From owner-namedroppers@ops.ietf.org Sat Jul 01 00:36:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwXDp-0004Vp-Dz for dnsext-archive@lists.ietf.org; Sat, 01 Jul 2006 00:36:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwXDl-0004Vj-GT for dnsext-archive@lists.ietf.org; Sat, 01 Jul 2006 00:36:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwX7V-000GrR-OY for namedroppers-data@psg.com; Sat, 01 Jul 2006 04:30:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.133.34] (helo=mail11.mdx.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwX7V-000GrA-8L for namedroppers@ops.ietf.org; Sat, 01 Jul 2006 04:30:13 +0000 Received: by mail11.mdx.safepages.com (Postfix, from userid 1012) id 14C9EA0AA3; Sat, 1 Jul 2006 02:40:13 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.252]) by mail11.mdx.safepages.com (Postfix) with ESMTP id C582BA0AF7; Sat, 1 Jul 2006 02:40:12 +0000 (GMT) Message-ID: <44A5E0D8.60906@connotech.com> Date: Fri, 30 Jun 2006 22:41:28 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: Recall: Key rollover Work. References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> < <20060630194116.GG595@afilias.info> In-Reply-To: <20060630194116.GG595@afilias.info> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Andrew Sullivan wrote: > [...] > > This is somewhat related to Thierry Moreau's comment > in > ; > but my view is ultimately that no protocol is going to save operators > from key mismanagement. Indeed. Furthermore, not all automated TAK rollover are created equal with respect to key mismanagement, i.e. some may be more error-prone than others. But that is not an evaluation criteria provided by draft-ietf-dnsext-rollover-requirements-02. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 01 02:39:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwZ8K-0008ML-Ni for dnsext-archive@lists.ietf.org; Sat, 01 Jul 2006 02:39:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwZ8I-0003ma-9B for dnsext-archive@lists.ietf.org; Sat, 01 Jul 2006 02:39:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwZ4K-000AiO-7K for namedroppers-data@psg.com; Sat, 01 Jul 2006 06:35:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwZ4J-000AhV-B8 for namedroppers@ops.ietf.org; Sat, 01 Jul 2006 06:35:03 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k616Z0xu004220 for ; Sat, 1 Jul 2006 08:35:00 +0200 (CEST) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k616Z0mA004219 for namedroppers@ops.ietf.org; Sat, 1 Jul 2006 08:35:00 +0200 (CEST) (envelope-from olaf) Date: Sat, 1 Jul 2006 08:35:00 +0200 (CEST) From: Olaf Kolkman Message-Id: <200607010635.k616Z0mA004219@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 01 09:22:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwfR5-0000lm-4A for dnsext-archive@lists.ietf.org; Sat, 01 Jul 2006 09:22:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwfR2-0007rO-PB for dnsext-archive@lists.ietf.org; Sat, 01 Jul 2006 09:22:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwfL9-0000pB-Nu for namedroppers-data@psg.com; Sat, 01 Jul 2006 13:16:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwfL9-0000oz-BV for namedroppers@ops.ietf.org; Sat, 01 Jul 2006 13:16:51 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FwfL8-0001PE-GQ for namedroppers@ops.ietf.org; Sat, 01 Jul 2006 09:16:50 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 1E4D113744; Sat, 1 Jul 2006 09:16:40 -0400 (EDT) Date: Sat, 1 Jul 2006 09:16:40 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Recall: Key rollover Work. Message-ID: <20060701131637.GA23120@dba3> Reply-To: Andrew Sullivan References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <44A1DB2D.3050704@algroup.co.uk> <3827.1151471569@sa.vix.com> <60E47F1C-F4B1-4DC2-B947-97262B39C746@NLnetLabs.nl> <20060630194116.GG595@afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060630194116.GG595@afilias.info> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Fri, Jun 30, 2006 at 03:41:16PM -0400, Andrew Sullivan wrote: > I did not review draft-weiler-dnssec-dlv-01.txt yet, because I did > not initially think that it was a candidate to satisfy the > requirements. I'm happy to do so, however (is that wanted?). I I read this very quickly, on my commute home yesterday, and while I cannot pretend to have a deep or complete understanding, I am pretty sure that it does not solve any Trust Anchor rollover problems. It moves them, but the DLV keys still need to be rolled. There does not appear to be anything in the draft that will satisfy requirement 5.11, at the very least, so I don't think it's a candidate. (It's still likely a good draft -- I'm not prepared to speak too much to it at present -- just not an answer to the problem the requirements state.) A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 02 22:02:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxDld-0000Nb-QP for dnsext-archive@lists.ietf.org; Sun, 02 Jul 2006 22:02:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxDld-0006po-8B for dnsext-archive@lists.ietf.org; Sun, 02 Jul 2006 22:02:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxDfv-000DCK-QX for namedroppers-data@psg.com; Mon, 03 Jul 2006 01:56:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxDfu-000DC5-Uw for namedroppers@ops.ietf.org; Mon, 03 Jul 2006 01:56:35 +0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k631uVF6018021 for ; Sun, 2 Jul 2006 18:56:33 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k631uVFV003734 for ; Sun, 2 Jul 2006 20:56:31 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Date: Sun, 2 Jul 2006 21:56:28 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790011A3869@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Thread-Index: AcacdomsVwgBYFaBQmaXvLu/CYHXTAByvzWQ From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 The whole thing about IANA allocations is to define the process so an objection related to that is quite important. As I understand it, the Expert's job is to, in effect, hold the delegated authority of IANA to grant or withhold allocation of a code point. It is not a "recommend/not recommend" thing, they have the authority, subject to the usual appeal channels to the IESG, etc. Of course they should try to help proponents. And if they are sufficiently obstructive or obnoxious or abuse their authority, you would expect a clamor to the IESG to replace them. Keep in mind that this is intended to be an open but reasonably rapid and efficient process. The template specified in 3.1.2 must have been completed and posted to namedroppers for three weeks so there will be plenty of time for community input. But someone has to have the authority and make the call and "Expert Review" means that the Designated Expert appointed by the IESG is it. Who did you think had the authority? It can't be the DNSEXT working group as the IETF process assumption is that all working groups are temporary. (Although, of course, as long as the DNEXT working group, or a successor, exists, I would expect its chair or co-chair to have major input to the Designated Expert selection.) Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Scott Rose Sent: Friday, June 30, 2006 2:40 PM To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt I have one comment on the new text (or maybe this was old, but I the first time I saw it). Unfortunately, it is a high level politics thing. The first paragraph in Section 3.1.3 has the sentence "The Expert should reject any RRTYPE allocation request...". That makes it sound like a much more formal process than the rest of the document lays out. From what I gathered, it is more of a "recommend/not recommend" thing. The Expert's job should be more of an endorsement, or failing the criteria, helping the proponents meet whatever goal they have for the draft. Yes, this is a process issue and not a technical one, but something that may catch some poor WG member acting as a expert in the future. Scott **************************************** Scott Rose Adv. Network Tech. Div., NIST +1 301-975-8439 https://www-x.antd.nist.gov/dnssec/ http://www.dnssec-deployment.org/ **************************************** > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eastlake III > Donald-LDE008 > Sent: Friday, June 30, 2006 10:36 AM > To: namedroppers@ops.ietf.org > Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > > Hi, > > The last feedback I got from the working group on this draft was that=20 > it was in good shape except for the need for some specific guidelines=20 > for the designated RR type allocation expert. So this updated version=20 > has such guidelines in section 3.1.3. Hopefully this version, or=20 > perhaps -04 is some minor changes are needed, will be ready for WG last call. > > Thanks, > Donald > > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Thursday, June 29, 2006 3:50 PM > To: i-d-announce@ietf.org > Cc: namedroppers@ops.ietf.org > Subject: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the DNS Extensions Working Group of the=20 > IETF. > > Title : Domain Name System (DNS) IANA Considerations > Author(s) : D. Eastlake 3rd > Filename : draft-ietf-dnsext-2929bis-03.txt > Pages : 19 > Date : 2006-6-29 > > Internet Assigned Number Authority (IANA) parameter assignment=20 > considerations are specified for the allocation of Domain Name System > (DNS) Classes, RR Types, operation codes, error codes, RR header bits, > and AFSDB subtypes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-ietf-dnsext-2929bis-03.txt". > > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-dnsext-2929bis-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 02 22:44:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxEPu-0007gy-Nl for dnsext-archive@lists.ietf.org; Sun, 02 Jul 2006 22:44:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxEPu-0001aQ-8V for dnsext-archive@lists.ietf.org; Sun, 02 Jul 2006 22:44:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxENV-000OCU-8w for namedroppers-data@psg.com; Mon, 03 Jul 2006 02:41:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxENU-000O99-B9 for namedroppers@ops.ietf.org; Mon, 03 Jul 2006 02:41:36 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k632fZQt024437 for ; Sun, 2 Jul 2006 19:41:35 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k632fZ1m020477 for ; Sun, 2 Jul 2006 21:41:35 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-eastlake-dnsext-cookies-00.txt Date: Sun, 2 Jul 2006 22:41:33 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790011A3872@de01exm64.ds.mot.com> In-Reply-To: <200606302016.k5UKGDMj002585@atlas.centergate.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-eastlake-dnsext-cookies-00.txt Thread-Index: Acacg2dOwFUEYe/4TtWvkUUvSKyumgBwNKfg From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 See below at @@@ -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of John Kristoff Sent: Friday, June 30, 2006 4:16 PM To: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt On Sun, 25 Jun 2006 23:08:28 -0400 "Eastlake III Donald-LDE008" wrote: > So I had this idea for DNS cookies to help ameliorate traffic=20 > amplification, cache poisoning, etc. attacks. Anyway, I've written up=20 > my idea and the first draft is available as=20 > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.t > xt I'd be interested in people's comments. This is a topic I'm interested in so I wanted to provide some feedback. Hopefully it is helpful. @@@ Sure, comments are useful. I did some experimentation with putting RRs in the additional section of requests and found that most servers seem to silently ignore them. However, I did find one case, where servers that fingerprint (fpdns) as a Microsoft Windows DNS 2000 implementation will first send back a FORMERR. Though some servers stop there, I've seen others that then follow up immediately with an answer if the query was otherwise valid. @@@ They actually sent two response messages (with the same ID presumably) to one query? Sounds odd to me. Just ignoring an Additional Information RR you don't understand and processing the rest of the query seems like the right thing to me. In the case of adding a cookie to the additional section in a response, what if there is no room for the cookie, particularly if the policy for them is set to "enforced"? Does it take precedence over other records? @@@ This was just a -00 draft. There are quite a few details that need to be filled in, such as the priority of the inclusion of COOKIE RRs, what their owner names, TTL, and CLASS should be (I'm inclined to say these are ignored), any recommendations related to using multiple types of DNS security, examples of message sequences, etc. My understanding of this draft is that this attempts to offset the DoS reflection/amplification attack by trying to avoid having servers respond to illegimate requests. For the resolver, it attempts to help avoid cache poisoning by essentially requiring an attacker to forge another, hopefully not easily knowable, set of bits. From the perspective of minimizing the DoS attacks, the server has no incentive, and in fact probably has a disincentive to set the policy to enabled, rather than disabled or enforced. The resolvers have some incentive to set their policy to enabled. Unless I'm missing something, there is this policy disconnect that will prohibit deployment without the impossible "flag day". @@@ I should think that servers would want to reduce the amount of work they have to do including having to send out big answers. This is especially true for recursive servers and servers that support DNSSEC and even more so for recursive servers that support DNSSEC. If this idea were adopted, how quickly servers would change to which mode I don't know. But it seems to me that if they have some resolvers they want to provide service to but that have not implemented COOKIEs but want the benefits for other resolvers, going to enabled mode makes some sense. The whole notion of having to have the resolvers and servers "learn" the cookies based on past queries and answers in the first place seems problematic. There seems to be a race condition here that an attacker would be able to exploit, either by having the other side learn it's illegimate cookie first or when a valid cookie expires. @@@ Nope, I don't think there is any race condition. If you do cache a cookie for the other side, it never needs to expire. It might get pushed out due to a cache congestion and it might get overridden by a new cookie but there is no reason to expire it just due to the passage of time. The server always reflects back the query resolver cookie in its response so there is no reason for it to cache it except as part of the indexing to its server cookie for that resolver to save hash computation. The resolver does not believe a server cookie it receives unless accompanied by a correct resolver cookie. If the server cookie is one it should so believe in, it can override any cached server cookie. @@@ I'll try to get a bunch of examples into the next version to show how all this works. In the case of a forwarding server, what should happen? Will a cookie be forwarded along with the request or should it be stripped, or even stripped and replaced with a new cookie, while doing validation on the cookie it received and vice versa with the original querier (if it has support for any of this functionality at all). @@@ Due to inclusion of the IP address, a server should always check the COOKIE, if present first. If bad, it returns an error. If good, it processes the query. If that results in it transmitting a query, the COOKIE RR it received is irrelevant and it should insert an appropriate COOKIE to the query it sends, if called for by its policy with the server it is querying, or send a query with no COOKIE if its policy for the server so indicates. I found a handful of small grammatical problems, shoot me an email offlist if you want to hear about those at this stage. @@@ I'd be happy for you to send them directly to me. John @@@ Thanks, @@@ Donald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 03 05:37:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKsO-0000Y8-Hc for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 05:37:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxKsM-000123-3P for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 05:37:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxKoC-0003gv-1p for namedroppers-data@psg.com; Mon, 03 Jul 2006 09:33:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxKoA-0003bB-OB for namedroppers@ops.ietf.org; Mon, 03 Jul 2006 09:33:35 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 37AC033C1B; Mon, 3 Jul 2006 10:33:26 +0100 (BST) Message-ID: <44A8E466.10207@algroup.co.uk> Date: Mon, 03 Jul 2006 10:33:26 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Gustavo Lozano CC: Namedroppers Subject: Re: Is keyrollover neccesary? (was Key rollover Work.) References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <2567.1151511542@sa.vix.com> <6.2.5.6.2.20060628182608.04874800@nic.mx> In-Reply-To: <6.2.5.6.2.20060628182608.04874800@nic.mx> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Gustavo Lozano wrote: > At 04:19 PM 6/28/2006 +0000, Paul Vixie wrote: >> if we were willing to cut&paste the root zone's key (and by local >> policy, some other set of trust anchors) into every validator, then there >> would be no automated trust anchor project going on in this working >> group. > > Statements: I don't want to start a flame war. I am committed to review > the keyrollover proposals and participate with my two cents. > > I gave a DNSSEC workshop to a carrier in Mexico months ago. When I > mentioned the keyrollover work being done in the IETF they asked me if > automatic trust anchor keyrollover is really necessary to deploy > DNSSECbis and this question has been in my head since. > > Since the first time I read about DNSSECbis it became clear the > usefulness of having a signed root. I know about the trouble of signing > the root, but when the root is finally signed I expect that RSA is > broken first before the root zone key is compromised. I expect that the > entity chosen for root signing implements the same operational security > that Verising uses to guard its root CA private key. If the root is > signed and a root key compromise happens, it's going to be "big news" > (think of CNN alert news) and people will update. Note that having the root signed is only the start of the solution. You also need an unbroken chain of signed zones from the root to every zone that wants to deploy DNSSEC. > > If the root is never signed, IANA can have a list of the trusted anchor > currently used by each TLD and we know that communication between IANA > and the TLDs is already authenticated. You can think of a lot of > operational procedures to propagate this information from IANA to end > users: windows update, RHN, cvsup, https GET by the DNS implementation, > etc. The trick is that if you don't update your TA in your validator > then your client's DNS request will fail and someone is going to scream > and you will have to fix it. I expect that TLDs will implement a > security infrastructure (here at NIC Mexico cctld .mx we are thinking > about FIPS 140-2 level 3 HSMs for example) to protect the key so I think > that a key rollover should be an isolated event. > > Is DNSSECbis deployable without an automatic trust anchor keyrollover > feature? Maybe what we need is a key management security guideline in > the spirit of RFC3647 or we can add more operational security best > practices to the existent dnssec operational practices? Maybe we are > trying to make a perfect protocol and we just need a pretty good protocol? > > Thank you for your comments. > > > Gustavo Lozano > NIC Mexico > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 03 10:53:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPnx-0000YK-Fh for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 10:53:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPnw-0002q7-6k for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 10:53:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxPk0-000I3S-3N for namedroppers-data@psg.com; Mon, 03 Jul 2006 14:49:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxPjz-000I2M-LS for namedroppers@ops.ietf.org; Mon, 03 Jul 2006 14:49:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EBB991142E for ; Mon, 3 Jul 2006 14:49:34 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Is keyrollover neccesary? (was Key rollover Work.) In-Reply-To: Your message of "Mon, 03 Jul 2006 10:33:26 +0100." <44A8E466.10207@algroup.co.uk> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <2567.1151511542@sa.vix.com> <6.2.5.6.2.20060628182608.04874800@nic.mx> <44A8E466.10207@algroup.co.uk> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Jul 2006 14:49:34 +0000 Message-ID: <3198.1151938174@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de > Note that having the root signed is only the start of the solution. You > also need an unbroken chain of signed zones from the root to every zone > that wants to deploy DNSSEC. you mean "from some trust anchor" not "from the root", surely? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 03 14:55:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxTZv-0002bN-2N for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 14:55:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxTZs-0007QI-Fo for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 14:55:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxTUk-000Anb-K0 for namedroppers-data@psg.com; Mon, 03 Jul 2006 18:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxTUj-000AnB-DU for namedroppers@ops.ietf.org; Mon, 03 Jul 2006 18:50:05 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k63InwRA029807 for ; Mon, 3 Jul 2006 14:49:58 -0400 Received: from gorilla ([129.6.220.94]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k63ImwB7025765 for ; Mon, 3 Jul 2006 14:49:00 -0400 (EDT) From: "Scott Rose" To: Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Date: Mon, 3 Jul 2006 14:49:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3870C46029D1F945B1472F170D2D9790011A3869@de01exm64.ds.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Alright then. I think I mis-understood the text at first read. I have no problem with the chosen expert acting with the authority of IANA (or whichever entity will be serving that role in the future). Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eastlake III > Donald-LDE008 > Sent: Sunday, July 02, 2006 9:56 PM > To: namedroppers@ops.ietf.org > Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > > The whole thing about IANA allocations is to define the process so an > objection related to that is quite important. > > As I understand it, the Expert's job is to, in effect, hold the > delegated authority of IANA to grant or withhold allocation of a code > point. It is not a "recommend/not recommend" thing, they have the > authority, subject to the usual appeal channels to the IESG, etc. Of > course they should try to help proponents. And if they are sufficiently > obstructive or obnoxious or abuse their authority, you would expect a > clamor to the IESG to replace them. > > Keep in mind that this is intended to be an open but reasonably rapid > and efficient process. The template specified in 3.1.2 must have been > completed and posted to namedroppers for three weeks so there will be > plenty of time for community input. But someone has to have the > authority and make the call and "Expert Review" means that the > Designated Expert appointed by the IESG is it. > > Who did you think had the authority? It can't be the DNSEXT working > group as the IETF process assumption is that all working groups are > temporary. (Although, of course, as long as the DNEXT working group, or > a successor, exists, I would expect its chair or co-chair to have major > input to the Designated Expert selection.) > > Thanks, > Donald > > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Scott Rose > Sent: Friday, June 30, 2006 2:40 PM > To: namedroppers@ops.ietf.org > Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > I have one comment on the new text (or maybe this was old, but I the > first time I saw it). Unfortunately, it is a high level politics thing. > > The first paragraph in Section 3.1.3 has the sentence "The Expert should > reject any RRTYPE allocation request...". That makes it sound like a > much more formal process than the rest of the document lays out. From > what I gathered, it is more of a "recommend/not recommend" thing. The > Expert's job should be more of an endorsement, or failing the criteria, > helping the proponents meet whatever goal they have for the draft. > > Yes, this is a process issue and not a technical one, but something that > may catch some poor WG member acting as a expert in the future. > > Scott > **************************************** > Scott Rose > Adv. Network Tech. Div., NIST > +1 301-975-8439 > > https://www-x.antd.nist.gov/dnssec/ > http://www.dnssec-deployment.org/ > **************************************** > > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Friday, June 30, 2006 10:36 AM > > To: namedroppers@ops.ietf.org > > Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > > > > > Hi, > > > > The last feedback I got from the working group on this draft was that > > it was in good shape except for the need for some specific guidelines > > for the designated RR type allocation expert. So this updated version > > has such guidelines in section 3.1.3. Hopefully this version, or > > perhaps -04 is some minor changes are needed, will be ready for WG > last call. > > > > Thanks, > > Donald > > > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Thursday, June 29, 2006 3:50 PM > > To: i-d-announce@ietf.org > > Cc: namedroppers@ops.ietf.org > > Subject: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DNS Extensions Working Group of the > > IETF. > > > > Title : Domain Name System (DNS) IANA Considerations > > Author(s) : D. Eastlake 3rd > > Filename : draft-ietf-dnsext-2929bis-03.txt > > Pages : 19 > > Date : 2006-6-29 > > > > Internet Assigned Number Authority (IANA) parameter assignment > > considerations are specified for the allocation of Domain Name System > > (DNS) Classes, RR Types, operation codes, error codes, RR header bits, > > > and AFSDB subtypes. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-dnsext-2929bis-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-dnsext-2929bis-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 03 18:01:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWUF-0006Jr-LA for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 18:01:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxWUE-0001ob-AR for dnsext-archive@lists.ietf.org; Mon, 03 Jul 2006 18:01:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxWRQ-0003Et-G1 for namedroppers-data@psg.com; Mon, 03 Jul 2006 21:58:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [204.74.78.17] (helo=atlas.centergate.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxWRP-0003DP-LN for namedroppers@ops.ietf.org; Mon, 03 Jul 2006 21:58:51 +0000 Received: from dsl017-022-073.chi1.dsl.speakeasy.net (atlas.centergate.com [127.0.0.1]) by atlas.centergate.com (8.13.1/8.13.1) with SMTP id k63LwoVF024484 for ; Mon, 3 Jul 2006 14:58:50 -0700 Message-Id: <200607032158.k63LwoVF024484@atlas.centergate.com> Date: Mon, 3 Jul 2006 16:58:50 -0500 From: John Kristoff To: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt In-Reply-To: <3870C46029D1F945B1472F170D2D9790011A3872@de01exm64.ds.mot.com> References: <200606302016.k5UKGDMj002585@atlas.centergate.com> <3870C46029D1F945B1472F170D2D9790011A3872@de01exm64.ds.mot.com> X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.8.12; i386-apple-darwin8.5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On Sun, 2 Jul 2006 22:41:33 -0400 "Eastlake III Donald-LDE008" wrote: > However, I did find one case, where servers that fingerprint (fpdns) > as a Microsoft Windows DNS 2000 implementation will first send back a > FORMERR. Though some servers stop there, I've seen others that then > follow up immediately with an answer if the query was otherwise valid. > > @@@ They actually sent two response messages (with the same ID > presumably) to one query? Sounds odd to me. Just ignoring an If you need some sample code, reply off list and I'll send you a bit of Perl that uses Net::DNS to exhibit this behavior, but in the meantime, the DNS server at 207.198.250.119 is just one example of an implementation, which appears to do exactly that. Here is what I see: A query for motorola.com to 207.198.250.119 over UDP/53, including an additional section with an A record for foo.bar, type A, class IN with address of 192.0.2.1. RD bit set. First response echoes back the query indicating a format error. An immediate second packet from the server, with the same ID, but this time with an answer to the A query for motorola. My particular resolver does not expect this response, so it issues an ICMP destination port unreachable back. I'll keep the pcap for a bit if someone thinks I'm making this up. :-) I guess servers like this would make those open recursive name server attacks that much more potent eh? :-/ > Additional Information RR you don't understand and processing the > rest of the query seems like the right thing to me. Agreed, all other implementations I tried this agaist appeared to do exactly that. > don't know. But it seems to me that if they have some resolvers they > want to provide service to but that have not implemented COOKIEs but > want the benefits for other resolvers, going to enabled mode makes > some sense. It would seem that way, but I think we might find in practice it won't be implemented that way. As I was trying to point out, all those resolvers that you have to "allow", will be precisely the ones you would want using cookies. > @@@ I'll try to get a bunch of examples into the next version to show > how all this works. I think that will be helpful and I'll withhold further comments on this particular issue til then. John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 04 05:10:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxgvG-0007iv-LW for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 05:10:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxguS-0005xo-CI for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 05:09:32 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fxgqd-0002RF-Hr for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 05:05:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxgjU-000FfC-U3 for namedroppers-data@psg.com; Tue, 04 Jul 2006 08:58:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxgjT-000Fep-St for namedroppers@ops.ietf.org; Tue, 04 Jul 2006 08:58:12 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 04 Jul 2006 09:58:10 +0100 X-IronPort-AV: i="4.06,203,1149462000"; d="scan'208"; a="3889645:sNHT32655596" In-Reply-To: <200607032158.k63LwoVF024484@atlas.centergate.com> To: John Kristoff Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 4 Jul 2006 10:58:24 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/04/2006 09:58:24 AM, Serialize complete at 07/04/2006 09:58:24 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -1.4 (-) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 John Kristoff wrote on 07/03/2006 11:58:50 PM: > On Sun, 2 Jul 2006 22:41:33 -0400 > "Eastlake III Donald-LDE008" wrote: > > > However, I did find one case, where servers that fingerprint (fpdns) > > as a Microsoft Windows DNS 2000 implementation will first send back a > > FORMERR. Though some servers stop there, I've seen others that then > > follow up immediately with an answer if the query was otherwise valid. > > > > @@@ They actually sent two response messages (with the same ID > > presumably) to one query? Sounds odd to me. Just ignoring an > > If you need some sample code, reply off list and I'll send you a > bit of Perl that uses Net::DNS to exhibit this behavior, but in the > meantime, the DNS server at 207.198.250.119 is just one example of > an implementation, which appears to do exactly that. Here is what > I see: > > A query for motorola.com to 207.198.250.119 over UDP/53, including > an additional section with an A record for foo.bar, type A, class > IN with address of 192.0.2.1. RD bit set. > > First response echoes back the query indicating a format error. > > An immediate second packet from the server, with the same ID, but this > time with an answer to the A query for motorola. My particular resolver > does not expect this response, so it issues an ICMP destination port > unreachable back. I'll keep the pcap for a bit if someone thinks > I'm making this up. :-) I guess servers like this would make those > open recursive name server attacks that much more potent eh? :-/ As for the configuration of 207.198.250.119, it seems it is (blindly) forwarding requests to both 204.141.112.2 and 129.250.16.14, simultaniously. The software running on 204.141.112.2 is Microsoft Windows DNS 2000, source of the FORMERR you have received. Note that ANY information in the additional section, including OPT RR (for edns purposes) causes a FORMERR with this implementation. The software running on 129.250.16.14 is ISC BIND 9.3.1, which silently ignores unknown data in the additional section. Both hosts are open recursive resolvers. So, to be correct, it is not that Windows DNS 2000 responds twice to a single request. It is the forwarder that causes that behavior by multiplexing a single request to two different recursive resolvers. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 04 09:30:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxkzC-000296-Rk for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 09:30:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxkzB-000242-F2 for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 09:30:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxkuX-000CXJ-JB for namedroppers-data@psg.com; Tue, 04 Jul 2006 13:25:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxkuW-000CX3-Rt for namedroppers@ops.ietf.org; Tue, 04 Jul 2006 13:25:53 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k64DPok9057480; Tue, 4 Jul 2006 15:25:50 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <3870C46029D1F945B1472F170D2D9790011A3869@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790011A3869@de01exm64.ds.mot.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6--233826490" Message-Id: Cc: IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Date: Tue, 4 Jul 2006 15:25:48 +0200 To: Eastlake III Donald-LDE008 X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6--233826490 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > As I understand it, the Expert's job is to, in effect, hold the > delegated authority of IANA to grant or withhold allocation of a code > point. It is not a "recommend/not recommend" thing, they have the > authority, subject to the usual appeal channels to the IESG, etc. Of > course they should try to help proponents. And if they are > sufficiently > obstructive or obnoxious or abuse their authority, you would expect a > clamor to the IESG to replace them. Actually it might be good to make that explicit: Maybe it would be good to make that a little more explicit by defining the term in the introduction. Something like: Designated Expert: a subject matter expert hired and fired by the relevant AD and subject to the IETF appeal. See RFC2434 section 2. and then consequently use "Designated Expert" throughout the text. no hats, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-6--233826490 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEqmxdtN/ca3YJIocRAne9AJ0WRLmYb/h2nTAzWqJkXhtVXE7/xACgjDCN Mpvxhg2g3wFD+CLqO1HfH1Y= =1IcH -----END PGP SIGNATURE----- --Apple-Mail-6--233826490-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 04 11:50:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnAF-0000ZY-K1 for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 11:50:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxn28-0005VV-A2 for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 11:41:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxmyc-000P74-Ei for namedroppers-data@psg.com; Tue, 04 Jul 2006 15:38:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=ham version=3.1.1 Received: from [65.54.246.204] (helo=bay0-omc3-s4.bay0.hotmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxmyb-000P6q-JU for namedroppers@ops.ietf.org; Tue, 04 Jul 2006 15:38:13 +0000 Received: from hotmail.com ([64.4.61.83]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 08:38:13 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Jul 2006 08:38:13 -0700 Message-ID: Received: from 62.30.56.40 by BAY102-DAV11.phx.gbl with DAV; Tue, 04 Jul 2006 15:38:09 +0000 X-Originating-IP: [62.30.56.40] X-Originating-Email: [priyandika@hotmail.com] X-Sender: priyandika@hotmail.com Reply-To: "Suranjith Ariyapperuma" From: "Suranjith Ariyapperuma" To: References: Subject: Re: draft-eastlake-dnsext-cookies-00.txt Date: Tue, 4 Jul 2006 16:38:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0158_01C69F88.397586D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 04 Jul 2006 15:38:13.0017 (UTC) FILETIME=[DC2BF890:01C69F7F] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 3.1 (+++) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 This is a multi-part message in MIME format. ------=_NextPart_000_0158_01C69F88.397586D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roy, Sorry if this sounds a silly question. How did you figure out the below ? =20 As for the configuration of 207.198.250.119, it seems it is (blindly)=20 forwarding requests to both 204.141.112.2 and 129.250.16.14,=20 simultaneously Best regards, Suranjith ----- Original Message -----=20 From: "Roy Arends" To: "John Kristoff" Cc: Sent: Tuesday, July 04, 2006 9:58 AM Subject: Re: draft-eastlake-dnsext-cookies-00.txt > John Kristoff wrote on 07/03/2006 11:58:50 PM: >=20 > > On Sun, 2 Jul 2006 22:41:33 -0400 > > "Eastlake III Donald-LDE008" wrote: > >=20 > > > However, I did find one case, where servers that fingerprint = (fpdns) > > > as a Microsoft Windows DNS 2000 implementation will first send = back a > > > FORMERR. Though some servers stop there, I've seen others that = then > > > follow up immediately with an answer if the query was otherwise = valid. > > >=20 > > > @@@ They actually sent two response messages (with the same ID > > > presumably) to one query? Sounds odd to me. Just ignoring an > >=20 > > If you need some sample code, reply off list and I'll send you a > > bit of Perl that uses Net::DNS to exhibit this behavior, but in the > > meantime, the DNS server at 207.198.250.119 is just one example of > > an implementation, which appears to do exactly that. Here is what > > I see: > >=20 > > A query for motorola.com to 207.198.250.119 over UDP/53, including > > an additional section with an A record for foo.bar, type A, class > > IN with address of 192.0.2.1. RD bit set. > >=20 > > First response echoes back the query indicating a format error. > >=20 > > An immediate second packet from the server, with the same ID, but = this > > time with an answer to the A query for motorola. My particular = resolver > > does not expect this response, so it issues an ICMP destination port > > unreachable back. I'll keep the pcap for a bit if someone thinks > > I'm making this up. :-) I guess servers like this would make those > > open recursive name server attacks that much more potent eh? :-/ >=20 > As for the configuration of 207.198.250.119, it seems it is (blindly)=20 > forwarding requests to both 204.141.112.2 and 129.250.16.14,=20 > simultaniously.=20 >=20 > The software running on 204.141.112.2 is Microsoft Windows DNS 2000,=20 > source of the FORMERR you have received. Note that ANY information in = the=20 > additional section, including OPT RR (for edns purposes) causes a = FORMERR=20 > with this implementation.=20 > The software running on 129.250.16.14 is ISC BIND 9.3.1, which = silently=20 > ignores unknown data in the additional section. >=20 > Both hosts are open recursive resolvers. >=20 > So, to be correct, it is not that Windows DNS 2000 responds twice to a = > single request. It is the forwarder that causes that behavior by=20 > multiplexing a single request to two different recursive resolvers. >=20 > Roy >=20 > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org = with > the word 'unsubscribe' in a single line as the message text body. > archive: > ------=_NextPart_000_0158_01C69F88.397586D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roy,

 

Sorry if this sounds a silly = question=85

How did you figure out the below ?

 

As for the configuration of = 207.198.250.119, it=20 seems it is (blindly)
forwarding requests to both 204.141.112.2 and=20 129.250.16.14,
simultaneously
 
Best regards,
Suranjith
 
 
 
----- Original Message ----- =
From: "Roy Arends" <roy@nominet.org.uk>
To: "John Kristoff" = <jtk@ultradns.net>
Cc: <namedroppers@ops.ietf.org>
Sent: Tuesday, July 04, 2006 = 9:58=20 AM
Subject: Re:=20 draft-eastlake-dnsext-cookies-00.txt

> John Kristoff wrote on 07/03/2006 = 11:58:50=20 PM:
>
> > On Sun, 2 Jul 2006 22:41:33 -0400
> > = "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> wrote:
> >
> > > However, I = did find=20 one case, where servers that fingerprint (fpdns)
> > > as a=20 Microsoft Windows DNS 2000 implementation will first send back a
> = >=20 > FORMERR.  Though some servers stop there, I've seen others = that=20 then
> > > follow up immediately with an answer if the query = was=20 otherwise valid.
> > >
> > > @@@ They actually = sent two=20 response messages (with the same ID
> > > presumably) to one = query?=20 Sounds odd to me. Just ignoring an
> >
> > If you = need some=20 sample code, reply off list and I'll send you a
> > bit of Perl = that=20 uses Net::DNS to exhibit this behavior, but in the
> > = meantime, the=20 DNS server at 207.198.250.119 is just one example of
> > an=20 implementation, which appears to do exactly that.  Here is = what
>=20 > I see:
> >
> >   A query for = motorola.com to=20 207.198.250.119 over UDP/53, including
> >   an = additional=20 section with an A record for foo.bar, type A, class
> = >   IN=20 with address of 192.0.2.1.  RD bit set.
> >
> > = First=20 response echoes back the query indicating a format error.
> > =
>=20 > An immediate second packet from the server, with the same ID, but=20 this
> > time with an answer to the A query for motorola.  = My=20 particular resolver
> > does not expect this response, so it = issues an=20 ICMP destination port
> > unreachable back. I'll keep the pcap = for a=20 bit if someone thinks
> > I'm making this up.  :-)  I = guess=20 servers like this would make those
> > open recursive name = server=20 attacks that much more potent eh?  :-/
>
> As for the=20 configuration of 207.198.250.119, it seems it is (blindly)
> = forwarding=20 requests to both 204.141.112.2 and 129.250.16.14,
> = simultaniously.=20
>
> The software running on 204.141.112.2 is Microsoft = Windows DNS=20 2000,
> source of the FORMERR you have received. Note that ANY=20 information in the
> additional section, including OPT RR (for = edns=20 purposes) causes a FORMERR
> with this implementation.
> = The=20 software running on 129.250.16.14 is ISC BIND 9.3.1, which silently =
>=20 ignores unknown data in the additional section.
>
> Both = hosts are=20 open recursive resolvers.
>
> So, to be correct, it is not = that=20 Windows DNS 2000 responds twice to a
> single request. It is the=20 forwarder that causes that behavior by
> multiplexing a single = request to=20 two different recursive resolvers.
>
> Roy
>
> = --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as = the=20 message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> ------=_NextPart_000_0158_01C69F88.397586D0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 04 11:59:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnJN-0000H6-OT for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 11:59:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxnJM-0007eg-DX for dnsext-archive@lists.ietf.org; Tue, 04 Jul 2006 11:59:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxnHS-00016S-OL for namedroppers-data@psg.com; Tue, 04 Jul 2006 15:57:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxnHR-00016B-V6 for namedroppers@ops.ietf.org; Tue, 04 Jul 2006 15:57:42 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 04 Jul 2006 16:57:40 +0100 X-IronPort-AV: i="4.06,205,1149462000"; d="scan'208"; a="4338675:sNHT32261524" In-Reply-To: To: "Suranjith Ariyapperuma" Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 4 Jul 2006 17:57:53 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/04/2006 04:57:54 PM, Serialize complete at 07/04/2006 04:57:54 PM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 U3VyYW5qaXRoIEFyaXlhcHBlcnVtYSB3cm90ZSBvbiAwNy8wNC8yMDA2IDA1OjM4OjA1IFBNOg0K DQo+IEhpIFJveSwNCj4gDQo+IFNvcnJ5IGlmIHRoaXMgc291bmRzIGEgc2lsbHkgcXVlc3Rpb27i gKYNCj4gSG93IGRpZCB5b3UgZmlndXJlIG91dCB0aGUgYmVsb3cgPw0KPiANCj4gICBBcyBmb3Ig dGhlIGNvbmZpZ3VyYXRpb24gb2YgMjA3LjE5OC4yNTAuMTE5LCBpdCBzZWVtcyBpdCBpcyAoYmxp bmRseSkgDQo+ICAgZm9yd2FyZGluZyByZXF1ZXN0cyB0byBib3RoIDIwNC4xNDEuMTEyLjIgYW5k IDEyOS4yNTAuMTYuMTQsIA0KPiAgIHNpbXVsdGFuZW91c2x5DQoNCkkgc2VuZCBhIHJlY3Vyc2l2 ZSBxdWVyeSBmb3IgYSBuYW1lIHVuZGVyIG15IGF1dGhvcml0eSB0byAyMDcuMTk4LjI1MC4xMTku IA0KVGhlIGl0ZXJhdGl2ZSBxdWVyaWVzIGNvbWluZyB0byBteSBhdXRob3JpdGF0aXZlIHNlcnZl cnMgKGZvciB0aGF0IA0Kc3BlY2lmaWMgbmFtZSkgY2FtZSBmcm9tIGJvdGggMjA0LjE0MS4xMTIu MiBhbmQgMTI5LjI1MC4xNi4xNCANCnNpbXV0YW5pb3VzbHkuIFRoZXJlIHdlcmUgbm8gcmVxdWVz dHMgY29taW5nIGluIGZyb20gMjA3LjE5OC4yNTAuMTE5LiBTbyANCml0IGlzIHZlcnkgbGlrZWx5 IHRoYXQgMjA3LjE5OC4yNTAuMTE5IGlzIGEgZm9yd2FyZGVyLCB3aGljaCBoYXMgdGhlIG90aGVy IA0KdHdvIGFkZHJlc3NlcyBjb25maWd1cmVkIGFzIHVwc3RyZWFtIHJlc29sdmVycy4NCg0KSG9w ZSB0aGlzIGhlbHBzLA0KDQpSb3kgDQo= -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 04:06:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyOsO-00037n-0n for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 04:06:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyOsM-0004WI-Ab for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 04:06:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyOlF-0005z7-6O for namedroppers-data@psg.com; Thu, 06 Jul 2006 07:58:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyOlD-0005yj-Vw for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 07:58:56 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k667wbOi049003; Thu, 6 Jul 2006 09:58:37 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-18--80659004" Message-Id: <90AEB90D-2D7A-465A-82C4-08467172B5EB@nlnetlabs.nl> Cc: iesg-secretary@ietf.org, IETF DNSEXT WG , Jari Arkko Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Advance request for opt-in and experiments Date: Thu, 6 Jul 2006 09:58:36 +0200 To: Mark Townsley X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-18--80659004 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Mark, This is a proto request for two documents. Olaf Kolkman will be the shepherd for both. Please publish draft-ietf-dnsext-dnssec-experiments-03 on the standards track and publish draft-ietf-dnsext-dnssec-opt-in-09 as an experimental rfc. Questions: 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes we have reviewed both document. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes. draft-ietf-dnsext-dnssec-opt-in has quite a long history and thorough and in-depth discussion a few years ago also see below. Both opt-in and dnssec-experiments have been last called together and were reviewed (among others) by: Sam Weiler (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00576.html) Ed Lewis (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00440.html) Andrew Sullivan (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00330.html) Mark Kosters (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00309.html) Thierry Moreau (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00305.html) Scott Rose (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00316.html) Rodney Joffe(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00335.html) Thomas Nartan (thread starting at: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00308.html). 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No we do not. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. It is probably good to have some historic background on the documents. The OPT-in document has been around for a long time. In 2002 it lead to heated debates which resulted in a conclusion that opt-in was technically solid but there was no rough consensus to add opt-in to the spec. (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01007.html) The chairs then suggested to make sure that opt-in did not end up as an I-D tombstone but was to be published as informational draft. Adding the boilerplate has been on the WG todo list for a very long time. In the mean time the working group has created DNSSECbis and has thought about the possible transition mechanisms to DNSSEC-ter (for deploying NSEC3). One of the possible transition mechanism can also be used to run experiments on production systems without interfering with production data. This technology has been described in the dnssec-experiments draft. After dnssec-experiments was published as an I-D, the editors of OPT-IN (also the editor of opt-in) suggested to update OPT-IN to fit in the frame work of dnssec-experiments, in other words opt-in being the first application of dnssec-experiments. Currently the OPT-IN technology is making its comeback in the NSEC3 specification. Times seem to have changed since OPT-IN does not seem to be as contentious as 4 years ago. 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? We think it is solid. Active members are aware of this document and key members of the working group have reviewed the documents. There were no objections raised against the document. There was some clarification work needed after version of 'experiment' and version 8 of 'opt-in. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. See the history above. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). yes 8) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: draft-ietf-dnsext-dnssec-experiments This document describes how algorithm identifiers can be used to perform experiments within a DNSSECbis environment without that the published data is marked as "bogus" by validating resolvers that do not partake in the experiments. The document explains why this methodology works and describes how experiments are to be defined. Besides, it suggests that algorithm identifiers can be used to introduce non-backward compatible DNSSEC features into the protocol. The first application of this methodology will be an experiment with "opt-in" [draft-ietf-dnsext-dnssec-opt-in]. It is possible that the methodology will be used for the introduction of current DNSSEC extensions currently under development in DNSEXT, the NSEC3 work. draft-ietf-dnsext-dnssec-opt-in opt-in is a method to disable the authenticated denial of existence for a range of domain names in a zone. It has been developed to generate a sparse set of NSEC RRs in a zone that contains mostly delegations i.e. to opt-in the secure delegations. The span of delegations for which authenticated denial is not available is still indicated using an NSEC resource record. 'NSEC-bit' in the type bitmap of the NSEC RDATA is used to signal the different semantic of the opt-in type NSEC RR. opt-in is a methodology that is backwards incompatible with DNSSEC; in order to perform a trial the methodology described in draft-ietf-dnsext-dnssec-experiments is applied. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-18--80659004 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFErMKstN/ca3YJIocRAvf1AKCesuj7yXfHCsF4HU0a8vcWnwmIDwCgoNgG X+8nz7YnUM31CNoy6pNvNdw= =asod -----END PGP SIGNATURE----- --Apple-Mail-18--80659004-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 09:32:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTyV-0006Cj-DU for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 09:32:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTyV-0004iF-C4 for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 09:32:59 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyTyT-0005QF-J2 for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 09:32:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyTsr-000A5b-03 for namedroppers-data@psg.com; Thu, 06 Jul 2006 13:27:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyTsq-000A5P-E5 for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 13:27:08 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k66DQ8aS024049 for ; Thu, 6 Jul 2006 09:26:08 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAocaq1U; Thu, 6 Jul 06 09:25:44 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k66DOVtV004809 for ; Thu, 6 Jul 2006 09:24:32 -0400 (EDT) Date: Thu, 6 Jul 2006 09:26:32 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: IETF DNSEXT WG Subject: Re: Advance request for opt-in and experiments In-Reply-To: <90AEB90D-2D7A-465A-82C4-08467172B5EB@nlnetlabs.nl> Message-ID: References: <90AEB90D-2D7A-465A-82C4-08467172B5EB@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de The wildcard section (4.1.3 in opt-in-08) appears to have disappeared in opt-in-09, and I'm not recalling the WG's discussion of that. Would someone kindly refer me to it? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 11:55:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWC7-0007Wg-QS for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 11:55:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWC5-00022E-Dm for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 11:55:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyW8h-000NnR-Ma for namedroppers-data@psg.com; Thu, 06 Jul 2006 15:51:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyW8h-000NnD-3B for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 15:51:39 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 06 Jul 2006 16:51:37 +0100 X-IronPort-AV: i="4.06,214,1149462000"; d="scan'208"; a="3916815:sNHT36575764" In-Reply-To: To: IETF DNSEXT WG Subject: Re: Advance request for opt-in and experiments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Thu, 6 Jul 2006 17:51:53 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/06/2006 04:51:53 PM, Serialize complete at 07/06/2006 04:51:53 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Sam Weiler wrote on 07/06/2006 03:26:32 PM: > The wildcard section (4.1.3 in opt-in-08) appears to have disappeared > in opt-in-09, and I'm not recalling the WG's discussion of that. > Would someone kindly refer me to it? That section was wrong and redundant. Wrong because that specific section dealt with full opt-in (not delegation only opt-in). Redundant since the issues surrounding opt-in and wildcards is covered in section 8 as well. Section 4 discussses Protocol Additions, while section 4.1.3 in opt-in-08 explained a security consideration. The original reason for section 4.1.3 was that it seemed that the use of opt-in and wildcards are a special corner case. It is _not_ a special corner case. An opt-in span may contain unsigned delegations (i.e. onwernames that only own NS records, not any other records). Section 8 (security considerations) explain the security issues surrounding unsigned names. In particular, this means that a malicious entity may be able to insert or delete records with unsigned names. These records are normally NS records, but this also includes signed wildcard expansions (while the wildcard record itself is signed, its expanded name is an unsigned name), which can be undetectably removed or used to replace an existing unsigned delegation. (last two sentences are quoted from section 8). Hope this helps. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 13:00:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXDI-0001lF-Ho for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 13:00:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXDH-0005ER-4i for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 13:00:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyX9V-0003bk-Pb for namedroppers-data@psg.com; Thu, 06 Jul 2006 16:56:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyX9U-0003bT-SY for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 16:56:33 +0000 Received: from [10.31.32.89] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k66GuKRU021829; Thu, 6 Jul 2006 12:56:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 6 Jul 2006 12:56:23 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Advance request for opt-in and experiments Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 At 17:51 +0200 7/6/06, Roy Arends wrote: >Sam Weiler wrote on 07/06/2006 03:26:32 PM: > >> The wildcard section (4.1.3 in opt-in-08) appears to have disappeared >> in opt-in-09, and I'm not recalling the WG's discussion of that. >> Would someone kindly refer me to it? > >That section was wrong and redundant. Wrong because that specific section >dealt with full opt-in (not delegation only opt-in). Redundant since the >issues surrounding opt-in and wildcards is covered in section 8 as well. >Section 4 discussses Protocol Additions, while section 4.1.3 in opt-in-08 >explained a security consideration. Part of Sam's question is 'where is the WG's discussion of the change' as this is a WG document. >The original reason for section 4.1.3 was that it seemed that the use of >opt-in and wildcards are a special corner case. It is _not_ a special >corner case. I do recall long discussions about the interaction of wild cards and opt-in the last time significant progress was made on this issue. If opt-in restricts opt-ed out domains to being delegation points and we are currently avoiding any word on wild card NS records (in the wcard draft, RFC "rfc-editor queue *still*") I think there is a consideration to cover. Let's say I have *.example TXT in the zone. This would generate names anywhere there is nothing else, potentially outside/inside an opt-in/out span. I suppose that we can write this off by saying that the proof show the real source to be *.example. Fine, but, what about a replay of the opt-in NSEC covering the query name? This dilemma ought to be recognized. We can't opt-out a wildcard. Because only NS's can be opted-out and wildcards can't reliably own NS's. >An opt-in span may contain unsigned delegations (i.e. onwernames that only >own NS records, not any other records). Section 8 (security >considerations) explain the security issues surrounding unsigned names. In >particular, this means that a malicious entity may be able to insert or >delete records with unsigned names. These records are normally NS 'normally'? >records, but this also includes signed wildcard expansions (while the >wildcard record itself is signed, its expanded name is an unsigned name), >which can be undetectably removed or used to replace an existing unsigned >delegation. > >(last two sentences are quoted from section 8). That's the dilemma. Wildcards and opt-in have never really mixed. I think that's significant to get it's own section. BTW, I'm fine with such a bump in an experimental RFC. Not saying anything about standards eventualities, but it's okay to play. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 13:51:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyY0E-0002Sf-Mj for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 13:51:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyY0D-0000D5-Ck for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 13:51:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyXwm-0007bL-Do for namedroppers-data@psg.com; Thu, 06 Jul 2006 17:47:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyXwl-0007b8-TB for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 17:47:27 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 06 Jul 2006 13:47:26 -0400 id 002CC092.44AD4CAE.00003758 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> Cc: Roy Arends , IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Advance request for opt-in and experiments Date: Thu, 6 Jul 2006 13:47:25 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Jul 6, 2006, at 12:56 PM, Edward Lewis wrote: > > Part of Sam's question is 'where is the WG's discussion of the > change' as this is a WG document. There wasn't a recent one. > Let's say I have *.example TXT in the zone. This would generate > names anywhere there is nothing else, potentially outside/inside an > opt-in/out span. I suppose that we can write this off by saying > that the proof show the real source to be *.example. Fine, but, > what about a replay of the opt-in NSEC covering the query name? > This dilemma ought to be recognized. This is basically what removing section 4.1.3 was about. 4.1.3 tried to justify a change in the proof structure of a positive wildcard response when the qname was covered by an opt-in NSEC. The logic wasn't solid, so I removed it. >> records, but this also includes signed wildcard expansions (while the >> wildcard record itself is signed, its expanded name is an unsigned >> name), >> which can be undetectably removed or used to replace an existing >> unsigned >> delegation. >> >> (last two sentences are quoted from section 8). > > That's the dilemma. Wildcards and opt-in have never really mixed. > I think that's significant to get it's own section. You keep saying that, and I continue to not understand what you are talking about. If there is an unaddressed problem with wildcards in the current draft, please bring it up. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 13:56:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyY5W-0004VS-SF for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 13:56:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyY5V-0000Re-Gu for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 13:56:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyY3n-00081Z-GU for namedroppers-data@psg.com; Thu, 06 Jul 2006 17:54:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyY3m-00081I-S2 for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 17:54:43 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k66HsaUO022063 for ; Thu, 6 Jul 2006 13:54:36 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060706132715.036b2628@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Jul 2006 13:29:41 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT-66 Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Sorry for the late inclusion of the agenda but it has been uploaded to the meeting web site at: http://www3.ietf.org/proceedings/06jul/agenda/dnsext.html Main items on the agenda are NSEC3, Key Rollover With some additional items DNAME-bis and RFC2929-bis and if there is time Eastlake-cookies draft. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 15:20:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZP4-0005e0-1w for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 15:20:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZP1-0007Em-Or for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 15:20:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyZLN-000EDi-1r for namedroppers-data@psg.com; Thu, 06 Jul 2006 19:16:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyZLM-000EDT-En for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 19:16:56 +0000 Received: from [10.31.32.89] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k66JGj4S022404; Thu, 6 Jul 2006 15:16:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> Date: Thu, 6 Jul 2006 15:16:53 -0400 To: IETF DNSEXT WG From: Edward Lewis Subject: Re: Advance request for opt-in and experiments Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 13:47 -0400 7/6/06, David Blacka wrote: >You keep saying that, and I continue to not understand what you are talking >about. If there is an unaddressed problem with wildcards in the current >draft, please bring it up. http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 15:45:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZnL-0007BI-0i for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 15:45:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZnJ-0001Uo-Mv for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 15:45:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyZl6-000Gch-Ju for namedroppers-data@psg.com; Thu, 06 Jul 2006 19:43:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyZl5-000GZf-VL for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 19:43:32 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k66JgoPU022601 for ; Thu, 6 Jul 2006 15:42:50 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k66JgoBN022600 for namedroppers@ops.ietf.org; Thu, 6 Jul 2006 15:42:50 -0400 (EDT) (envelope-from namedroppers) Received: from [204.61.210.70] (helo=paixhost.pch.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuuWJ-000MhC-Gv for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 17:05:07 +0000 Received: from paixhost.pch.net (paixhost.pch.net [204.61.210.70]) by paixhost.pch.net (8.12.11/8.12.11) with ESMTP id k5QH51jW027629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 10:05:02 -0700 (PDT) Date: Mon, 26 Jun 2006 10:05:01 -0700 (PDT) From: Bill Woodcock To: Eastlake III Donald-LDE008 cc: David Ulevitch , namedroppers@ops.ietf.org Subject: RE: You saw this, right? In-Reply-To: <3870C46029D1F945B1472F170D2D97900111F6A6@de01exm64.ds.mot.com> Message-ID: References: <3870C46029D1F945B1472F170D2D97900111F6A6@de01exm64.ds.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > What I was thinking was, assume you have N anycast hosts who are DNS > servers and all receive DNS queries sent to IP address ADDR-0. All are capable of receiving, but only one actually receives any specific query... > If they really all think they are just a host at address ADDR-0 and > any of these host sends out a DNS query, presumably the anycast > nature of their address would mean that the response to that query > could come back to a different one than the host which originated > the query. Ah, I see what you were getting at. In practice, one never originates a transaction with the anycast address as source. One only originates transactions from the host's unique address. In practice, the anycast service addresses are loopbacks internal to the host, while the actual physical interfaces which are used to originate transactions use the host's unique addresses. So this is never actually a problem. I suppose in the interests of thoroughness, it wouldn't hurt to explain why, so new people don't have to stub their toes on that same corner-case. -Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 16:23:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaNP-00014P-A5 for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:23:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaNP-0007We-8k for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:23:07 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyaMp-0003jg-V2 for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:22:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyaJ6-000Jy2-8a for namedroppers-data@psg.com; Thu, 06 Jul 2006 20:18:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyaIx-000JxB-JI for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 20:18:31 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 06 Jul 2006 21:18:30 +0100 X-IronPort-AV: i="4.06,214,1149462000"; d="scan'208"; a="3918015:sNHT57233016" In-Reply-To: To: namedroppers@ops.ietf.org Subject: Re: Advance request for opt-in and experiments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Thu, 6 Jul 2006 22:18:44 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/06/2006 09:18:45 PM, Serialize complete at 07/06/2006 09:18:45 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Edward Lewis wrote on 07/06/2006 09:16:53 PM: > At 13:47 -0400 7/6/06, David Blacka wrote: > > >You keep saying that, and I continue to not understand what you are talking > >about. If there is an unaddressed problem with wildcards in the current > >draft, please bring it up. > > http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html Dave's question was, 'If there is an unaddressed problem with wildcards in the current draft, please bring it up'. This is not an unaddressed problem since http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01747.html is reflected in the security considerations. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 16:23:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaNP-00014e-Of for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:23:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaNP-0007We-M3 for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:23:07 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyaMY-0003jI-9Z for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:22:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyaIy-000JxU-34 for namedroppers-data@psg.com; Thu, 06 Jul 2006 20:18:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.1.1 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyaIw-000JxC-VJ for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 20:18:31 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id 5BB0F183687 for ; Thu, 6 Jul 2006 15:18:30 -0500 (CDT) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69483-05 for ; Thu, 6 Jul 2006 15:18:30 -0500 (CDT) Received: from GLOZANO.nic.mx (unknown [200.33.1.76]) by mail.nic.mx (Postfix) with ESMTP id F2E5B18363E for ; Thu, 6 Jul 2006 15:18:29 -0500 (CDT) Message-Id: <6.2.5.6.2.20060706151708.05175080@nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Jul 2006 15:18:29 -0500 To: Namedroppers From: Gustavo Lozano Subject: Re: Recall: Key rollover Work. In-Reply-To: <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_459026945==.ALT" X-Virus-Scanned: by amavisd-new at nic.mx Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 --=====================_459026945==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:52 AM 6/27/2006 +0200, Olaf M. Kolkman wrote: >Still we new more reviewers. By having people comment and choose on >proposals we can get forward progression. My 2 cents. I reviewed the following key rollover drafts: draft-laurie-dnssec-key-distribution-02.txt draft-ietf-dnsext-trustupdate-timers-02.txt draft-ietf-dnsext-trustupdate-threshold-01.txt And also read: Vixie new RR at APEX idea draft-moreau-dnsext-takrem-dns-02.txt Not reviewed because of 5.2 of requirements draft. draft-laurie-dnssec-key-distribution-02.txt Laurie's draft is a nice idea and if the WG wants to look for out-of-band solutions to priming keys this is a serious proposal. I see scalability issues if this proposal is used as the in-band proposal and I prefer a solution that only depends on DNS infrastructure. Timers and threshold are, from my perspective, the best approaches to the problem of key rollover. I believe both drafts can be worked as the solution. I like the idea of the revocation bit in timers draft but adding a new bit to DNSKEY will require the modification of more code. I have doubts about how transparent the matching of DNSKEY by the DS record and current implementations can work if the revocation bit is introduced. Threshold will need fewer queries than timers as the drafts are currently written and I like this from my operator's perspective. If one draft is to be chosen I prefer threshold because of the previous reasoning but I could support timers if it's chosen by the WG. What I would want in future threshold draft versions: * I think that the Vixie new RR at the apex idea is interesting and it could be incorporated into threshold draft. * I would like a suggestion of M and N values so operators can take decisions on our DNSSEC zones. * Knowing if a TA was rolled because of a key compromise or a normal (scheduled) key rollover is important. If a TA was rolled because of a key compromise and I was using it as TA then I will like to make an initial key setup procedure. I don't know if this had been proposed before but we can use the hash of the key as an owner name, query for it and obtain status and other information about a specific key. This can also add a revocation feature like timers to threshold and revolvers could be able to know about past keys. Gustavo Lozano NIC Mexico --=====================_459026945==.ALT Content-Type: text/html; charset="us-ascii" At 09:52 AM 6/27/2006 +0200, Olaf M. Kolkman wrote:
Still we new more reviewers. By having people comment and choose on 
proposals we can get forward progression.

My 2 cents.

I reviewed the following key rollover drafts:
 
draft-laurie-dnssec-key-distribution-02.txt
draft-ietf-dnsext-trustupdate-timers-02.txt
draft-ietf-dnsext-trustupdate-threshold-01.txt
 
And also read:
Vixie new RR at APEX idea
 
draft-moreau-dnsext-takrem-dns-02.txt
Not reviewed because of 5.2 of requirements draft.
 
draft-laurie-dnssec-key-distribution-02.txt
Laurie’s draft is a nice idea and if the WG wants to look for out-of-band solutions to priming keys this is a serious proposal. I see scalability issues if this proposal is used as the in-band proposal and I prefer a solution that only depends on DNS infrastructure.
 
Timers and threshold are, from my perspective, the best approaches to the problem of key rollover. I believe both drafts can be worked as the solution.
 
I like the idea of the revocation bit in timers draft but adding a new bit to DNSKEY will require the modification of more code. I have doubts about how transparent the matching of DNSKEY by the DS record and current implementations can work if the revocation bit is introduced. Threshold will need fewer queries than timers as the drafts are currently written and I like this from my operator’s perspective. If one draft is to be chosen I prefer threshold because of the previous reasoning but I could support timers if it’s chosen by the WG.
 
What I would want in future threshold draft versions:
  • I think that the Vixie new RR at the apex idea is interesting and it could be incorporated into threshold draft.
  • I would like a suggestion of M and N values so operators can take decisions on our DNSSEC zones.
  • Knowing if a TA was rolled because of a key compromise or a normal (scheduled) key rollover is important. If a TA was rolled because of a key compromise and I was using it as TA then I will like to make an initial key setup procedure. I don’t know if this had been proposed before but we can use the hash of the key as an owner name, query for it and obtain status and other information about a specific key. This can also add a revocation feature like timers to threshold and revolvers could be able to know about past keys.


Gustavo Lozano
NIC Mexico --=====================_459026945==.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 17:33:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybT3-0004gE-99 for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 17:33:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZtI-0002a5-Lu for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 15:52:00 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyZnA-0003B4-NR for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 15:45:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyZkd-000GZG-3W for namedroppers-data@psg.com; Thu, 06 Jul 2006 19:43:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyZkc-000GU9-Gy for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 19:43:02 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k66JgUKY022595 for ; Thu, 6 Jul 2006 15:42:30 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k66JgUoi022594 for namedroppers@ops.ietf.org; Thu, 6 Jul 2006 15:42:30 -0400 (EDT) (envelope-from namedroppers) Received: from [204.61.210.70] (helo=paixhost.pch.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Futj0-000HOc-2g for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 16:14:10 +0000 Received: from paixhost.pch.net (paixhost.pch.net [204.61.210.70]) by paixhost.pch.net (8.12.11/8.12.11) with ESMTP id k5QGE4tM004795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 09:14:04 -0700 (PDT) Date: Mon, 26 Jun 2006 09:14:04 -0700 (PDT) From: Bill Woodcock To: Donald.Eastlake@motorola.com, David Ulevitch cc: namedroppers@ops.ietf.org Subject: Re: You saw this, right? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > Anycast accessed servers are > unlikely to be recursive servers or otherwise act as resolvers due to > the confusion that would result in getting responses to their queries > back to the right machine. Hi, Donald. We're having king of hard time figuring out what you're getting at here. Care to clarify it? -Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 06 18:30:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycMb-0004Fc-EY for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 18:30:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyadl-0008PY-2H for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:40:01 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyaUJ-00041A-E8 for dnsext-archive@lists.ietf.org; Thu, 06 Jul 2006 16:30:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyaSX-000L5r-IP for namedroppers-data@psg.com; Thu, 06 Jul 2006 20:28:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyaSW-000L5a-Us for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 20:28:25 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 06 Jul 2006 16:28:23 -0400 id 002CC2B6.44AD7267.000063CF In-Reply-To: References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Advance request for opt-in and experiments Date: Thu, 6 Jul 2006 16:28:21 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Jul 6, 2006, at 3:16 PM, Edward Lewis wrote: > At 13:47 -0400 7/6/06, David Blacka wrote: > >> You keep saying that, and I continue to not understand what you >> are talking >> about. If there is an unaddressed problem with wildcards in the >> current >> draft, please bring it up. > > http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html AFAICT, everything in that post is addressed in the current (and past) drafts. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 09:38:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyqXA-00051z-W6 for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 09:38:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyqX8-00017f-Ml for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 09:38:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyqQ4-0004OO-Uq for namedroppers-data@psg.com; Fri, 07 Jul 2006 13:30:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyqQ4-0004O8-BX for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 13:30:56 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k67DUoOb028422 for ; Fri, 7 Jul 2006 09:30:51 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Jul 2006 09:30:46 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Dear colleagues, This message starts at 3 week last call for this document ending on midnight July 30'th 2006 (Reykjavik time). The URL for the document is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt The document is a collection of different approaches to flag extensions/changes in DNSSEC. The document is a cumulative list of pros and cons as well as impact and issues for each possible mechanism. This document is to be published as Informational to capture the current knowledge of the state of art of signalling changes in the DNSSEC protocol. The document process rules in this group, require that at least 5 members of the working to state that they have read the document and support it being published. Olafur & 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. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 10:32:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrNI-0000aB-JT for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 10:32:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyrNH-0007SX-7D for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 10:32:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyrKH-0009Up-D6 for namedroppers-data@psg.com; Fri, 07 Jul 2006 14:29:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyrKG-0009Uc-NG for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 14:29:00 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k67ERoYl028697; Fri, 7 Jul 2006 10:27:50 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060707100956.03688318@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Jul 2006 10:27:46 -0400 To: Ben Laurie , David Blacka From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains Cc: Namedroppers WG In-Reply-To: <449D7785.6010105@algroup.co.uk> References: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> <449D7785.6010105@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 13:33 24/06/2006, Ben Laurie wrote: >David Blacka wrote: > > Note that solution #4 could be thought of as a special case of the NSEC3 > > hash calculation function rather than as a special NSEC3 RR. > > > > Solutions 2, 3, and 4 all have the property of having something that may > > be directly looked up by the authoritative server (either primary or > > secondary), which is known to be efficient. > >If we're going to change things, then I prefer 2. > >3 & 4 both complicate the logic for handling NSEC3 records, for no >obvious reason (to save a type code? really?). I agree with Ben that 2 sounds as the cleanest solution, but I'm partial to liking #4. #1 (having zone parameters at a random name) is unacceptable from both performance and consistency point of view. There are two uses for this information: Authorative server configuring its NSEC3 behavior, this is both to set the NSEC3 lookup parameters. The case that I keep harping on are nameservers that do not "load" the zone but look up in a database for answers. For these servers it the location of NSEC3 parameters must be known. The alternative is to FIX the parameters for each zone/all zones, but that is counters the spirit of NSEC3 design. Also keep in mind that a paranoid DNSSEC validator may want to check that the NSEC3 record it received is from the CURRENT NSEC3 chain. If this use is encouraged then zones should lower the TTL on the marker record before switch to have them flush out of caches faster. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 11:28:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysFT-0001KI-KY for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 11:28:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysFR-0005YJ-73 for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 11:28:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FysCd-000ESr-8U for namedroppers-data@psg.com; Fri, 07 Jul 2006 15:25:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FysCb-000ESA-My for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 15:25:10 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k67FO6kI001032 for ; Fri, 7 Jul 2006 11:24:06 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAioaa9b; Fri, 7 Jul 06 11:23:52 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k67E5vtU020254; Fri, 7 Jul 2006 10:05:57 -0400 (EDT) In-Reply-To: References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4CC3CF35-6035-4C0C-B64F-CC2725F9C58B@tislabs.com> Cc: "Olaf M. Kolkman" , Namedroppers Content-Transfer-Encoding: quoted-printable From: Suresh Krishnaswamy Subject: Re: Recall: Key rollover Work. Date: Fri, 7 Jul 2006 10:08:05 -0400 To: Suresh Krishnaswamy X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 My own personal "preferences" from having compared the different =20 proposals are similar to what Wouter expressed in http://ops.ietf.org/=20= lists/namedroppers/namedroppers.2006/msg00869.html. I like the revoke bit in the timers approach and I also find the =20 simplicity and statelessness of resolvers in the M-of-N approach very =20= appealing. Paul's optimization involves some amount of protocol =20 modification, so although I see the value of his approach I also see =20 its usefulness being somewhat blurred by this. TAKREM's support for =20 reconnections after minor offline periods and its ability to allow =20 inspection of past trust anchors is useful, but then again I don't =20 see this feature out-weighing the IPR issue. IMHO a combination of M-of-N and the revoke feature in the timers =20 approach would be ideal (if this is indeed possible and the authors =20 are willing to combine these). If not, I'd be in favour of the timers =20= approach simply because of the revoke feature and the ability to =20 signal and recover from compromise. In the latter approach, the add =20 hold-down timer is useful, but as Mike says in his draft, it "mitigate=20= [s] but [does] not completely solve" the problem of an attacker using =20= a compromised key to add a new key. I think to keep the rollover =20 component simple at the resolver, the add hold-down feature can go =20 and something akin to the priming key can be used instead. I also feel that "stale" trust anchors will likely play a more =20 important part in practice than we seem to be willing to admit. My =20 personal preference is to also see Ben's approach standardized as one =20= way to solve the problem of initial distribution of priming keys. Suresh On Jun 28, 2006, at 6:12 PM, Suresh Krishnaswamy wrote: > > On Jun 27, 2006, at 3:52 AM, Olaf M. Kolkman wrote: > >> >> Note that Alberto Mart=EDnez Herrera's comparison is still available =20= >> at: >> http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf >> >> I recall there is a second comparison but I cannot find it. > > > The table at http://www.dnssec-tools.org/docs/trust-anchor-=20 > comparison-v02.htm may also be useful. > > Suresh > (on behalf of myself) > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org =20 > with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 11:28:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysFl-0001Kg-RA for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 11:28:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysFk-0005ZD-E8 for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 11:28:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FysDq-000EZ1-Nt for namedroppers-data@psg.com; Fri, 07 Jul 2006 15:26:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FysDp-000EYP-IZ for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 15:26:25 +0000 Received: from [10.31.32.89] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k67FQDV7028998; Fri, 7 Jul 2006 11:26:14 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> Date: Fri, 7 Jul 2006 11:26:11 -0400 To: IETF DNSEXT WG From: Edward Lewis Subject: Re: Advance request for opt-in and experiments Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a At 16:28 -0400 7/6/06, David Blacka wrote: >On Jul 6, 2006, at 3:16 PM, Edward Lewis wrote: > >> At 13:47 -0400 7/6/06, David Blacka wrote: >> >>> You keep saying that, and I continue to not understand what you are talking >>> about. If there is an unaddressed problem with wildcards in the current >>> draft, please bring it up. >> >> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html > >AFAICT, everything in that post is addressed in the current (and past) drafts. (I've had this reply open for quite a few hours now...) 1) The original question was "where was the discussion." That's a procedural question, not really important to the science of this, but Sam seemed to be picking on such a large change to a WG document without a WG mention of it. Of course, raising this is like me trying to deflect the discussion at hand. I don't mean to do that, but it's what has led us into this. 2) I've said it earlier that I have no problem with this as an experimental document, although I have reservations still if this will be a good thing. In the spirit of "it's never too late to make a comment on a topic, but it's too late to comment on a document" what is being said here ought not delay the document - especially because it is experimental. I'm not saying that experimental has a lower bar, but, it's that I really am not yet sold on *whether there is a problem* with opt-in. 3) Okay, here's the new material. There's been the discussion of wild cards and opt-in for a while. (Yeah, I know there have been replies saying "it's a non issue" but I still don't agree.) But here's a thought based on what's come up in the time since the above thread and now. We say that only delegations can be opt-ed out. We also say that you can't wild card NS sets - or rather we say you shouldn't think about doing it. That's what's in the wcard to-be-RFC. So, in a way, the conflict between wild cards and opt-in has been deflected. But then I began thinking about the comment "Note that being able to add a delegation is functionally equivalent to being able to add any record type" that appears in the draft. Well, maybe it's functionally equivalent, but a verifier can detect this, so maybe another non-issue. So, maybe the non-conflict still holds. OTOH, this could be a can of worms. Ultimately, all of this is supposed to be for the benefit of the resolver/client/verifier. If a response returns an unsigned delegation, does a proper answer include proof that there is no appropriate wild card? Given that we are on an IETF-eve, maybe we can talk about this next week. It's also probably in the document details and I've missed it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 13:53:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyuWX-0000JE-Gg for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 13:53:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyuWW-0003En-6O for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 13:53:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyuS4-0000y7-Dc for namedroppers-data@psg.com; Fri, 07 Jul 2006 17:49:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyuS3-0000xt-95 for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 17:49:15 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 07 Jul 2006 13:49:13 -0400 id 002D004E.44AE9E99.00007C93 In-Reply-To: References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <008DAD0C-58F5-4424-AD86-F87B6A817CD2@verisignlabs.com> Cc: IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Advance request for opt-in and experiments Date: Fri, 7 Jul 2006 13:49:13 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c On Jul 7, 2006, at 11:26 AM, Edward Lewis wrote: > 3) Okay, here's the new material. > > There's been the discussion of wild cards and opt-in for a while. > (Yeah, I know there have been replies saying "it's a non issue" but > I still don't agree.) But here's a thought based on what's come up > in the time since the above thread and now. > > We say that only delegations can be opt-ed out. We also say that > you can't wild card NS sets - or rather we say you shouldn't think > about doing it. That's what's in the wcard to-be-RFC. So, in a > way, the conflict between wild cards and opt-in has been deflected. > But then I began thinking about the comment "Note that being able > to add a delegation is functionally equivalent to being able to add > any record type" that appears in the draft. Well, maybe it's > functionally equivalent, but a verifier can detect this, so maybe > another non-issue. So, maybe the non-conflict still holds. OTOH, > this could be a can of worms. A verifier is not required to detect this. Well, specifically, a validator isn't required to detect that there was an actual insecure delegation present. This is actually a change between opt-in-09 and earlier drafts. > Ultimately, all of this is supposed to be for the benefit of the > resolver/client/verifier. If a response returns an unsigned > delegation, does a proper answer include proof that there is no > appropriate wild card? No. This is why section 8 talks about being able to replace a positive wildcard response with a spoofed unsigned delegation, or vice-versa. If there were proof that there was no appropriate wildcard, that would suggest that the wildcard would match before the delegation, which isn't true. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 14:39:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvEF-00005N-2Y for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 14:39:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyvEC-0007H9-Lt for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 14:39:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyvBS-00063Y-VK for namedroppers-data@psg.com; Fri, 07 Jul 2006 18:36:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyvBS-00063G-6f for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 18:36:10 +0000 Received: from [10.31.32.89] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k67IZwD8029860; Fri, 7 Jul 2006 14:35:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <008DAD0C-58F5-4424-AD86-F87B6A817CD2@verisignlabs.com> References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> <008DAD0C-58F5-4424-AD86-F87B6A817CD2@verisignlabs.com> Date: Fri, 7 Jul 2006 14:31:22 -0400 To: IETF DNSEXT WG From: Edward Lewis Subject: Re: Advance request for opt-in and experiments Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 13:49 -0400 7/7/06, David Blacka wrote: It's not so much a matter whether a verifier is required to do something (it's all up to local policy after all) but whether the verifier is presented with the data to make the (or any) question decidable. >If there were proof that there was no appropriate wildcard, that would suggest >that the wildcard would match before the delegation, which isn't true. Now I recall that debate...existence vs. security. Yes, if there is a genuine opt-out delegation in the zone then there's no wild card that comes into play. But in this case, if what we are "defending" against is someone inserting an opted-out delegation, then showing that there's no applicable wild card is the data needed to disambiguate between malicious behavior and a regular answer. Sure, the proof that there's no wild card can be stripped out. But so long as the verifier is in the state of not seeing what should be there, it'll know to be suspicious. Of course, if there is no wild card and someone is spoofing unsecured delegations, they all they need to do here is to replay the proof of no wild card and shove it into the forged response. Not too hard to do, so maybe it isn't of any value. Worse yet, a false sense of security and all. But then again, if there is a wild card, then the attacker would have to forge the proof there is none, so maybe it's useful after all. Every time I think this is all covered, another problem slips out. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 16:07:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fywby-0002BY-UE for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 16:07:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fywby-0000SQ-SA for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 16:07:38 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fywbx-0002Qg-BB for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 16:07:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FywZh-000EaD-Ch for namedroppers-data@psg.com; Fri, 07 Jul 2006 20:05:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FywZg-000Ea2-NV for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 20:05:16 +0000 Received: from [10.31.32.89] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k67K54tP030293; Fri, 7 Jul 2006 16:05:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <0F300C40-3AED-45B3-BF66-E5277BBD3A5E@verisignlabs.com> References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> <008DAD0C-58F5-4424-AD86-F87B6A817CD2@verisignlabs.com> <0F300C40-3AED-45B3-BF66-E5277BBD3A5E@verisignlabs.com> Date: Fri, 7 Jul 2006 16:05:00 -0400 To: David Blacka From: Edward Lewis Subject: Re: Advance request for opt-in and experiments Cc: Edward Lewis , IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.1 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At 15:47 -0400 7/7/06, David Blacka wrote: >You cannot defend against someone inserting an opted-out delegation. >That is one of the main properties of opt-in. From the validator's point of >view, there is no discernible difference between a real opt-out delegation >and a spoofed one. You can never defend against someone attempting an attack, that's true. The question is whether it is possible to arrange the protocol to indicate the difference, and I think the answer is no. But... >By going down this path, you would make wildcards and opt-in completely >incompatible. How so? >No, I think that you just aren't accepting the opt-in tradeoff. Of course not, I don't like tradeoffs. So I'm resisting until I'm convinced it isn't a tradeoff but a necessary solution. However, your reply isn't addressing what I think can be solved - the conflict between having a signed wild card in the zone and some spoofing in an answer. The spoofed referral shouldn't be able to trump a signed answer, or signed no data answer. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 17:20:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyxkp-0004O1-2g for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 17:20:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyxkn-0008Ao-NQ for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 17:20:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fyxhd-000Kra-Df for namedroppers-data@psg.com; Fri, 07 Jul 2006 21:17:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fyxhc-000KrN-MQ for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 21:17:32 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 07 Jul 2006 17:17:31 -0400 id 002D000E.44AECF6B.00003CFA In-Reply-To: References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> <008DAD0C-58F5-4424-AD86-F87B6A817CD2@verisignlabs.com> <0F300C40-3AED-45B3-BF66-E5277BBD3A5E@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18BDBCC7-BBB9-4FE2-99B5-F58A2453928C@verisignlabs.com> Cc: IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Advance request for opt-in and experiments Date: Fri, 7 Jul 2006 17:17:32 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 On Jul 7, 2006, at 4:05 PM, Edward Lewis wrote: > At 15:47 -0400 7/7/06, David Blacka wrote: > >> You cannot defend against someone inserting an opted-out delegation. >> That is one of the main properties of opt-in. From the >> validator's point of >> view, there is no discernible difference between a real opt-out >> delegation >> and a spoofed one. > > You can never defend against someone attempting an attack, that's > true. That isn't what I meant. > The question is whether it is possible to arrange the protocol to > indicate the difference, and I think the answer is no. The answer is no. > But... > >> By going down this path, you would make wildcards and opt-in >> completely >> incompatible. > > How so? 1. You cannot tell the difference between a spoofed opt-in delegation and a real one. 2. You propose for the validator to check for proof that no wildcard could have matched when validating an opt-out referral. 3. But, there is no difference between the spoofed case and the real case (see #1). 4. Thus, if there is a wildcard in an opt-in zone, then you cannot have any insecure opt-out delegations, since you won't be able to prove that the wildcard shouldn't have matched. That is, if your proposal will block a spoofed referral, it will also block a real one. >> No, I think that you just aren't accepting the opt-in tradeoff. > > Of course not, I don't like tradeoffs. So I'm resisting until I'm > convinced it isn't a tradeoff but a necessary solution. This is a natural consequence of what opt-in is. Within the opt-in span, an attacker can (by spoofing) insert a name. That spoofed name may be used to block the expression of the wildcard. Within an opt- in span, an attacker can remove insecure names, allowing the wildcard to be expressed. The attacker can do this because of what an opt-in span *means*. It means that insecure names are not proven to exist or not exist. > However, your reply isn't addressing what I think can be solved - > the conflict between having a signed wild card in the zone and some > spoofing in an answer. The spoofed referral shouldn't be able to > trump a signed answer, or signed no data answer. I think that this is all adequately described in section 8 of the draft. However, the statement "The spoofed referral shouldn't be able..." is exactly what I was talking about when I said that you just haven't accepted the opt-in tradeoffs. In your mind it shouldn't, but with opt-in it can, and the fact that it can is documented as a tradeoff. So, I don't see this as a *conflict* but as a caveat. It isn't that opt-in prevents you from using a wildcard, it is that you don't get the same security guarantees with wildcards as you do with normal signed authoritative data. You are, of course, free to invent some alternative proposal that has the properties you want. Opt-in has the properties that it does because of the approach it took. If you want different properties, I think that you are going to need a different approach. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 17:25:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyxp3-0004eL-8h for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 17:25:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyxp1-0008H6-Ug for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 17:25:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyxnZ-000LB8-21 for namedroppers-data@psg.com; Fri, 07 Jul 2006 21:23:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyxnY-000LAv-Hy for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 21:23:40 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k67LNchC008810; Fri, 7 Jul 2006 14:23:38 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 14:23:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Advance request for opt-in and experiments Date: Fri, 7 Jul 2006 14:23:37 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6041@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Advance request for opt-in and experiments Thread-Index: Acah/t+8v+rlUKdNQUm9l6SkON6kEwACOqlg From: "Hallam-Baker, Phillip" To: "David Blacka" , "Edward Lewis" Cc: "IETF DNSEXT WG" X-OriginalArrivalTime: 07 Jul 2006 21:23:38.0434 (UTC) FILETIME=[9CB8E220:01C6A20B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Blacka > No, I think that you just aren't accepting the opt-in tradeoff. I think that what he is doing is asserting that the group should = determine whether the tradeoff is acceptable for all parties and for all = time rather than leaving this judgement to the people actually = responsible for the infrastructure in question. At present DNS is not secured in any shape or form and that is a = problem. As an intended consumer of the security provided by DNSSEC I would = prefer the group to stop arguing over the terms on which parties are to = be graceously permitted to deploy. After ten years the group still = thinks of its role as a gatekeeper and not as it should do as an = advocate. Given the current state of deployment the response to any proposal = intended to accelerate deployment should be 'that will do nicely' and = not 'we will think about it'. It will be at least a decade before the type of problems being discussed = here are going to represent the weakest link in DNS. If this does happen = we know how to fix them. If people are genuinely concerned about the state of DNSSEC security = then they should start work on the practices issues surrounding the = registration process. That discussion cannot start until this set of = discussions is concluded. There has been enough discussion of OPT-IN to issue an Experimental RFC. = -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 17:29:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyxtT-0004iO-V9 for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 17:29:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FywOn-0007le-NG for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 15:54:01 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FywLx-00020s-0v for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 15:51:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FywIs-000Cib-E4 for namedroppers-data@psg.com; Fri, 07 Jul 2006 19:47:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FywIr-000Ci6-R0 for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 19:47:53 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 07 Jul 2006 15:47:52 -0400 id 002D000E.44AEBA68.000024FD In-Reply-To: References: <67718B71-D211-4750-BAB9-01CF73CCBCFB@verisignlabs.com> <008DAD0C-58F5-4424-AD86-F87B6A817CD2@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F300C40-3AED-45B3-BF66-E5277BBD3A5E@verisignlabs.com> Cc: IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Advance request for opt-in and experiments Date: Fri, 7 Jul 2006 15:47:52 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab On Jul 7, 2006, at 2:31 PM, Edward Lewis wrote: > At 13:49 -0400 7/7/06, David Blacka wrote: > > It's not so much a matter whether a verifier is required to do > something (it's all up to local policy after all) but whether the > verifier is presented with the data to make the (or any) question > decidable. > >> If there were proof that there was no appropriate wildcard, that >> would suggest >> that the wildcard would match before the delegation, which isn't >> true. > > Now I recall that debate...existence vs. security. > > Yes, if there is a genuine opt-out delegation in the zone then > there's no wild card that comes into play. But in this case, if > what we are "defending" against is someone inserting an opted-out > delegation, then showing that there's no applicable wild card is > the data needed to disambiguate between malicious behavior and a > regular answer. You cannot defend against someone inserting an opted-out delegation. That is one of the main properties of opt-in. From the validator's point of view, there is no discernible difference between a real opt- out delegation and a spoofed one. > Sure, the proof that there's no wild card can be stripped out. But > so long as the verifier is in the state of not seeing what should > be there, it'll know to be suspicious. By going down this path, you would make wildcards and opt-in completely incompatible. > Of course, if there is no wild card and someone is spoofing > unsecured delegations, they all they need to do here is to replay > the proof of no wild card and shove it into the forged response. > Not too hard to do, so maybe it isn't of any value. Worse yet, a > false sense of security and all. But then again, if there is a > wild card, then the attacker would have to forge the proof there is > none, so maybe it's useful after all. > > Every time I think this is all covered, another problem slips out. No, I think that you just aren't accepting the opt-in tradeoff. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 18:36:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyyva-0006ve-U5 for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 18:36:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyyvZ-0000Bw-ER for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 18:36:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fyyrt-0000X3-N1 for namedroppers-data@psg.com; Fri, 07 Jul 2006 22:32:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fyyrs-0000Wq-Q1 for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 22:32:13 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k67MW96l015434 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 Jul 2006 18:32:09 -0400 Date: Fri, 7 Jul 2006 18:32:08 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: iesg@ietf.org cc: IETF DNSEXT WG Subject: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 IESG and DNSEXT WG: Summary Last Call Comment requested by Mark Townsley. I object strongly to the draft as it is currently worded. Several versions of part of section 3.1 were discussed at the last minute, and these discussions resulted in a new draft version that was immediately submitted to the IESG Last Call without further WG review. Due to confusion over which version the wording, a different text was put in the final document from that which many people supported or accepted. WG Chair Olaf Kolkman has acknowledged confusing references and acknowledged some responsibility for the confusion. http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00830.html [It is not asserted that Mr. Kolkman did anything nefariously wrong, but the WG was confused and a mistake was made.] These are the changes that need to be made: In the first paragraph of Section 3.1, use this wording: 3.1. The NSID Payload The syntax and semantics of the content of the NSID option is deliberately left outside the scope of this specification. It is the prerogative of the server administrator to choose the NSID content as long as the content is unique to each anycast instance so that a remote user is able to match the NSID to the server instance over a series of queries. The NSID can be opaque and encoded such that it can be decoded by the server adminstrator to provide more information. This section describe some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind choosing a simple opaque byte string. Delete this text from Section 3.1: o It could be some sort of dynamicly generated identifier so that only the name server operator could tell whether or not any two queries had been answered by the same server. I think that presently 7 of 10 in the DNSEXT WG who previously commented on the spoofing issue now either support or at least accept the proposed wording change: Matt Larson can accept either version, but seems to prefer slightly my version. Quoting Koch's text, he says he can accept it, but prefers the original text (which I think means my text). Alex Bligh does not think there should be a prohibition on opaque NSID (i.e. in am in favour of removing the prohibition), but does not think the ability to use them needs to be expressly authorised in the standard (does not objecting to it doing so per se, I just think its otiose and understands the argument that we shouldn't be seen to encourage it). [the new proposed change does not prohibit opaque NSID, but requires that it be unique per anycast instance. -Dean] William Leibzon is also not convinced by the DOS argument, and asks for the DOS attack to be better explained and added to the Security Considerations section. John Dickinson seems to agree with Peter Koch, but notes that spoofing is a policy decision that has nothing to do with the protocol. It seems he could be happy without it in the standard. And it was my impression that Olaf Kolkman agreed spoofing should not be in the standard, though perhaps his mind was changed... Andrew Sullivan is not for spoofing. "To be clear, I am not "for spoofing". I think I've said enough on the topic, however, so I won't re-hash my arguments here." And of course, I (Dean Anderson) strongly object to the spoofing text. Strongly for spoofing: Peter Koch Ed Lewis geoff@nominet.org.uk My objection with the document is that the the language in section 3.1 permits operators to obscure the existance an anycast instance while in full compliance with the standard. I think one should not be able to do this. Being able to prevent identification of anycast instances subverts the purpose of the draft. The only reason put forward for this facility was a vague concern that identifying the number of anycast instances could (vaguely somehow) assist a DOS attack. This rationale was never explained, and there is no evidence that this would happen. If it did happen, of course, NSID could be turned off by server query authorization controls, just as AXFR, recursion, etc are now controlled. So the DOS attack concern seems to be adequately addressed by conventional methods. Plainly, those who want to do spoofing, and aren't compelled to comply strictly with the standard, will do spoofing regardless of the standard. There are many examples of such spoofing: for example TCP signature spoofing, etc. While one might anticipate this activity "in the wild", there is no need to specify it in a standard. As Alex Bligh noted, it is otiose to do so. The only reason I can see for this feature is to obstruct testing of DNS Root Anycast; Testing which will further demonstrate the unsafe nature of stateful anycast. One might also foresee that (at least) RSOs might be prohibited from operating Anycast, and that this spoofing facility would make it difficult to catch non-compliance. Furthermore, including spoofing in the standard creates much more effort to require RSOs to not use spoofing. [this fact by itself seems to militate that this is an inappropriate effort by certain operators, who have already demonstrated some extraordinary nefarious efforts on the subject of DNS anycast] This spoofing ability is contrary to the requirements discussed by the RSSAC and elsewhere regarding the need to identify anycast server instances. It does not belong in this document. This ability to obscure anycast is nefarious in light of the extraordinary efforts to silence discussion of the scientific fraud and to subvert the process in several instances, as described previously to the IESG. Dean Anderson Av8 Internet, Inc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 19:00:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyzJb-00036A-Dy for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 19:00:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyzJa-0002U4-2H for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 19:00:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyzHS-0002Qj-QE for namedroppers-data@psg.com; Fri, 07 Jul 2006 22:58:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyzHS-0002QX-8B for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 22:58:38 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k67MwFYI021543; Fri, 7 Jul 2006 22:58:15 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k67MwF59021542; Fri, 7 Jul 2006 22:58:15 GMT Date: Fri, 7 Jul 2006 22:58:15 +0000 From: bmanning@vacation.karoshi.com To: "dr. W.C.A. Wijngaards" Cc: Namedroppers Subject: Re: Trust anchor rollover review Message-ID: <20060707225815.GA21509@vacation.karoshi.com.> References: <44A288E8.9060605@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A288E8.9060605@nlnetlabs.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 greetings... I'd like to note that for those folks who would like to have a sidebar discussion on keyrollover considerations, i've arrainged to have a room (513F) available monday 10july2006 from 13:00-15:00 (and perhaps later) to get inputs on what should become at least one revised ID. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 07 19:17:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyzZf-0005J5-Hp for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 19:17:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyzZe-0002x9-8p for dnsext-archive@lists.ietf.org; Fri, 07 Jul 2006 19:17:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyzXy-0003zK-79 for namedroppers-data@psg.com; Fri, 07 Jul 2006 23:15:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyzXx-0003z6-RH for namedroppers@ops.ietf.org; Fri, 07 Jul 2006 23:15:41 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FyzXx-0005Ce-0M; Fri, 07 Jul 2006 19:15:41 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 5FE9013744; Fri, 7 Jul 2006 19:15:26 -0400 (EDT) Date: Fri, 7 Jul 2006 19:15:26 -0400 From: Andrew Sullivan To: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) Message-ID: <20060707231526.GC31919@dba3> Reply-To: Andrew Sullivan References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Fri, Jul 07, 2006 at 06:32:08PM -0400, Dean Anderson wrote: > > I think that presently 7 of 10 in the DNSEXT WG who previously commented > on the spoofing issue now either support or at least accept the proposed > wording change: [ . . . ] > Andrew Sullivan is not for spoofing. "To be clear, I am not "for > spoofing". I think I've said enough on the topic, however, so I won't > re-hash my arguments here." It appears to me that my statements are being (presumably accidentally) misrepresented. My position is that I am not "for spoofing". That does not entail in any way that I support the formulation Mr Anderson is arguing for. It seems to me to be a little emotionally charged to suggest that those who are opposed to the importation of policy into a protocol are "for spoofing". Best regards, A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 02:40:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz6U4-0003Iw-Tr for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 02:40:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz6U2-000618-AJ for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 02:40:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz6PA-000FEF-P5 for namedroppers-data@psg.com; Sat, 08 Jul 2006 06:35:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz6PA-000FDP-0R for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 06:35:04 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k686Z00q073667; Sat, 8 Jul 2006 08:35:00 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <4CC3CF35-6035-4C0C-B64F-CC2725F9C58B@tislabs.com> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <4CC3CF35-6035-4C0C-B64F-CC2725F9C58B@tislabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-50-87124685" Message-Id: <040329AB-DC69-4BFC-AB14-85ED7D7E330E@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Recall: Key rollover Work. Date: Sat, 8 Jul 2006 08:34:59 +0200 To: Suresh Krishnaswamy X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-50-87124685 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 7, 2006, at 4:08 PM, Suresh Krishnaswamy wrote: > IMHO a combination of M-of-N and the revoke feature in the timers > approach would be ideal (if this is indeed possible and the authors > are willing to combine these). To be precise; it is not the authors that need to be willing, it is the working group. Obviously we would need the authors/editors to be responsive to the wg needs. Anyway, there needs to go some thinking into putting revoke into an M- N like approach. Any engineer that wants to put their mind to that. Is it feasible? How does the state diagram look? &c, &c... Oh, Suresh, thanks for reviewing. :-) --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-50-87124685 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEr1IUtN/ca3YJIocRAqvkAJ4gbJV+scAWma/07HokZBJFToZtKQCgnfva pMCWfgtgEHDDLQ2FtAgbPbQ= =xRis -----END PGP SIGNATURE----- --Apple-Mail-50-87124685-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 05:15:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz8uW-0005Fk-WE for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 05:15:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz8uV-00042d-Mu for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 05:15:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz8r5-0002Hi-Fh for namedroppers-data@psg.com; Sat, 08 Jul 2006 09:12:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz8r4-0002HW-TK for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 09:12:03 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D00C4C2DA5; Sat, 8 Jul 2006 10:12:01 +0100 (BST) Date: Sat, 08 Jul 2006 10:11:55 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Dean Anderson , iesg@ietf.org Cc: IETF DNSEXT WG , Alex Bligh Subject: Re: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) Message-ID: <9D894AEA0881EE7CB3E33DC0@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d --On 07 July 2006 18:32 -0400 Dean Anderson wrote: > Alex Bligh does not think there should be a prohibition on opaque NSID > (i.e. in am in favour of removing the prohibition), but does not think > the ability to use them needs to be expressly authorised in the standard > (does not objecting to it doing so per se, I just think its otiose and > understands the argument that we shouldn't be seen to encourage it). > [the new proposed change does not prohibit opaque NSID, but requires > that it be unique per anycast instance. -Dean] While the above is true, I did also (I think) point out that despite the fact that particular bit of draft-ietf-dnsext-nsid wasn't how I would have phrased it myself, I was happy with the document going forward in the current form, that being the nature of compromise, as all the document has now in my view is "a few unnecessary words". I thought this was perhaps evident from my original contribution, which was to say that we should NOT prohibit opaque NSID (what Dean calls spoofing) though we need not encourage it. In any case, I think the point is sufficiently minor that it doesn't merit going back to the w/g, and for the record I think Olaf made the right call. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 06:51:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAPh-0000Ca-UL for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 06:51:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzAPg-00039r-LS for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 06:51:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzALv-000AGT-GG for namedroppers-data@psg.com; Sat, 08 Jul 2006 10:47:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzALs-000AGA-PT; Sat, 08 Jul 2006 10:47:56 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 08 Jul 2006 11:47:51 +0100 X-IronPort-AV: i="4.06,219,1149462000"; d="scan'208"; a="4397659:sNHT30776220" In-Reply-To: To: Dean Anderson Cc: iesg@ietf.org, IETF DNSEXT WG , owner-namedroppers@ops.ietf.org Subject: Re: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Date: Sat, 8 Jul 2006 11:48:02 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/08/2006 11:48:04 AM, Serialize complete at 07/08/2006 11:48:04 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Dean Anderson wrote on 2006-07-07 23:32:08: > Strongly for spoofing: > Peter Koch > Ed Lewis > geoff@nominet.org.uk To be clear, I'm persuaded there are "legitimate", non-detrimental uses for returning encrypted responses containing values that don't persist between responses. The term "spoofing" probably inaccurately characterises these uses. I'm very reluctantly responding to your most recent message, but I fear that if I (and others) remain silent, that some observers with incomplete information may interpret this as acquiescence, or -- worse -- agreement, to your charactarisations. Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 11:42:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzEwU-0005oW-G4 for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 11:42:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzEwT-000679-7T for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 11:42:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzEqN-0008kI-4y for namedroppers-data@psg.com; Sat, 08 Jul 2006 15:35:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzEqM-0008k4-Gl for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 15:35:42 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k68FZdYI026785; Sat, 8 Jul 2006 15:35:39 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k68FZboI026784; Sat, 8 Jul 2006 15:35:37 GMT Date: Sat, 8 Jul 2006 15:35:37 +0000 From: bmanning@vacation.karoshi.com To: dnssec-app@lists.cafax.se, namedroppers@ops.ietf.org, dnssec-deployment@shinkuro.com Cc: bmanning@vacation.karoshi.com Subject: [Re: Applications/API meeting during IETF-66] Message-ID: <20060708153537.GA26706@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 so... tuesday 11jul2006 in room 513F from 0900-1130 at least a few folks will be present to talk about DNSSEC application/API issues and likely, Suresh's draft(s) --bill ----- Forwarded message from bmanning@vacation.karoshi.com ----- To: Suresh Krishnaswamy Cc: bmanning@vacation.karoshi.com Subject: Re: Applications/API meeting during IETF-66 tuesday morning - 0900-1130 is open. >On Thu, Jul 06, 2006 at 08:52:42AM -0400, Suresh Krishnaswamy >wrote: >Bill, > >Wondering if there is any time slot available in your meeting room >for holding the Applications/API discussion... > >Thanks! >Suresh ----- End forwarded message ----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 12:03:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFHD-00022f-Go for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 12:03:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzFHA-0000WP-Vl for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 12:03:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzFFO-000Aqo-Gb for namedroppers-data@psg.com; Sat, 08 Jul 2006 16:01:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,HTML_30_40,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzFFL-000AqX-DA for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 16:01:31 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k68G1JFp042041; Sat, 8 Jul 2006 12:01:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD6041@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37BD6041@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Sat, 8 Jul 2006 11:57:00 -0400 To: "IETF DNSEXT WG" From: Edward Lewis Subject: RE: Advance request for opt-in and experiments Cc: "David Blacka" , "Edward Lewis" Content-Type: multipart/alternative; boundary="============_-1059748005==_ma============" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 --============_-1059748005==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 14:23 -0700 7/7/06, Hallam-Baker, Phillip wrote: >> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Blacka > >> No, I think that you just aren't accepting the opt-in tradeoff. > ... > >There has been enough discussion of OPT-IN to issue an Experimental RFC. 1) I have said that this document ought to go forward as Experimental. (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00914.html, and search for "I've said it earlier that I have no problem with this as an experimental document" 2) But experimental isn't really enough, is it? If this stuff is to be real, we want it to be on the standards track. 3) The difference between experimental and standard is that in the former there are still questions (that's why it's an experiment). If there's any expectation that something that's ready for experimental ought to never be discussed again, then is experimental being used as a way to route around the standards track? Once the RFC gets stamped as an experiment by the IESG, only then do we begin to experiment and then review the results. Otherwise, why are we even bothering with this (experimental) process? By calling for an end to discussion, do you think that there's no need for an experiment and we ought to go straight to standards track? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") --============_-1059748005==_ma============ Content-Type: text/html; charset="us-ascii" RE: Advance request for opt-in and experiments
At 14:23 -0700 7/7/06, Hallam-Baker, Phillip wrote:
>> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Blacka
>
>> No, I think that you just aren't accepting the opt-in tradeoff.
>
...
>
>There has been enough discussion of OPT-IN to issue an Experimental RFC.

1) I have said that this document ought to go forward as Experimental.
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00914.html, and search for "I've said it earlier that I have no problem with this as an experimental document"

2) But experimental isn't really enough, is it?  If this stuff is to be real, we want it to be on the standards track.

3) The difference between experimental and standard is that in the former there are still questions (that's why it's an experiment).

If there's any expectation that something that's ready for experimental ought to never be discussed again, then is experimental being used as a way to route around the standards track?

Once the RFC gets stamped as an experiment by the IESG, only then do we begin to experiment and then review the results.  Otherwise, why are we even bothering with this (experimental) process?

By calling for an end to discussion, do you think that there's no need for an experiment and we ought to go straight to standards track?

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get it? "fuss?")
--============_-1059748005==_ma============-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 14:38:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzHgv-000218-EC for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 14:38:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzHgr-0007RC-75 for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 14:38:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzHdT-000Mkt-8n for namedroppers-data@psg.com; Sat, 08 Jul 2006 18:34:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.226] (helo=mail6.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzHdI-000MhI-PZ for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 18:34:24 +0000 Received: by mail6.sea.safepages.com (Postfix, from userid 1012) id 7773CEC106; Sat, 8 Jul 2006 18:33:58 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.248]) by mail6.sea.safepages.com (Postfix) with ESMTP id 68DA3EBF73 for ; Sat, 8 Jul 2006 18:33:56 +0000 (GMT) Message-ID: <44AFFB06.4090606@connotech.com> Date: Sat, 08 Jul 2006 14:35:50 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers Subject: Clarifications about status of TAKREM proposal for automated TAK rollover Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Dear all: (1) The TAKREM proposal is actually made of two drafts, i.e. http://tools.ietf.org/wg/dnsext/draft-moreau-dnsext-sdda-rr-02.txt and http://tools.ietf.org/wg/dnsext/draft-moreau-dnsext-takrem-dns-02.txt (only the latter was referenced in the DNSEXT chairman message asking for comparative review of alternatives, http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00829.html). FYI, the draft draft-moreau-dnsext-sdda-rr-02 formalized TAK lifetime management somehow, e.g. with the notion of "obituary resource record." (2) The "no derivative clause" (in draft-moreau-dnsext-takrem-dns-02 only) appeared in the document almost by accident. It pertains to IETF publishing activities (IETF document versus independent RFC submission). Under the principle of "if it's not broken, don't fix it," I have no incentive to remove it at this point in the discussions. (3) The reviews of TAK rollover alternatives (more precisely the reviews of TAK rollover alternatives that the DNSEXT wg chairmen should consider for consensus building) should abide by the instructions to consider "the requirement for non-IPR as _one_ _of_ _the_ _tradeoffs_." (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00370.html), which implies that the TAKREM proposal for automated TAK rollover should be reviewed. Given the intensity of prevailing IPR-aversion, I am skeptical that this will actually occur, but the DNSEXT chairman words are at stake. In this respect, Suresh deserves credit for his comprehensive analysis in http://www.dnssec-tools.org/docs/trust-anchor-comparison-v02.htm, brought to namedroppers in http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00862.html. (4) In case someone is reluctant even to *read* a document for which an IPR claim exists, he/she might ask if such self-inflicted censorship extends to any issued patent, any publicly available patent application, and any foreign patent document for technologies in the public domain of his/her own jurisdiction. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 14:38:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzHgv-00021B-Ev for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 14:38:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzHgr-0007RD-Kb for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 14:38:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzHdF-000Miz-EI for namedroppers-data@psg.com; Sat, 08 Jul 2006 18:34:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.222] (helo=mail2.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzHdD-000Mh0-07 for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 18:34:19 +0000 Received: by mail2.sea.safepages.com (Postfix, from userid 1012) id 496DF68492; Sat, 8 Jul 2006 18:33:52 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.248]) by mail2.sea.safepages.com (Postfix) with ESMTP id 1E71E68282 for ; Sat, 8 Jul 2006 18:33:50 +0000 (GMT) Message-ID: <44AFFAFF.7010000@connotech.com> Date: Sat, 08 Jul 2006 14:35:43 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers Subject: Do any DNSEXT participants care about TAK rollover security? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Dear DNSEXT wg participants: Trust anchor Key Rollover (TAK) for DNSSEC is part of an IT security scheme. It must also by an interoperability specifications that is deeply influenced by the installed base of DNS technology. DNSEXT came up with draft-ietf-dnsext-rollover-requirements-02 as the current definition of requirements for a TAK rollover solution, but it is almost by accident that the requirement 5.13 was added in the draft to reflect the need for TAK rollover security, and even the active document editor (Suresh Krishnaswamy) seems to have difficulty with it: in http://www.dnssec-tools.org/docs/trust-anchor-comparison-v02.htm, he comments about requirement 5.13 writing "May be a policy issue (which algorithm to allow etc). How does one define degraded trustworthiness?" And then he abstain from applying requirement 5.13 to alternatives in an otherwise meticulous and interesting comparison chart. It all boils down to whether TAK rollover solutions are evaluated with or without a properly formulated security criteria. I came to the conclusion that the DNSEXT wg focuses on interoperability and DNS installed base compatibility, almost exclusively. (The draft draft-moreau-dnsext-tak-req-00 contains contributions in this direction, that were set aside completely.) Thus, the question is whether any DNSEXT participants care about security. I suggest that those who do, if any, should speak up now. Incidentally, outside of the IETF, there might be some voices calling for the criticalness of security in the DNSSEC overall solution (e.g. the presentation made by Maria Zitkova about DNSSEC deployment in the .aero sponsored TLD for the airline industry, http://www.icann.org/meetings/marrakech/captioning-DNSSEC-28jun06.htm). So, I'm in Montreal next week during the IETF 66 meeting, but I'm still skeptical about DNSEXT ability to address the automated TAK rollover issue in a productive way. In any event, enjoy your stay in this marvelous city at the right time of the year! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 17:52:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzKjA-0000MJ-8I for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 17:52:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzKj9-0006ux-LN for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 17:52:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzKfe-000Cjs-Ke for namedroppers-data@psg.com; Sat, 08 Jul 2006 21:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzKfc-000CjT-GG; Sat, 08 Jul 2006 21:49:00 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k68Lkxkx016703 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 8 Jul 2006 17:47:28 -0400 Date: Sat, 8 Jul 2006 17:46:53 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Andrew Sullivan , Alex Bligh , cc: iesg@ietf.org, IETF DNSEXT WG , Subject: Re: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 I am not against opaque NSID's: As long as the NSID is unique to the anycast instance. However, lets be clear on what spoofing means: To make the NSID different between successive query responses from the same instance is to spoof the number of instances. Indeed, the reason given for this behavior is to hide and obscure the number anycast instances to prevent DOS attackers from knowing how many there are. [though why having this knowledge would benefit the attacker was never made clear, nor was it made clear how denying this knowledge from the attacker would benefit the operator--but this was the reason given for hiding]. This is fairly and accurately described as "spoofing". Lets get our terms clear: "Opaque NSID" is ___NOT___ what "Dean calls spoofing". Lets start by getting that characterization right. Lets be very clear on that: "Opaque NSID" and "Spoofed NSIDs" are different, and have different text examples. "Opaque NSID"s are still unique to the anycast instance. "Opaque NSID"s still remain the same across queries to the same anycast instance. By contrast, "Spoofed NSID"s are not unique to the anycast instance. "Spoofed NSID"s change across subsequent queries to the same anycast instance, and fail to publicly identify the anycast instance(s) that handled a group of queries. "NSID Spoofing" is something lately added by persons associated with root server operators, in the context of a scientific fraud concerning the stability of stateful anycast, perpetrated by persons associated with root server operators, particularly RIPE NCC and ISC. The IESG is currently investigating this fraud. "NSID Spoofing" prevents outside monitoring of root servers using anycast, and prevents outside analysis of data regarding root server anycast. "NSID Spoofing" provides no other features which aren't already addressed by conventional access controls. [It seems ironic to me the my GF is currently grading a series of placement essays for incoming MIT freshmen. One of the tasks given to them is to write a "literature summary". They are given several papers with very different views on a scientific subject, and they have to write an essay summarizing what the papers say. The essay has to be interesting, readable, and accurate--in other words, a good literature summary essay. If they fail the several writing tasks given, they are placed in additional humanities and writing courses--I don't know exactly what happens but some sort of remediation is required. It seems to me this skill of "literature summary" should be developed more broadly. And indeed, there are other universities working with MIT to implement the MIT program with their incoming freshmen.] More inline. --Dean On Fri, 7 Jul 2006, Andrew Sullivan wrote: > On Fri, Jul 07, 2006 at 06:32:08PM -0400, Dean Anderson wrote: > > > > I think that presently 7 of 10 in the DNSEXT WG who previously commented > > on the spoofing issue now either support or at least accept the proposed > > wording change: > > [ . . . ] > > > Andrew Sullivan is not for spoofing. "To be clear, I am not "for > > spoofing". I think I've said enough on the topic, however, so I won't > > re-hash my arguments here." > > It appears to me that my statements are being (presumably > accidentally) misrepresented. > > My position is that I am not "for spoofing". That does not entail in > any way that I support the formulation Mr Anderson is arguing for. > It seems to me to be a little emotionally charged to suggest that > those who are opposed to the importation of policy into a protocol > are "for spoofing". "Emotionally charged"???? What does that mean? I can see what is meant by "opposing importation of policy into a protocol"--rather like Bligh's view, but I can't see any emotional relationship between this view and being "for spoofing". How can that possibly be "emotionally charged"? Perhaps you are imputing emotion where none exists? Or perhaps you are emotionally concerned about your new co-worker (Joe Abley's) involvement in the underlying scientific fraud of stateful anycast. I can see that. But I rather doubt there is any emotional relationship between these issues. nor any relevance to my summarizing your position. I originally summarized your position as supporting the spoofing text. That is, you supported the current text. You reacted to that summary by indicating that wasn't your position. So, I listed you in the other category, and now you react against that, too. It now seems you have a view in a heretofore unknown third category: Those that don't support spoofing, don't support the current text, and don't support my proposal for removing that text. In any case, what exactly are you for, or against? Please don't be vague. How is it that you are "against spoofing", but "for" the current text, which includes spoofing? If you are "against spoofing" (you wrote 'I am not "for spoofing"'), then that seems to indicate that you agree that the "spoofing" text should be removed from the draft, regardless of my "formulation". It is hard to imagine how to formulate removal differently, but I'm willing to listen to a different formulation for removal, if you have one. On Sat, 8 Jul 2006, Alex Bligh wrote: > > > --On 07 July 2006 18:32 -0400 Dean Anderson wrote: > > > Alex Bligh does not think there should be a prohibition on opaque NSID > > (i.e. in am in favour of removing the prohibition), but does not think > > the ability to use them needs to be expressly authorised in the standard > > (does not objecting to it doing so per se, I just think its otiose and > > understands the argument that we shouldn't be seen to encourage it). > > [the new proposed change does not prohibit opaque NSID, but requires > > that it be unique per anycast instance. -Dean] > > While the above is true, It should be true. You said it: ======================================================= Date: Wed, 28 Jun 2006 09:34:23 +0100 From: Alex Bligh [...] What I said (well what I meant to say) is that I do not think there should be a prohibition on opaque NSID (i.e. I am in favour of removing the prohibition), but I do not think the ability to use them needs to be expressly authorised in the standard (I'm not objecting to it doing so per se, I just think its otiose and I understand the argument that we shouldn't be seen to encourage it). Alex ======================================================= I just changed your text from first person to second person. > I did also (I think) point out that despite the fact that particular > bit of draft-ietf-dnsext-nsid wasn't how I would have phrased it > myself, I was happy with the document going forward in the current > form, that being the nature of compromise, as all the document has now > in my view is "a few unnecessary words". I thought this was perhaps > evident from my original contribution, which was to say that we should > NOT prohibit opaque NSID (what Dean calls spoofing) though we need not > encourage it. In any case, I think the point is sufficiently minor > that it doesn't merit going back to the w/g, and for the record I > think Olaf made the right call. Repeat for clarity: "Opaque NSID" is ___NOT___ what "Dean calls spoofing". Lets be clear on that: "Opaque NSID" and "Spoofed NSIDs" are different, and have different text examples. "Opaque NSID"s are still unique to the anycast instance. "Spoofed NSID"s are not unique to the anycast instance. > > Alex > > On Sat, 8 Jul 2006 geoff@nominet.org.uk wrote: > Dean Anderson wrote on 2006-07-07 23:32:08: > > > Strongly for spoofing: > > Peter Koch > > Ed Lewis > > geoff@nominet.org.uk > > To be clear, I'm persuaded there are "legitimate", non-detrimental > uses for returning encrypted responses containing values that don't > persist between responses. The term "spoofing" probably inaccurately > characterises these uses. I did summarize that. Perhaps, though, you could elaborate on what those "legitimate" uses might be. We've still not heard of any truly legitimate uses. > I'm very reluctantly responding to your most recent message, but I fear > that if I (and others) remain silent, that some observers with incomplete > information may interpret this as acquiescence, or -- worse -- agreement, > to your charactarisations. I accurately characterized your position as "for spoofing". But do agree absolutely, that if you do not agree with my characterization, then you should speak up. > > Geoff > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 18:37:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzLQO-00018o-Hk for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 18:37:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzLQO-0001bU-2J for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 18:37:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzLOL-000GaQ-J4 for namedroppers-data@psg.com; Sat, 08 Jul 2006 22:35:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_50_60,HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzLOI-000Ga9-JX for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 22:35:10 +0000 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k68MZ60v006576; Sat, 8 Jul 2006 15:35:06 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 15:35:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A2DE.C269C3D0" Subject: RE: Advance request for opt-in and experiments Date: Sat, 8 Jul 2006 15:35:04 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD607A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Advance request for opt-in and experiments Thread-Index: AcaiqDAVJpjhKThwQ9K+oDLeoU6IlwANR/UA From: "Hallam-Baker, Phillip" To: "Edward Lewis" , "IETF DNSEXT WG" Cc: "David Blacka-CR" X-OriginalArrivalTime: 08 Jul 2006 22:35:05.0796 (UTC) FILETIME=[C29A2840:01C6A2DE] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A2DE.C269C3D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not going to get into this argument. =20 The experiment will provide the data necessary to solve the argument. ________________________________ From: owner-namedroppers@ops.ietf.org = [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Edward Lewis Sent: Saturday, July 08, 2006 11:57 AM To: IETF DNSEXT WG Cc: David Blacka-CR; Edward Lewis Subject: RE: Advance request for opt-in and experiments =09 =09 At 14:23 -0700 7/7/06, Hallam-Baker, Phillip wrote: >> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Blacka > >> No, I think that you just aren't accepting the opt-in tradeoff. > ... > >There has been enough discussion of OPT-IN to issue an Experimental = RFC. 1) I have said that this document ought to go forward as Experimental. = (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00914.html, = and search for "I've said it earlier that I have no problem with this as = an experimental document" 2) But experimental isn't really enough, is it? If this stuff is to be = real, we want it to be on the standards track. 3) The difference between experimental and standard is that in the = former there are still questions (that's why it's an experiment). If there's any expectation that something that's ready for experimental = ought to never be discussed again, then is experimental being used as a = way to route around the standards track? Once the RFC gets stamped as an experiment by the IESG, only then do we = begin to experiment and then review the results. Otherwise, why are we = even bothering with this (experimental) process? By calling for an end to discussion, do you think that there's no need = for an experiment and we ought to go straight to standards track? --=20 = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - Edward Lewis = +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard = time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") ------_=_NextPart_001_01C6A2DE.C269C3D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Advance request for opt-in and = experiments
I am not going to get into this=20 argument.
 
The experiment will provide the data = necessary to solve=20 the argument.

From: = owner-namedroppers@ops.ietf.org=20 [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Edward=20 Lewis
Sent: Saturday, July 08, 2006 11:57 AM
To: = IETF=20 DNSEXT WG
Cc: David Blacka-CR; Edward = Lewis
Subject: RE:=20 Advance request for opt-in and experiments

At 14:23 -0700 7/7/06, Hallam-Baker, Phillip wrote:
>> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of = David=20 Blacka
>
>> No, I think that you just aren't accepting the opt-in=20 tradeoff.
>
...
>
>There has been enough discussion of OPT-IN to issue an = Experimental=20 RFC.

1) I have said that this document ought to go forward as=20 Experimental.
=
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00914.h= tml,=20 and search for "I've said it earlier that I have no problem with this = as an=20 experimental document"

2) But experimental isn't really enough, is it?  If this = stuff is to=20 be real, we want it to be on the standards track.

3) The difference between experimental and standard is that in = the former=20 there are still questions (that's why it's an experiment).

If there's any expectation that something that's ready for = experimental=20 ought to never be discussed again, then is experimental being used as = a way to=20 route around the standards track?

Once the RFC gets stamped as an experiment by the IESG, only then = do we=20 begin to experiment and then review the results.  Otherwise, why = are we=20 even bothering with this (experimental) process?

By calling for an end to discussion, do you think that there's no = need=20 for an experiment and we ought to go straight to standards = track?

--=20
=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Edward=20 = Lewis                               &n= bsp;         &n= bsp;     =20 +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have = a hard=20 time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get = it?=20 "fuss?")
------_=_NextPart_001_01C6A2DE.C269C3D0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 19:21:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzM76-0006r3-Dk for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 19:21:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzM74-0007n9-1k for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 19:21:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzM4m-000JfE-Cy for namedroppers-data@psg.com; Sat, 08 Jul 2006 23:19:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzM4l-000Jf1-Qs for namedroppers@ops.ietf.org; Sat, 08 Jul 2006 23:19:04 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k68NJ0YI029113; Sat, 8 Jul 2006 23:19:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k68NIv4Y029112; Sat, 8 Jul 2006 23:18:57 GMT Date: Sat, 8 Jul 2006 23:18:56 +0000 From: bmanning@vacation.karoshi.com To: Thierry Moreau Cc: Namedroppers Subject: Re: Clarifications about status of TAKREM proposal for automated TAK rollover Message-ID: <20060708231856.GA28802@vacation.karoshi.com.> References: <44AFFB06.4090606@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AFFB06.4090606@connotech.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > (4) In case someone is reluctant even to *read* a document for which an > IPR claim exists, he/she might ask if such self-inflicted censorship > extends to any issued patent, any publicly available patent application, > and any foreign patent document for technologies in the public domain of > his/her own jurisdiction. > > Regards, > > -- > > - Thierry Moreau note that the IPR claims for the -threshold & -timers came -AFTER- the drafts were published and by a third party... not the submitter of a draft. also - given Internet techologies are in every jurisdiction that I can think of, the solution needs to be unencumbered... YMMV of course. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 08 21:51:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOSO-0000to-KY for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 21:51:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzOSN-0004U1-1K for dnsext-archive@lists.ietf.org; Sat, 08 Jul 2006 21:51:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzOP7-00061Q-2S for namedroppers-data@psg.com; Sun, 09 Jul 2006 01:48:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, HEADER_SPAM,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzOP2-00060q-GQ for namedroppers@ops.ietf.org; Sun, 09 Jul 2006 01:48:12 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k691m1Le071916 for ; Sun, 9 Jul 2006 03:48:01 +0200 (CEST) (envelope-from namemod@open.nlnetlabs.nl) Received: (from namemod@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k691m1fV071915 for namedroppers@ops.ietf.org; Sun, 9 Jul 2006 03:48:01 +0200 (CEST) (envelope-from namemod) Received: from [203.187.132.2] (helo=delta.hssblr.co.in) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyO9V-0001rL-R3 for namedroppers@ops.ietf.org; Thu, 06 Jul 2006 07:20:03 +0000 Received: from pragati.blr.hss.hns.com ([10.203.193.22]) by delta.hssblr.co.in (8.13.6/8.13.6) with ESMTP id k667JZFh020125 for ; Thu, 6 Jul 2006 12:49:39 +0530 Received: from cheux004.che.flextronics.com ([10.203.112.4]) by espion.blr.hss.hns.com (Lotus Domino Release 6.5.5) with ESMTP id 2006070612490094-16792 ; Thu, 6 Jul 2006 12:49:00 +0530 Received: from CHEW0672 ([10.203.115.115]) by cheux004.che.flextronics.com (8.13.6/8.13.5) with SMTP id k6671ogU002223 for ; Thu, 6 Jul 2006 12:32:07 +0530 Reply-To: badrinath.s@flextronicssoftware.com From: Badrinath.S@flextronicssoftware.com To: Subject: Problems in DDNS Client Development for Secure Update Date: Thu, 6 Jul 2006 12:48:46 +0530 Message-ID: <00e401c6a0cc$6c2d2bb0$7373cb0a@asia.ad.flextronics.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-MIMETrack: Itemize by SMTP Server on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 07/06/2006 12:49:00 PM, Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at 07/06/2006 12:47:39 PM, Serialize complete at 07/06/2006 12:47:39 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C6A0FA.85E567B0" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This is a multi-part message in MIME format. ------=_NextPart_000_00E5_01C6A0FA.85E567B0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Hi Iam Badrinath SVN, Flextronics Software Systems Chennai, India. I am facing some problems in development of DDNS Client for secure DNS updates using MD5 and statically assigned keys both side. In RFC: 2845, Section 3.4, 1. For calculation of TSIG, we have to use whole DNS message (without Additional section and AdditionalCount decremented by 1 before digested) in network byte order or wire format. Are both network byte order or wire format same or different?? 2. In sec3.4.2, TSIG RR CLASS which is always ANY 0x00FF, is not in network byte order in calculation of TSIG??? I did not understand how to calculate the TSIG for DNS Update. When I prepared the DNS message for update, all multi octet integers are converted to network byte order using htons() and htonl(). Is that prepared message have to take for TSIG calculation??? Thanks & Regards Badrinath SVN ------=_NextPart_000_00E5_01C6A0FA.85E567B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

Hi 

 

   Iam Badrinath = SVN,=20 Flextronics Software Systems Chennai, India.

   I am facing = some=20 problems in development of DDNS Client for secure DNS updates using MD5 = and=20 statically assigned keys both side.

 

   In RFC: 2845, = Section=20 3.4,

   =

   1. For = calculation of=20 TSIG, we have to use whole DNS message (without Additional section and=20 AdditionalCount decremented by 1 before digested) in = network byte=20 order or wire format.

       Are both=20 network byte order or wire format same or=20 different??

   =20

   2. In = sec3.4.2,=20 TSIG RR CLASS which is always ANY 0x00FF, is not in network byte order = in=20 calculation of TSIG???

 

   I did not = understand=20 how to calculate the TSIG for DNS Update.

   When I = prepared the DNS=20 message for update, all multi octet integers are converted to network = byte order=20 using htons() and htonl(). Is that prepared message have to take for = TSIG=20 calculation???

 

Thanks &=20 Regards

Badrinath=20 SVN
       =
------=_NextPart_000_00E5_01C6A0FA.85E567B0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 09 15:11:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzegu-0004Mg-8X for dnsext-archive@lists.ietf.org; Sun, 09 Jul 2006 15:11:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzegt-0007d2-RL for dnsext-archive@lists.ietf.org; Sun, 09 Jul 2006 15:11:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzecG-0009aq-Gq for namedroppers-data@psg.com; Sun, 09 Jul 2006 19:06:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzecF-0009a7-1k; Sun, 09 Jul 2006 19:06:51 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Fzec4-0006vT-2A; Sun, 09 Jul 2006 15:06:40 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 33F7313744; Sun, 9 Jul 2006 15:06:24 -0400 (EDT) Date: Sun, 9 Jul 2006 15:06:24 -0400 From: Andrew Sullivan To: Dean Anderson Cc: Andrew Sullivan , Alex Bligh , geoff@nominet.org.uk, iesg@ietf.org, IETF DNSEXT WG , owner-namedroppers@ops.ietf.org Subject: Re: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) Message-ID: <20060709190624.GA4141@dba3> Reply-To: Andrew Sullivan References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Dean, I'm extremely leery of going down this conversational path, since I think I have already explained my views adequately on the WG list. But since you ask for clarification, here it is. On Sat, Jul 08, 2006 at 05:46:53PM -0400, Dean Anderson wrote: > anycast instance. However, lets be clear on what spoofing means: To > make the NSID different between successive query responses from the same > instance is to spoof the number of instances. Indeed, the reason given From my point of view, that is the meaning of "spoofing" only in your ideolect. Everywhere I ever use the term "spoofing", I use it to mean one thing pretending to be another, not one thing delivering answers to identity questions which do not confirm the identity to the asker. > "Emotionally charged"???? What does that mean? It's a term that people who study arguments (which is what I did in a previous life) use to describe the use of words that have negative connotations, when a more neutral term is available. You can read more about this issue at . For instance, in this case, the term "spoofing" suggests that the practice is some sort of malicious activity. In addition, the I-D as currently written is simply silent about the nature of the name server identifier. You could describe it more neutrally, therefore, as "strong opacity", as opposed to the "weak opacity" that you seem to want. > Perhaps you are imputing emotion where none exists? Or perhaps you are > emotionally concerned about your new co-worker (Joe Abley's) involvement > in the underlying scientific fraud of stateful anycast. I can see that. No, and I resent the _ad hominem_ attack. Please don't do that. > I originally summarized your position as supporting the spoofing text. No, you summarized my position as being "for spoofing". I am not for spoofing. I'm not sure that anyone would be in favour of spoofing. > view in a heretofore unknown third category: Those that don't support > spoofing, don't support the current text, and don't support my proposal > for removing that text. I do support the current text. It seems to me to strike the right balance of making possible a potentially desirable behaviour (where clients can figure out what node has replied to them) while yet not imposing policy decisions about how people run their servers. I might like it that people put a meaningful and consistent identifier string in there, because it might make my life easier. But protocol documents are not in the business of dictating the policies of server operators; so I am opposed to any addition to the document of anything that waters down the statement, "Choosing the NSID content is a prerogative of the server administrator." (BTW, nit: I just noticed that "choosing" there is spelled "chosing" in the document.) > In any case, what exactly are you for, or against? Please don't be > vague. How is it that you are "against spoofing", but "for" the current > text, which includes spoofing? My claim is that this document is not "for spoofing". Neither am I. This document allows server operators to set policy. I think that's a good thing. I am opposed to any changes to that. I hope this clarifies things for you. If not, I reluctantly conclude that I am unable to make my position clear to you. In either case, I will not discuss this on list any more. Best regards, A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 09 15:31:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzf00-0007GF-GQ for dnsext-archive@lists.ietf.org; Sun, 09 Jul 2006 15:31:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzezz-0001U6-Mv for dnsext-archive@lists.ietf.org; Sun, 09 Jul 2006 15:31:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzexX-000AxQ-VU for namedroppers-data@psg.com; Sun, 09 Jul 2006 19:28:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzexW-000AxB-CM for namedroppers@ops.ietf.org; Sun, 09 Jul 2006 19:28:50 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id k69JSlU9015156; Sun, 9 Jul 2006 21:28:47 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id k69JSlq10363; Sun, 9 Jul 2006 21:28:47 +0200 (MEST) Message-Id: <200607091928.k69JSlq10363@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org From: Peter Koch Subject: Re: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt In-reply-to: Your message of "Fri, 30 Jun 2006 10:35:37 EDT." <3870C46029D1F945B1472F170D2D9790011643B1@de01exm64.ds.mot.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10360.1152473318.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Sun, 09 Jul 2006 21:28:47 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Donald Eastlake wrote: > The last feedback I got from the working group on this draft was that it > was in good shape except for the need for some specific guidelines for > the designated RR type allocation expert. So this updated version has > such guidelines in section 3.1.3. Hopefully this version, or perhaps -04 as one of those asking for such guidance (and apologies for failing to send text), I am pretty much happy with what Donald came up in 3.1.3, just modulo some nits. 3.1.3 first: (nit) s/designed/Designated/ (nit) use consistent spelling of "RR TYPE" vs. "RRTYPE" > and to consult with other experts as necessary. The Expert should > reject any RRTYPE allocation request which meets the following > criterion: "which meets at least one of the following criteria" to emphazise these items are ORed. > 4. The intended use of the proposed RRTYPE would cause problems with > existing DNS deployments. add "or the DNS infrastructure" to cover cases like tree climbing. > 5. The requested RRTYPE would conflict with one under development > within the IETF and the existence of more than one such type would > harm interoperability. rephrase /harm interoperability/ to /put interoperability at risk/ to shift the burden of the proof on the requester. The template in 3.1.2 I'd like to be amended > Does the proposed RR TYPE require special handling within the > DNS different from an Unknown RR TYPE or ignorable meta-TYPE? so that a "no" would require some explanation or discussion. The document doesn't say what an "ignorable" meta type (nit: consistent spelling) is, other than > 2. The RR for which a TYPE code is being requested is either (a) a > data TYPE which can be handled as an Unknown RR as described in > [RFC 3597] or (b) a Meta TYPE who processing is optional, i.e., > which it is safe to simply discard. Would that encourage silence in response to a Meta Query? Also, if this is what makes 2929bis update 3597, could that be mentioned explicitly? Other comments, some of which may apply to text that already appeared in RFC 2929, but since this is an update attempt anyway: o The introduction and 3.2 call the DNS a database, which it isn't. Slightly change that to data store, data repository or something close. o The Opcode list in 2.2 (and one could argue that such list doesn't really belong into the policy setting document in the first place) uses mixed case for codes of QUERY, IQUERY and STATUS with a reference to RFC 1035, where that uses all caps. Same for NOTIFY and UPDATE. Could be these names are either non-normative or case insensitive (as everything else in the DNS) but some authoritative words would be fine. o Same applies to the error code list in 2.3, even more so since RFC 1035 didn't even define a mnemnonic for every code. o ``Allocation'' and ``assignment'' are used synonymously throughout the draft. Suggest to use one term (assignment) only. o bottom of page 6: ``TTL is a four octet (32 bit) [bit] unsigned integer'' o page 11: QCLASS None, the case issue again o still page 11: strictly speaking 255 is for QCLASS=*, not "any" (in any case :-) o 3.3 RR NAME Considerations this touches both label type and label content issues, so i'd suggest to rename the section to "Label Considerations" and make the split between label types (currently the 2nd paragraph) and label content. o still 3.3 > A somewhat out-of-date description of name allocation in the IN Class > is given in [RFC 1591]. Some information on reserved top level > domain names is in BCP 32 [RFC 2606]. This is kinda level 9ish, but I don't think the WG or the IETF should make a statement, however fuzzy, on how outdated RFC 1591 is (2929 said "dated"). The main point here is that there is no IETF label registry, be that TLD labels or those further down the tree (although there are proposals to change the latter). o There are normative references to experimental RFCs (1183, 2673) that are probably really informative references. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 10 08:48:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzvBr-0005B1-NB for dnsext-archive@lists.ietf.org; Mon, 10 Jul 2006 08:48:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzvBq-00032t-Ay for dnsext-archive@lists.ietf.org; Mon, 10 Jul 2006 08:48:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fzv5D-0000S2-Cn for namedroppers-data@psg.com; Mon, 10 Jul 2006 12:41:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fzv4u-0000Lk-Vo for namedroppers@ops.ietf.org; Mon, 10 Jul 2006 12:41:33 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 10 Jul 2006 13:41:23 +0100 X-IronPort-AV: i="4.06,223,1149462000"; d="scan'208"; a="3961150:sNHT31883676" In-Reply-To: To: nsec3-testing@nsec3.org Cc: namedroppers@ops.ietf.org Subject: Re: [nsec3-testing] NSEC3 Meeting at IETF 66 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Date: Mon, 10 Jul 2006 13:41:33 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/10/2006 01:41:34 PM, Serialize complete at 07/10/2006 01:41:34 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 "Geoffrey Sisson" wrote on 2006-07-08 09:51:09: > "Olaf M. Kolkman" wrote on 2006-07-08 07:17:59: > > > SIDR, IPR and DKIM all are on my list to attend... Monday is just > > very bad. > > > > Any hope to move this to a different day (such as Wed or Thur)... > > DKIM is definitely on our "must not clash" list; it's now scheduled > to meet on Tuesday and Wednesday afternoon -- at least on the most > recent publicly-available agenda. Several people have a conflict with > the Security Area Directorate open meeting on Thursday afternoon. > There _is_ a two hour stretch between DKIM and the plenary on > Wednesday afternoon, but that might be cruel and unusual? Good Morning All It turns out that the clash with SIDR affects too many people, so the NSEC3 meeting will now be today (Monday) from 15:20 to 17:20 (or longer, if required or if there is continuing interest). It will be in room 514C at the Palais. Apologies for the late announcement, but the network at the Delta Hotel was, to be kind, "uncooperative". (Okay, it was well and truly b0rked.) Hope to see you all there. Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 10 13:36:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzgU-0000by-3m for dnsext-archive@lists.ietf.org; Mon, 10 Jul 2006 13:36:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzgS-0006bj-MP for dnsext-archive@lists.ietf.org; Mon, 10 Jul 2006 13:36:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzzcE-000MZi-Cq for namedroppers-data@psg.com; Mon, 10 Jul 2006 17:32:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzzcB-000MZQ-WB for namedroppers@ops.ietf.org; Mon, 10 Jul 2006 17:32:12 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k6AHW5eg026022 for ; Mon, 10 Jul 2006 19:32:07 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-17-299350341" To: Namedroppers WG From: "Olaf M. Kolkman" Subject: Draft: updated milestones Date: Mon, 10 Jul 2006 13:32:05 -0400 X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-17-299350341 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Colleagues, Below is an updated milestones proposal. Hereby a few short comments. Trust-anchor WGLC rollover at Oct 2006 might be to ambitious if we will need to combine properties from several drafts. If combining properties from drafts is to happen than the goal is to be ready with that work well before the end of the year. NSEC3 WGLC in October may or may not be doable. Tthis depends on how fast folk that are involved in workshops can get together again. The hope is that the current NSEC3 issues list will be addressed soon. DNAME is new work. Dec 2006 for a final doc is most probably to ambitious. Some work on serial arithmetic has been done. It has not been published yet Dec 2006 may therefore be ambitious. The Jan 2007 acts as a placeholder for all the work that can/should be advanced. Around Jan 2007 we plan to see if there are folk that are interested in working actively on advancing these docs. If you spot omissions, have comments, or prefer different priorities, let the list know. After this IETF meeting week we will have a final look at these milestones and send them up. Jul 2006 Finalize trust anchor rollover requirements Jul 2006 Finalize DNSSEC transition mechanisms Aug 2006 Finalize Zone Enumeration Requirements Aug 2006 Version 0 of DNAME clarification (outlined draft) Aug 2006 Select candidate for working group output for trust anchor rollover Oct 2006 WGLC trust-anchor rollover Oct 2006 Submit KEY algorithm documents RFC253[69]bis to IESG for proposed standard Oct 2006 Version 1 of DNAME clarification Oct 2006 NSEC3 WGLC Nov 2006 draft-fleming-007-21 ready for publication Dec 2006 RFC2672bis (DNAME) to Draft Standard or revision, WGLC Dec 2006 RFC1982 (Serial Number Arithmetic) interop report Jan 2007 Submit to IESG RFC2845 (TSIG)to Draft standard Jan 2007 RFC2671bis (EDNS0) to Draft Standard Jan 2007 RFC2136bis (Dynamic Update) to Draft Standard Jan 2007 RFC3007bis (Secure Update) to Draft Standard Jan 2007 RFC1995bis (IXFR) to Draft standard Jan 2007 RFC1996bis (Notify) to Draft Standard Jan 2007 RFC2930bis (TKEY) to Draft standard Jan 2007 RFC2181bis (Clarify) to Draft Standard Jan 2007 RFC2308bis (Neg Caching) to Draft Standard Jan 2007 RFC2782bis (SRV RR) to Draft Standard Jan 2007 RFC3226 (Message Size) to Draft Done Forward NSEC rdata to IESG for Proposed Standard Done Forward RFC2535-bis to IESG for proposed standard Done Forward Case Insensitive to IESG for Proposed Standard Done Forward LLMNR to IESG for Proposed Standard Done Update boilerplate text on OPT-IN Done Forward Wildcard clarification to IESG for proposed standard Done RFC2538 (CERT RR) to Draft Standard ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-17-299350341 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEso8VtN/ca3YJIocRAnSYAKDZN9OJzPR4c5JvsXjq9M9AQwbKQACg6n+H 2okzRCUkciZ8FCk/D+I4pDI= =jOlN -----END PGP SIGNATURE----- --Apple-Mail-17-299350341-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 10 21:02:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G06eG-0004Cc-PS for dnsext-archive@lists.ietf.org; Mon, 10 Jul 2006 21:02:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G06eF-0006EI-Fb for dnsext-archive@lists.ietf.org; Mon, 10 Jul 2006 21:02:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G06aa-0006BV-NB for namedroppers-data@psg.com; Tue, 11 Jul 2006 00:59:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G06aZ-0006BJ-Go for namedroppers@ops.ietf.org; Tue, 11 Jul 2006 00:58:59 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6B0vwku016773 for ; Mon, 10 Jul 2006 20:57:58 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKCaaWG; Mon, 10 Jul 06 20:57:55 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k6ANuw23027743; Mon, 10 Jul 2006 19:56:59 -0400 (EDT) Date: Mon, 10 Jul 2006 19:58:38 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms In-Reply-To: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> Message-ID: References: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 At first glance (having looked at the diff to -03 but not fully reread the document), the comments I made in November 2005 have not been fully reflected in the document, despite, IIRC, some agreement from the editors that they were a good idea. http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01704.html In addition to the comments I sent to namedroppers, there are some editorial rough spots that I'd like to see addressed before the document is advanced. I've reminded the editors of those. Accordingly, I continue to believe that the document is not ready for WGLC. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 11 02:53:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0C7S-0002og-8O for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 02:53:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0C7R-0007M1-Nd for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 02:53:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0C3g-0002zW-Eb for namedroppers-data@psg.com; Tue, 11 Jul 2006 06:49:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0C3e-0002zF-R2; Tue, 11 Jul 2006 06:49:23 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k6B6nAdY027825 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 11 Jul 2006 02:49:11 -0400 Date: Tue, 11 Jul 2006 02:49:10 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Andrew Sullivan cc: Alex Bligh , , , IETF DNSEXT WG , Subject: Re: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) In-Reply-To: <20060709190624.GA4141@dba3> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 On Sun, 9 Jul 2006, Andrew Sullivan wrote: > Hi Dean, > > I'm extremely leery of going down this conversational path, since I > think I have already explained my views adequately on the WG list. > But since you ask for clarification, here it is. > > On Sat, Jul 08, 2006 at 05:46:53PM -0400, Dean Anderson wrote: > > > anycast instance. However, lets be clear on what spoofing means: To > > make the NSID different between successive query responses from the same > > instance is to spoof the number of instances. Indeed, the reason given > > From my point of view, that is the meaning of "spoofing" only in your > ideolect. Everywhere I ever use the term "spoofing", I use it to > mean one thing pretending to be another, not one thing delivering > answers to identity questions which do not confirm the identity to > the asker. There is very little difference in "pretending to be another" if the answer to the ___identity___question___ "does not confirm the identity." This is a trivial distinction, at best. One that does not sustain your argument, either. I notice that both "not confirming", and "pretending to be another" also covers TCP signature spoofing: The TCP signature is a question about the identity of the remote server. "TCP signature spoofing" also "does not confirm the identity". And "TCP signature spoofing" also "pretends to be another". In just exactly the same way, in fact. You are making a very strained effort at splitting hairs. > > "Emotionally charged"???? What does that mean? > > It's a term that people who study arguments (which is what I did in a > previous life) use to describe the use of words that have negative > connotations, when a more neutral term is available. You can read > more about this issue at . > > For instance, in this case, the term "spoofing" suggests that the > practice is some sort of malicious activity. Yes; In this case, that's right. But there is no exaggeration. I'm reporting substantial facts on this particular subject, which includes scientific fraud---many would consider that a 'malicious' activity. [I think your selection of 'malice' is the wrong term. I think "untoward" would be better. Neither spoofing, nor scientific fraud imply malice--an intention to harm, but both terms do suggest some kind of deceptive, inappropriate, unseemly activity. For simplicity, I'll stick with 'malicious' in place of untoward or unseemly in what follows.] > In addition, the I-D as currently written is simply silent about the > nature of the name server identifier. You could describe it more > neutrally, therefore, as "strong opacity", as opposed to the "weak > opacity" that you seem to want. Yes, the ID is silent on the nature. But that does not mean that the nature isn't 'malicious' (read unseemly). It is malicious--I'm reporting that fact to you. This feature serves no legitimate purpose, and in fact furthers a previously known malicious activity--scientific fraud. There is no exaggeration in this term. The scientific fraud has been reported to the IESG, the IESG has investigated this matter, and shortly an appeal will be made to the IAB. Other organizations will also be involved. A more neutral description would belie and hide the nature of the activity already associated with the scientific fraud by Daniel Karrenberg et al. Neither "strong opacity" nor "weak opacity" have any relevant meaning, since there is nothing "strong" nor "weak" about the differences between "Spoofed NSID" or "Opaque NSID". "strong"/"weak" is a rather artificial non-descript choice of adjectives. > > Perhaps you are imputing emotion where none exists? Or perhaps you are > > emotionally concerned about your new co-worker (Joe Abley's) involvement > > in the underlying scientific fraud of stateful anycast. I can see that. > > No, and I resent the _ad hominem_ attack. Please don't do that. Ad hominem is a logical fallacy about irrelevant personal traits. _You_ attributed emotion (a personal trait) to my argument. If there was an ad hominem, you made it. But there is no fallacy in my response that you may have imputed emotion where none exists. That is relevant to your assertion of emotion in my argument. There is also no fallacy in an assertion that you (rather than me) may be the one emotionally connected to your new coworker, who stands to lose as a result of his involvement in the fraud I have reported. This is relevant to why it is you who are emotionally connected, rather than me. I don't stand to lose anything whatsoever---I'm just reporting facts which I'm confident will stand the test of time. I've been vindicated over time before on a few controversial subjects. I've been though it several times, and have no emotional involvement, any more than a reporter for the NY Times has emotional involvement in the news. > > I originally summarized your position as supporting the spoofing > > text. > > No, you summarized my position as being "for spoofing". I am not for > spoofing. I'm not sure that anyone would be in favour of spoofing. This splits hairs, exceedingly. > > view in a heretofore unknown third category: Those that don't support > > spoofing, don't support the current text, and don't support my proposal > > for removing that text. > > I do support the current text. Then you plainly support spoofing, as most people define the term, and as most people on the WG understand the term. And plainly you are in the same group as Peter Koch and the others who I grouped in the "for spoofing" category. So your original objection was trivial. Rather than trying disassociate your position from Koch and the others, you were aiming for something else---a word-smithing??? Did you not realize your objection would be read as disassociation? You seem articulate enough to avoid that. > My claim is that this document is not "for spoofing". Neither am I. That is interesting claim, but just attempts to draw a distinction where there is none, in an effort to try to remove a well-established unseemly character from the text under discussion. We used to describe this sort of word-smithing effort as an "attempt to polish a t*rd". > This document allows server operators to set policy. I think that's > a good thing. I am opposed to any changes to that. > > I hope this clarifies things for you. If not, I reluctantly conclude > that I am unable to make my position clear to you. In either case, I > will not discuss this on list any more. > > Best regards, > A > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 11 10:06:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Iss-0006Eo-RN for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 10:06:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Iss-0001xY-PM for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 10:06:42 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0Isl-0006P9-LV for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 10:06:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0Inq-0008jG-Fq for namedroppers-data@psg.com; Tue, 11 Jul 2006 14:01:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0Inp-0008j1-Ae for namedroppers@ops.ietf.org; Tue, 11 Jul 2006 14:01:29 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k6BE1IgF054850; Tue, 11 Jul 2006 16:01:20 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-23-373103653" Message-Id: Cc: "IESG (E-mail)" Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) (fwd) Date: Tue, 11 Jul 2006 10:01:18 -0400 To: IETF DNSEXT WG X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-23-373103653 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Kind Colleagues, We are now at a point that the discussion is drifting from the original topic. The NSID document is out of the working group and I have not seen support for the view that I called rough consensus the wrong way. If you happen to support that view please speak up and motivate it, Dean has already done so. If and/or when we have push-back from the IESG this WG is done and I close this thread. thanks, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-23-373103653 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEs68vtN/ca3YJIocRAlyGAKCQ/cAvNlP679nVewTRlwHwKHFspgCgswL4 42ROK+QbdBIGFvKDIHc6F08= =9Teg -----END PGP SIGNATURE----- --Apple-Mail-23-373103653-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 11 14:04:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Mai-0002k2-Rg for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 14:04:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Mag-0005kd-Bt for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 14:04:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0MXU-000KFZ-Hq for namedroppers-data@psg.com; Tue, 11 Jul 2006 18:00:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0MXR-000KFA-DG for namedroppers@ops.ietf.org; Tue, 11 Jul 2006 18:00:49 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6BI0gXB011026 for ; Tue, 11 Jul 2006 14:00:42 -0400 Received: from gorilla ([129.6.220.65]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k6BI0Raq003900 for ; Tue, 11 Jul 2006 14:00:29 -0400 (EDT) From: "Scott Rose" To: "Namedroppers" Subject: RE: Do any DNSEXT participants care about TAK rollover security? Date: Tue, 11 Jul 2006 14:00:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44AFFAFF.7010000@connotech.com> Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Thierry Moreau > > Thus, the question is whether any DNSEXT participants care about > security. I suggest that those who do, if any, should speak up now. > FWIW, I care. I don't know if TAK is the best solution for deployment however. My main concern is unfortunately more administrative than technical. It mainly concerns the pre-generation of keys and the dead storage. I can imagine a zone could generate all the operational keys it believes it needs, but that means zone admins have to be good at predicting the future - both key sizes and changes in algorithms. Or a worst case scenario - a weakness is found in either a key algorithm or the MASH algorithm used with the scheme. In these cases, it seems the only option is to restart the process from the beginning and have every validator obtain the new information (keys, hashes, etc). Much like an emergency rollover, but any validator off line for an extended period of time may miss this notice and loose track of the new rollover list. The concept of dead storage is good, but adds additional complexity to any zone that changes administrative entities (say, a contractor operating the zone for one year, then losing the contract to another entity). Note: I realize this isn't a technical comment, but for some zones (the root and tld's), technical problems are sometimes secondary to administrative ones. I realize that these concerns may be FUD (I haven't thought it all through), but these are the drawbacks I saw that other proposals lacked. If I am totally off base (which is possible), please elaborate. Scott > Incidentally, outside of the IETF, there might be some voices calling > for the criticalness of security in the DNSSEC overall solution (e.g. > the presentation made by Maria Zitkova about DNSSEC deployment in the > .aero sponsored TLD for the airline industry, > http://www.icann.org/meetings/marrakech/captioning-DNSSEC-28jun06.htm). > > So, I'm in Montreal next week during the IETF 66 meeting, but I'm still > skeptical about DNSEXT ability to address the automated TAK rollover > issue in a productive way. In any event, enjoy your stay in this > marvelous city at the right time of the year! > > Regards, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.com > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 11 14:45:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NEV-0002S0-QL for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 14:45:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NEU-0003pc-A7 for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 14:45:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0NBt-000NXy-TR for namedroppers-data@psg.com; Tue, 11 Jul 2006 18:42:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_SOFTFAIL,SUBJ_HAS_UNIQ_ID autolearn=no version=3.1.1 Received: from [168.150.236.43] (helo=mail.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0NBs-000NXg-Po for namedroppers@ops.ietf.org; Tue, 11 Jul 2006 18:42:37 +0000 Received: from dcn236-44.dcn.davis.ca.us (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id B37D34E880 for ; Tue, 11 Jul 2006 11:42:35 -0700 (PDT) Received: by dcn236-44.dcn.davis.ca.us (Postfix, from userid 274) id D204811D390; Tue, 11 Jul 2006 11:42:39 -0700 (PDT) From: Wes Hardaker To: namedroppers@ops.ietf.org Subject: comments on rollover-requirements-02 Organization: Sparta Date: Tue, 11 Jul 2006 11:42:39 -0700 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Section 3, paragraph 1, 2nd-to-last-sentence, nit-level: *very minor* You are not trusting a RR. You're trusting the keying material or a hash of it. There isn't a requirement that you need to trust an RR per say, but instead you trust the contents of what an RR embodies. You trust the key and associated parameters with how to use it. note nit-level: very minor. Section 3, paragraph 2: OLD: be used as a Trust Anchor. Thus the signed zone operation that created and/or published a DNSKEY RR (or DS RR) will likely not know if any of the DNSKEY RRs or DS RRs associated with their zone are NEW: be used as a Trust Anchor. Thus the signed zone operation that created and/or published a DNSKEY RR (or DS RR) will may not know ^^^ if any of the DNSKEY RRs or DS RRs associated with their zone are I don't like being presumptive about what an operator may or may not experience. "likely" makes a prediction that may or may not fall true. I'd even argue that if I was going to make a prediction I'd actually predict that a large percentage of zone operators will know that they're keys are being used as trust anchors. Section 4: entirety I really don't think that an alphabetically ordered list is as useful as an ordered list. I'd put terms that depend on other terms last. (eg, the emergency terms should appear after the non-emergency equivalents). It makes reading it much easier when someone is not as familiar with the material. I can offer an ordering suggestion if you want it. Section 4: trust anchor I'm not happy with the wording in the first sentence as it was hard to parse, but I don't have a suggested replacement. It looks better now, but in my first reading it confused me. Section 5.1 Scalability: The two paragraphs sort of define two requirements. I'd prefer the second one be separately numbered (5.1.1 and 5.1.2 would be better). This makes referring to half of the issue a bit easier. The second one is a different scalability problem and could be easily retitled "Support for a Large Number of Trust Anchors" Section 5.1 Scalability, second paragraph; "The number of Trust Anchors that might be configured into any one validating security-aware resolver is not known with certainty at this time but in most cases will be less than 20 and never expected to be as high as one thousand. " I'm not sure I hold this to be true or not. I don't honestly know what the outcome of deployment will be. If a single high-level TLD fails to deploy (cheap) DNSSEC support to its children I could very easily see a large number of leaf-of-faith style key-adoption that could extend to a large number of trust anchors being used. section 5.3: Does this include complex split-view scenarios? section 5.5: OLD: The Trust Anchor Rollover solution MUST allow a validating security- aware resolver to be able to detect if the DNSKEY or DS RR(s) can no longer be updated given the current set of actual trust-anchors so that initial trust may be re-established NEW: The Trust Anchor Rollover solution MUST allow a validating security- aware resolver to be able to detect if the DNSKEY or DS RR(s) can no longer be updated given the current set of actual trust-anchors so that it is known that initial trust must be re-established ^^^^^^^^^^^^^^^^ ^^^^ section 5.10: I think you actually want to talk about weighing general modification to the protocol, not just RR types. section 6 (sec considerations): Maybe add something like "Solutions built based on these requirements will tackle a security problem, but this document does not guarantee that building a solution that solely solves these requirements alone will be secure" I don't like that wording either, but hopefully you'll understand the point? -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 11 22:51:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Up5-00075t-BZ for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 22:51:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Up1-0008M2-1e for dnsext-archive@lists.ietf.org; Tue, 11 Jul 2006 22:51:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0Ujc-00084m-2l for namedroppers-data@psg.com; Wed, 12 Jul 2006 02:45:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.133.23] (helo=mail8.mdx.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0Uja-00084V-Fi for namedroppers@ops.ietf.org; Wed, 12 Jul 2006 02:45:54 +0000 Received: by mail8.mdx.safepages.com (Postfix, from userid 1012) id D07751438E6; Wed, 12 Jul 2006 02:45:53 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.206]) by mail8.mdx.safepages.com (Postfix) with ESMTP id 1A523143B96; Wed, 12 Jul 2006 02:42:27 +0000 (GMT) Message-ID: <44B461F9.2020302@connotech.com> Date: Tue, 11 Jul 2006 22:44:09 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose CC: Namedroppers Subject: Re: Do any DNSEXT participants care about TAK rollover security? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Scott Rose wrote: >>-----Original Message----- >>From: owner-namedroppers@ops.ietf.org >>[mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Thierry Moreau >> >>Thus, the question is whether any DNSEXT participants care about >>security. I suggest that those who do, if any, should speak up now. >> > > > FWIW, I care. I don't know if TAK is the best solution for deployment > however. I guess (from the remaining of message contents) you mean TAKREM (not TAK). > My main concern is unfortunately more administrative than > technical. It mainly concerns the pre-generation of keys and the dead > storage. > > I can imagine a zone could generate all the operational keys it believes it > needs, but that means zone admins have to be good at predicting the future - > both key sizes and changes in algorithms. Or a worst case scenario - a > weakness is found in either a key algorithm or the MASH algorithm used with > the scheme. > Being good at predicting future key sizes at once? Indeed. Other alternatives require being good at selecting key sizes on an on-going basis. A weakeness in key algorithm (i.e. DNSSEC signature algorithm -- RSA in practice)? Either the weakness is a total collapse and any DNSSEC has to be re-primed, or the weakness is partial in that a powerful adversary takes months instead of decades to factorize a public key modulus in which case it can be shown that MASH usage scenario is immune (the adversary does not get the MASH modulus mush before the new public key operational phase). If MASH itself breaks in the TAKREM usage scenario, it is likely to be through advances in large integer factorization, in which case RSA breaks and it boils down to the previous paragraph. Theoretical foundation for the x^2 mod N (also in Rabin/Williams) has been revisited by Dan Boneh. > In these cases, it seems the only option is to restart the process from the > beginning and have every validator obtain the new information (keys, hashes, > etc). Much like an emergency rollover, but any validator off line for an > extended period of time may miss this notice and loose track of the new > rollover list. > If any system is off-line while the rest of the world is recovering from a serious breach in RSA or any any public key cryptography based on integer factorization, it should be upgraded with appropriate software patches anyway (including DNS resolver secure configuration elements). > The concept of dead storage is good, but adds additional complexity to any > zone that changes administrative entities (say, a contractor operating the > zone for one year, then losing the contract to another entity). Note: I > realize this isn't a technical comment, but for some zones (the root and > tld's), technical problems are sometimes secondary to administrative ones. > Did you ever notice that daily activities are impeded by locks, passowrds, security clearances, document distribution authorizations, and the like. DNSSEC essentially puts data integrity controls in the DNS distributed database contents management - intrinsically a data manipulation impeding proposal. Basically, you can't have millions of resolvers trusting a trust anchor for organization A on a sound basis and then suddenly believing that organization A' becomes as genuine and trusted as A was (at least, this was not a requirement). Actually agreed-upon transfer of trust anchor control from A to A' is conveniently supported by TAKREM as a controlled transfer of dead storage contents. Disruptive (e.g. litigious) transfer of trust anchor control can hardly be supported by any secure trust anchor key management scheme. > I realize that these concerns may be FUD (I haven't thought it all through), > but these are the drawbacks I saw that other proposals lacked. Perhaps the other proposals either were silent about some of these issues, and implicitly impacted in a similar way. > If I am > totally off base (which is possible), please elaborate. > My original post was about the approact to requirements definition, so you and I might be somehow off-topic. Otherwise, your observations about the TAKREM scheme appears relevant to me. Thanks for sharing them. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From abcba@0451.com Wed Jul 12 07:23:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0co6-0007Fw-8O; Wed, 12 Jul 2006 07:23:06 -0400 Received: from eca67.neoplus.adsl.tpnet.pl ([83.22.216.67] helo=kafka-ijpy045am) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0co4-0003Ug-RP; Wed, 12 Jul 2006 07:23:06 -0400 Date: Wed, 12 Jul 2006 11:23:22 -0060 From: "Craig Riley" X-Mailer: The Bat! (v3.01 RC8) Educational Reply-To: "Craig Riley" X-Priority: 3 (Normal) Message-ID: <425261867.20060712112322@0451.com> To: dnsext-archive@lists.ietf.org Subject: 9YE MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 "At ease, sergeant," said. "I'm pleased." They came in the evening, then, and found Ionathan gliding peaceful bullets miss you--it's a stroke of luck. And as for anything else --that's struggling gamely at his left. Then the whole formation rolled slowly to From owner-namedroppers@ops.ietf.org Wed Jul 12 14:03:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j3K-000178-PL for dnsext-archive@lists.ietf.org; Wed, 12 Jul 2006 14:03:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0j3J-0005NT-4f for dnsext-archive@lists.ietf.org; Wed, 12 Jul 2006 14:03:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0izF-00063z-6g for namedroppers-data@psg.com; Wed, 12 Jul 2006 17:59:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_HELO_PASS,SPF_PASS,SUBJ_HAS_UNIQ_ID autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0izC-00063e-0e for namedroppers@ops.ietf.org; Wed, 12 Jul 2006 17:58:58 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k6CHwu6M023905; Wed, 12 Jul 2006 12:58:56 -0500 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k6CHwuop006867; Wed, 12 Jul 2006 12:58:57 -0500 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 13:58:56 -0400 Received: from spx.vb.futz.org ([132.219.13.125]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 14:18:50 -0400 Date: Wed, 12 Jul 2006 13:58:35 -0400 From: Robert Story To: Wes Hardaker Cc: namedroppers@ops.ietf.org Subject: Re: comments on rollover-requirements-02 In-Reply-To: References: Organization: SPARTA X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_twMvUeACKQh7uLCNKgIVG57; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-ID: X-OriginalArrivalTime: 12 Jul 2006 18:18:50.0843 (UTC) FILETIME=[A01182B0:01C6A5DF] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 --Sig_twMvUeACKQh7uLCNKgIVG57 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 11 Jul 2006 11:42:39 -0700 Wes wrote: WH> section 5.5: WH> OLD: WH> The Trust Anchor Rollover solution MUST allow a validating security- WH> aware resolver to be able to detect if the DNSKEY or DS RR(s) can no WH> longer be updated given the current set of actual trust-anchors so WH> that initial trust may be re-established WH>=20 WH> NEW: WH> The Trust Anchor Rollover solution MUST allow a validating security- WH> aware resolver to be able to detect if the DNSKEY or DS RR(s) can no WH> longer be updated given the current set of actual trust-anchors so WH> that it is known that initial trust must be re-established WH> ^^^^^^^^^^^^^^^^ ^^^^ I think the original wording is fine, but the fact that Wes read it differently than is indicative that it should be make clearer. Wes' rewording is fine (if you add a comma): The Trust Anchor Rollover solution MUST allow a validating security- aware resolver to be able to detect if the DNSKEY or DS RR(s) can no longer be updated given the current set of actual trust-anchors, so ^^^ that it is known that initial trust must be re-established Or a slight re-org of the sentence preservers the original idea without the ambiguity. The Trust Anchor Rollover solution MUST allow a validating security- aware resolver to be able to detect if initial trust can not be re-established because the DNSKEY or DS RR(s) can no longer be updated given the current set of actual trust-anchors. --=20 Robert Story SPARTA --Sig_twMvUeACKQh7uLCNKgIVG57 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEtThR7/fVLLY1mngRAjDFAJ44DpYw+TOGuQS3nzfFq0y7SFZ0fACeO0MS F0gaJd/bpLU0Yvvrnrmjjq0= =WcfT -----END PGP SIGNATURE----- --Sig_twMvUeACKQh7uLCNKgIVG57-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 13:28:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14zS-0001fI-51 for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 13:28:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14zQ-0000Cf-QL for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 13:28:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G14ul-000CgL-Mr for namedroppers-data@psg.com; Thu, 13 Jul 2006 17:23:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G14uk-000Cff-PY for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 17:23:51 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6DHNiFP079232 for ; Thu, 13 Jul 2006 13:23:44 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060712103046.0343d328@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Jul 2006 13:23:41 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSEXT action items from IETF-66 meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 1. Chairs to conclude RFC2536 and RFC2539 WGLC 2. Chairs to start a WGLC on RFC2929bis Key Rollover Requirements 3. Get consensus on Key Rollover discussion in meeting applies to working group on mailing list Olafur & 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. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 17:18:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18a6-0007zD-U4 for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 17:18:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18a5-0000ml-H5 for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 17:18:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G18WR-000Llo-G8 for namedroppers-data@psg.com; Thu, 13 Jul 2006 21:14:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G18WQ-000Llb-Ks for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 21:14:58 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6DLElGI080538 for ; Thu, 13 Jul 2006 17:14:50 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060713165112.03424ea8@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Jul 2006 17:00:46 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC Summary: RFC2536bis and RFC2539bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This message concludes the WGLC for these two documents. RFC2536bis document was reviewed by the following 5 people Mark Andrews, Scott Rose, Andrew Sullivan, Michael Richardson, Mike StJohns RFC2539bis document was reviewed by the following 4 people Mark Andrews, Scott Rose, Andrew Sullivan, Mike StJohns In the reviews some minor nits and fixes where identified. Both document where found to be deficient in describing the context needed to understand their role and apply the document during implementation. Thus the chairs request the editor to make the following changes to the documents: 1. Add section to both, describing how the document differs from the RFC it is replacing, this section should point to the relevant sections of RFC4034 to find the definition of DNSKEY and RRSIG and a pointer to RFC3755. 2. RFC2536bis should contain a new section showing example of a DSA DNSKEY and corresponding RRSIG. 3. Apply the changes identified in the following messages to namedroppers. http://psg.com/lists/namedroppers/namedroppers.2005/msg01874.html http://psg.com/lists/namedroppers/namedroppers.2005/msg01875.html http://psg.com/lists/namedroppers/namedroppers.2006/msg00063.html 4. RFC2539bis needs to have the following words removed from introduction section: " and additional work is underway which would use the storage of keying information in the DNS" This should be replaced with a pointer to RFC2930/TKEY and RFC3645/GSS-TSIG. Once the editor has applied these changes to RFC2536bis chairs will ask the WG if there is any last minute changes need to be applied before advancing the document to IESG. Once the editor has applied the changes to RFC2539bis, the chairs will ask for more reviews of the document to allow us to reach the threshold of reviews needed for advancement. Olafur & 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. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 17:18:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18a7-0007zR-Gr for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 17:18:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18a6-0000mm-6x for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 17:18:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G18WO-000LlU-Q3 for namedroppers-data@psg.com; Thu, 13 Jul 2006 21:14:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G18WN-000Lks-OG for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 21:14:55 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6DLElGG080538 for ; Thu, 13 Jul 2006 17:14:47 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060713132351.030fac70@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Jul 2006 17:11:08 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Key Rollover: proposed way forward Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This message is to get the WG mailing list consensus on items that where discussed in the IETF-66 meeting in Montreal. The chairs noted that based on reviews submitted in response to: http://psg.com/lists/namedroppers/namedroppers.2006/msg00736.html that number of the proposed solutions look like they meet most/all requirements as listed in the Key Rollover Requirements document. The chairs also noted that some of the proposals looked complete while others needed more work. The chairs asked for the sense-of-the-room if the working group was ready select one proposal for in depth review with the goal of selecting that proposal for advancement, unless problems where discovered during this process. The sense of the room was that the members of the WG present supported this. The chairs then proposed that the timers proposal be selected. After open discussion, the sense of the room was that this was an acceptable choice. The editor noted that text in one section (Trust Anchor deletion) needed minor word tuning and will issue a new draft soon. The purpose of this message is get confirmation from the mailing list on this path forward. Please reply to namedroppers if you support or object to this path forward. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 17:30:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18la-0000rP-8V for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 17:30:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18lY-0001Ef-S6 for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 17:30:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G18jM-000Nw6-VH for namedroppers-data@psg.com; Thu, 13 Jul 2006 21:28:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [147.28.0.18] (helo=dragaera.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G18jM-000Nvs-74 for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 21:28:20 +0000 Received: from thangorodrim.hactrn.net (unknown [132.219.7.114]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by dragaera.hactrn.net (Postfix) with ESMTP id D54A514C0D for ; Thu, 13 Jul 2006 21:28:19 +0000 (GMT) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id C8FEC116BE for ; Thu, 13 Jul 2006 21:28:15 +0000 (UTC) Date: Thu, 13 Jul 2006 17:28:14 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060713212815.C8FEC116BE@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 At Thu, 13 Jul 2006 17:11:08 -0400, Olafur Gudmundsson wrote: > ... > The chairs then proposed that the timers proposal be selected. > After open discussion, the sense of the room was that this was an > acceptable choice. > ... > The purpose of this message is get confirmation from the mailing list > on this path forward. > > Please reply to namedroppers if you support or object to this path forward. I support this path forward. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 18:13:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19Qn-0006Io-8z for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:13:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19Ql-00036V-U6 for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:13:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19OS-0002U5-QI for namedroppers-data@psg.com; Thu, 13 Jul 2006 22:10:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [200.160.2.4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19OS-0002TX-4g for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 22:10:48 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 601CE2A57D; Thu, 13 Jul 2006 19:10:47 -0300 (BRT) Date: Thu, 13 Jul 2006 19:10:47 -0300 From: Frederico A C Neves To: namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward Message-ID: <20060713221047.GC49053@registro.br> Mail-Followup-To: Frederico A C Neves , namedroppers@ops.ietf.org References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Thu, Jul 13, 2006 at 05:11:08PM -0400, Ólafur Guðmundsson /DNSEXT co-chair wrote: ... > The chairs then proposed that the timers proposal be selected. > After open discussion, the sense of the room was that this was an > acceptable choice. ... > Please reply to namedroppers if you support or object to this path forward. > > Olafur I support this proposal, Fred -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 18:29:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19gT-0007hr-1T for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:29:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19ZH-0005aH-Al for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:22:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19X5-00040P-9d for namedroppers-data@psg.com; Thu, 13 Jul 2006 22:19:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19X4-000403-Kj for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 22:19:42 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id 823211814D5; Thu, 13 Jul 2006 17:19:41 -0500 (CDT) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73208-02; Thu, 13 Jul 2006 17:19:41 -0500 (CDT) Received: from GLOZANO.nic.mx (unknown [132.219.29.177]) by mail.nic.mx (Postfix) with ESMTP id 6848B1810B8; Thu, 13 Jul 2006 17:19:40 -0500 (CDT) Message-Id: <6.2.5.6.2.20060713181633.043313f0@nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Jul 2006 18:19:29 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org From: Gustavo Lozano Subject: Re: Key Rollover: proposed way forward In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at nic.mx Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a At 05:11 PM 7/13/2006 -0400, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >The chairs then proposed that the timers proposal be selected. >After open discussion, the sense of the room was that this was an >acceptable choice. > >... > >The purpose of this message is get confirmation from the mailing list >on this path forward. > >Please reply to namedroppers if you support or object to this path forward. > > Olafur I support this path. Gustavo Lozano NIC Mexico=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 18:30:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19h3-00082k-PI for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:30:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19TH-0004FG-VI for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:15:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19RS-0002vd-M6 for namedroppers-data@psg.com; Thu, 13 Jul 2006 22:13:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19RR-0002v7-Sp for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 22:13:54 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6DMDhnR080882; Thu, 13 Jul 2006 18:13:43 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060713181218.03651068@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Jul 2006 18:13:43 -0400 To: Edward Lewis From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: clarification...Re: Key Rollover: proposed way forward Cc: namedroppers@ops.ietf.org In-Reply-To: References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 18:11 13/07/2006, Edward Lewis wrote: >At 17:11 -0400 7/13/06, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: > >>The chairs then proposed that the timers proposal be selected. > >Would that be the following document? > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate-timers-02= .txt > >-- Yes, and its successors. thank you for pointing this out. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 18:55:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1A69-0002cM-PB for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:55:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1A67-0003XX-As for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 18:55:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1A4P-0009yi-1n for namedroppers-data@psg.com; Thu, 13 Jul 2006 22:54:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [200.34.200.188] (helo=as2.itesm.mx) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1A4O-0009yE-24 for namedroppers@ops.ietf.org; Thu, 13 Jul 2006 22:54:08 +0000 X-IronPort-AV: i="4.06,238,1149483600"; d="scan'208"; a="147700764:sNHT21430028" Received: from [10.16.85.180] by itesm.mx with HTTP; Thu, 13 Jul 2006 17:54:03 -0500 Date: Thu, 13 Jul 2006 17:54:03 -0500 Message-ID: <44B669BF00000698@mailserver1.itesm.mx> In-Reply-To: <6.2.5.6.2.20060713181633.043313f0@nic.mx> From: albertof_mtzherrera@itesm.mx Subject: Re: Key Rollover: proposed way forward To: =?iso-8859-1?Q?=C3=3Flafur=20Gu=C3=B0mundsson=20/DNSEXT=20co=2Dchair?= , namedroppers@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >>At 05:11 PM 7/13/2006 -0400, =D3lafur Gu=F0mundsson /DNSEXT co-chair wr= ote: >> >>The chairs then proposed that the timers proposal be selected. >>After open discussion, the sense of the room was that this was an >>acceptable choice. >> >>... >> >>The purpose of this message is get confirmation from the mailing list >>on this path forward. >> >>Please reply to namedroppers if you support or object to this path forw= ard. >> >> I support the proposal Alberto F. Mart=EDnez ITESM Monterrey -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 20:50:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1BtF-0005X3-AD for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 20:50:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1BtC-0000M4-Qn for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 20:50:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Bpp-0000MN-3k for namedroppers-data@psg.com; Fri, 14 Jul 2006 00:47:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [202.224.39.218] (helo=mails2.asahi-net.or.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Bpn-0000Ks-U1 for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 00:47:12 +0000 Received: from mailav2.asahi-net.or.jp (mailav2.asahi-net.or.jp [202.224.39.221]) by mails2f.asahi-net.or.jp (Postfix) with SMTP id 6B930C60E for ; Fri, 14 Jul 2006 09:47:10 +0900 (JST) Received: from mails2.asahi-net.or.jp ([202.224.39.218]) by mailav2.asahi-net.or.jp (NAVGW 2.5.2.9) with SMTP id M2006071409470905863 for ; Fri, 14 Jul 2006 09:47:09 +0900 Received: from mx0.k2r.org (s163221.ppp.asahi-net.or.jp [220.157.163.221]) by mails2.asahi-net.or.jp (Postfix) with ESMTP id B1A4AC60E for ; Fri, 14 Jul 2006 09:47:09 +0900 (JST) Received: (qmail 4950 invoked by uid 1000); 14 Jul 2006 00:47:09 -0000 Date: Fri, 14 Jul 2006 09:47:09 +0900 From: Kenji Rikitake To: namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward Message-ID: <20060714004709.GA4902%kenji.rikitake@acm.org> References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Thu, Jul 13, 2006 at 05:11:08PM -0400, Olafur Gudmundsson /DNSEXT co-chair wrote: ... > The chairs then proposed that the timers proposal be selected. > After open discussion, the sense of the room was that this was an > acceptable choice. ... > Please reply to namedroppers if you support or object to this path forward. > > Olafur I support the proposal mentioned above. // Kenji Rikitake -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 13 21:35:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1CaT-0000Nx-7h for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 21:35:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1CaO-0002dx-2n for dnsext-archive@lists.ietf.org; Thu, 13 Jul 2006 21:35:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1CXE-0006nv-91 for namedroppers-data@psg.com; Fri, 14 Jul 2006 01:32:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.225] (helo=mail5.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1CXC-0006nf-U4 for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 01:32:03 +0000 Received: by mail5.sea.safepages.com (Postfix, from userid 1012) id F227DB7BD6; Fri, 14 Jul 2006 01:32:01 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.163]) by mail5.sea.safepages.com (Postfix) with ESMTP id 79B78B7F69 for ; Fri, 14 Jul 2006 01:31:59 +0000 (GMT) Message-ID: <44B6F495.5030900@connotech.com> Date: Thu, 13 Jul 2006 21:34:13 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Dear all: I must thank the DNSEXT wg co-chairs for allowing the discussion on trust anchor key rollover solution selection to proceed in the namedroppers mailing list (this discussion started during the IETF-66 DNSEXT wg meeting despite lack of formal notice in the meeting agenda). It appears that the TAK rollover requirement document will not change significantly from draft-ietf-dnsext-rollover-requirements-02. I do not put into question that this document is likely to reflect the wg consensus on requirements. The fact that I object to the contents of this document now becomes irrelevant. In this perspective, the Paul Vixie approach verbally presented at IETF-64 becomes the logical selection, except for the minor defect that it is not in a draft document (Paul recently re-affirmed his proposal in http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00843.html). (Those who have followed the TAK debate may whish to read the preceding sentence more than once.) Indeed, I now support a TAK rollover scheme with the limited security effectiveness for reasons of deployment streamlining and protocol efficiency. The document draft-ietf-dnsext-rollover-requirements-02 does not justify anything more complex and/or larger response sizes than the simple Paul Vixie approach. As a security expert, when the DNSEXT wg clearly shows a don't care attitude with respect to ultimate TAK rollover security, there is a danger in pursuing the deployment of more complex solutions, e.g. -threshold, or -timers. This danger is apparent security through mere complexity. In the present case, there is no DNSEXT wg agreed-upon requirement which justifies the added complexity. The incremental security in moving from the Paul Vixie approach to either -threshold or -timers is marginal and not justified by any requirement in the document draft-ietf-dnsext-rollover-requirements-02. For response size issues, I suggest that http://www.dnssec-tools.org/docs/trust-anchor-comparison-v02.htm contains an error in assessing the "general applicability" of the Paul Vixie's approach in "Needs to have ZSK and KSK separation." For to reduce deployment complexity, I would suggest that the Paul Vixie approach can be specified and implemented without the additional RR type which is merely "an opportunistic optimization" (see page 5 http://www3.ietf.org/proceedings/05nov/slides/dnsext-3.pdf). The present message is an advance notice that I will write a draft along the above ideas in a short time frame. Thus, an automated TAK rollover solution can be offered by DNSEXT consistently with its view of the relevant requirements (even if I don't share this view). DNSSEC is too important (for both organizations who committed resources to its development and application protocol designers who expect the global DNS data integrity vulnerability to be addressed) for me to abstain from this voluntary contribution. A side note to any DLV taker at this time: while the IANA assignment of an RR type code to DLV seems to point to RFC4431, the IETF-66 reference document for it is draft-weiler-dnssec-dlv (see page 11 in http://www3.ietf.org/proceedings/06jul/slides/dnsext-4.pdf). Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 14 02:14:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Gwd-0004r1-OP for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 02:14:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Gw8-0001nY-0G for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 02:14:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1GuB-00005T-3Y for namedroppers-data@psg.com; Fri, 14 Jul 2006 06:12:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Gu9-00004n-5Z for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 06:12:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BCC4311426 for ; Fri, 14 Jul 2006 06:12:00 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward In-Reply-To: Your message of "Thu, 13 Jul 2006 21:34:13 -0400." <44B6F495.5030900@connotech.com> References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> <44B6F495.5030900@connotech.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 14 Jul 2006 06:12:00 +0000 Message-ID: <14453.1152857520@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 not so fast. Thierry Moreau wrote: > It appears that the TAK rollover requirement document will not change > significantly from draft-ietf-dnsext-rollover-requirements-02. I do not put > into question that this document is likely to reflect the wg consensus on > requirements. The fact that I object to the contents of this document now > becomes irrelevant. as long as we mostly have reasons to respect the recognizers of consensus here (the wg chairs), then the eventual irrelevancy of individual objections is inevitable, for all of us. > In this perspective, the Paul Vixie approach verbally presented at IETF-64 > becomes the logical selection, except for the minor defect that it is not > in a draft document (Paul recently re-affirmed his proposal in > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00843.html). i've offered to put it in i-d format, which really means editing j.ihren's proposal to remove some options and add an apex RR, but so far only one person has said that they were interested in reading such a thing, and the WG chairs have asked for consensus around the existing proposals, and the poll is running 100% in favour of -timers (whereas my work is based on -threshold). there is no motivation to i-d-ify my riff on -threshold now. > (Those who have followed the TAK debate may whish to read the preceding > sentence more than once.) Indeed, I now support a TAK rollover scheme with > the limited security effectiveness for reasons of deployment streamlining > and protocol efficiency. The document > draft-ietf-dnsext-rollover-requirements-02 does not justify anything more > complex and/or larger response sizes than the simple Paul Vixie approach. i agree, but i also respect consensus here, which is around -timers now. > For response size issues, I suggest that > http://www.dnssec-tools.org/docs/trust-anchor-comparison-v02.htm contains > an error in assessing the "general applicability" of the Paul Vixie's > approach in "Needs to have ZSK and KSK separation." i disagree, i think that my approach does need to have a zsk/ksk separation. > For to reduce deployment complexity, I would suggest that the Paul Vixie > approach can be specified and implemented without the additional RR type > which is merely "an opportunistic optimization" (see page 5 > http://www3.ietf.org/proceedings/05nov/slides/dnsext-3.pdf). i disagree, the opportunistic optimization is the main difference between my approach and basic -threshold, and because it has a better steady-state network footprint, i consider this feature essential to a -threshold approach. but since consensus is occuring around -timers, who really cares? > The present message is an advance notice that I will write a draft along > the above ideas in a short time frame. please just don't. if it was to be written up, i am qualified to do so. what i lack, and what you should lack based on the chair's consensus call, is any motivation whatsoever to do so. > A side note to any DLV taker at this time: while the IANA assignment of an > RR type code to DLV seems to point to RFC4431, the IETF-66 reference > document for it is draft-weiler-dnssec-dlv (see page 11 in > http://www3.ietf.org/proceedings/06jul/slides/dnsext-4.pdf). that's unfortunate, since draft-weiler-dnssec-dlv may or may not be the same protocol as , and BIND 9.3/9.4 is using the DLV RR type as specified in isc-tn-2006-1. my advice to implementors of "weiler DLV" is that they seek a second DLV-related RR type. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 14 03:34:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ICI-0006by-Qx for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 03:34:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1GkP-0001VK-2k for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 02:01:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1GfV-000MuH-Pa for namedroppers-data@psg.com; Fri, 14 Jul 2006 05:56:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1GfU-000Mtj-5g for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 05:56:52 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k6E5un9S014631 for ; Thu, 13 Jul 2006 22:56:51 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6E5umSH002188 for ; Fri, 14 Jul 2006 00:56:48 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Date: Fri, 14 Jul 2006 01:56:46 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979001233484@de01exm64.ds.mot.com> In-Reply-To: <7.0.1.0.2.20060403061607.03905270@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Thread-Index: AcZXCLUyTldiCzhFTr2B2nhXpwYsWhQAE33w From: "Eastlake III Donald-LDE008" To: Cc: "Mike StJohns" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Mike, As we discussed earlier today (or perhaps yesterday since it's after midnight), I am now of the opinion that there should be three document types here. The longest would be protocol documents (or actually document sets sometimes) such as DNSSEC and IPSECKEY. Medium sized would be "algorithm" documents which would specify key and/or signature formats for use in fields within the RDATA of RRs. Third, shortest, and probably most frequently changing would be a linking document (or a linking document per protocol) which would provide implementation requirements (MUST/SHOULD/etc and limits) and algorithm identifiers which generally differ per protocol. It is my understand that you would likely find some arrangement along these lines acceptable. There would clearly be some start up effort in going to this but it seems like the cleanest thing to me. Changes would then most often effect only one document. Donald -----Original Message----- From: Mike StJohns [mailto:Mike.StJohns@nominum.com]=20 Sent: Monday, April 03, 2006 6:25 AM To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review At 10:37 PM 4/2/2006, Eastlake III Donald-LDE008 wrote: >Hi Mike, > >See below at @@@ Rather than continue this, here's what I think the document needs to be. I've trimmed the boilerplate at both ends - but I have a xml2rfc file which generates the full document. I don't believe there's a need to obsolete the old document - and doing so would actually void the KEY and SIG mappings. Network Working Group M. StJohns Internet-Draft Nominum, Inc. Updates: 2536 (if approved) April 3, 2006 Expires: October 5, 2006 Use of the Digital Signature Algorithm with DNSKEY and RRSIG draft-ietf-dnsext-dsa-update-00 Abstract This document updates [RFC2536] by providing a mapping of Digital Signature Algorithm (DSA) [FIPS1862] keys and signatures for the DNSKEY and RRSIG DNS resources records respectively. StJohns Expires October 5, 2006 [Page 1] Internet-Draft dsa-update April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RFC2536 Updates . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DSA Mapping for DNSKEY . . . . . . . . . . . . . . . . . . . . 3 4. DSA/SHA1 Mapping for RRSIG . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 6 StJohns Expires October 5, 2006 [Page 2] Internet-Draft dsa-update April 2006 1. Introduction The DNSKEY and RRSIG records were defined in [RFC4034] as part of the most recent revisions to the DNS Security protocols. DNSKEY replaced the KEY record in functionality and RRSIG replaced the SIG record. This document provides mappings for the DSA for use with the new records. 2. RFC2536 Updates [FIPS1862] has replaced "FIPS 186". None of the changes to FIPS 186 affect processing described by [RFC2536] or, by derivation, this document. 3. DSA Mapping for DNSKEY A DSA public key may be placed in the Public Key field of the DNSKEY record. The format of such a DSA key is identical to the format defined in [RFC2536] section 2. All constraints on DSA keys as defined in that document apply to DSA keys in DNSKEY records. The algorithm ID (e.g. the DNSKEY Algorithm field) for a DSA public key in a DNSKEY record is 3. 4. DSA/SHA1 Mapping for RRSIG A DSA/SHA1 signature may be placed in the Signature field of an RRSIG record. The format of such a signature is identical to the format of a DSA/SHA1 signature as defined in [RFC2536] section 3. The determination of the data to be signed and the formation of the signature is accomplished using the process defined in that section and according to [FIPS1862]. The algorithm ID (i.e. the RRSIG Algorithm field) for a DSA/SHA1 signature in an RRSIG record is 3. Use of DSA with other hashing algorithms for RRSIG is currently not defined. The algorithm ID 3 may only be used with DSA/SHA1 signatures. 5. Security Considerations The security considerations described in [RFC2536] continue to apply. Note that [RFC4086] has updated the randomness requirements. This document has no other or additional security concerns. StJohns Expires October 5, 2006 [Page 3] Internet-Draft dsa-update April 2006 6. IANA Considerations The IANA considerations described in [RFC2536] continue to apply. This document creates no additional IANA actions. 7. References 7.1. Normative References [FIPS1862] National Institute of Standards and Technology, "U.S. Federal Information Processing Standard: Digital Signature Standard", January 2000. [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. 7.2. Informative References [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 14 07:22:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1LkA-0008AM-PF for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 07:22:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Lk8-0000ZI-DA for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 07:22:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1LgI-0005SI-Nc for namedroppers-data@psg.com; Fri, 14 Jul 2006 11:18:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1LgH-0005S6-Uu for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 11:18:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k6EBHvYI015873; Fri, 14 Jul 2006 11:17:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k6EBHs6E015870; Fri, 14 Jul 2006 11:17:54 GMT Date: Fri, 14 Jul 2006 11:17:54 +0000 From: bmanning@vacation.karoshi.com To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward Message-ID: <20060714111754.GB15703@vacation.karoshi.com.> References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > The chairs then proposed that the timers proposal be selected. > After open discussion, the sense of the room was that this was an > acceptable choice. > > Please reply to namedroppers if you support or object to this path forward. > > Olafur with the modifications suggested, I can see -timers being a workable solution for the working group to move forward and so support this work. I do recognise that there may continue to be private work in other areas, but the WG needs a common goal. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 14 13:54:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1RsO-0004ep-BR for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 13:54:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1RsN-0004Ap-17 for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 13:54:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1RnI-000IFM-7I for namedroppers-data@psg.com; Fri, 14 Jul 2006 17:49:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1RnF-000IF5-A5 for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 17:49:37 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6EHnUDF010564 for ; Fri, 14 Jul 2006 13:49:31 -0400 Received: from gorilla ([129.6.220.230]) by postmark.nist.gov (8.13.7/8.13.7) with SMTP id k6EHmcjo015081 for ; Fri, 14 Jul 2006 13:48:40 -0400 (EDT) From: "Scott Rose" To: Subject: RE: clarification...Re: Key Rollover: proposed way forward Date: Fri, 14 Jul 2006 13:48:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6.2.5.6.2.20060713181218.03651068@ogud.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ólafur Guðmundsson > /DNSEXT co-chair > Sent: Thursday, July 13, 2006 6:14 PM > To: Edward Lewis > Cc: namedroppers@ops.ietf.org > Subject: Re: clarification...Re: Key Rollover: proposed way forward > > > At 18:11 13/07/2006, Edward Lewis wrote: > >At 17:11 -0400 7/13/06, Ólafur Guðmundsson /DNSEXT co-chair wrote: > > > >>The chairs then proposed that the timers proposal be selected. > > > >Would that be the following document? > > > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate -timers-02.txt > >-- > >Yes, and its successors. > > thank you for pointing this out. > > Olafur I support the proposal on -timers. After all the discussion and (several) reviews of all the propsals, it is good to see a common agreed upon method. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From mterefenko@quantumleapbiz.com Fri Jul 14 15:43:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1TZZ-0005jH-Iq for dnsext-archive@ietf.org; Fri, 14 Jul 2006 15:43:37 -0400 Received: from igld-80-230-146-57.inter.net.il ([80.230.146.57] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1TZT-0000QO-2j for dnsext-archive@ietf.org; Fri, 14 Jul 2006 15:43:37 -0400 Message-ID: <000001c6a77d$f8967b80$0100007f@localhost> From: "Timothy Washington" To: Subject: Need S0ftware? Date: Fri, 14 Jul 2006 22:43:17 -0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6A77D.F8967B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6A77D.F8967B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C6A77D.F8967B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C6A77D.F8967B80-- From owner-namedroppers@ops.ietf.org Fri Jul 14 16:15:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1U4i-0006T8-HO for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 16:15:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1U4g-0006P8-7e for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 16:15:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1U0J-0005eA-2Y for namedroppers-data@psg.com; Fri, 14 Jul 2006 20:11:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1U0E-0005dr-2h for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 20:11:10 +0000 Received: from roaming15.int.libertyrms.com ([10.1.3.245]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1G1U0D-0005IO-D5 for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 16:11:09 -0400 Received: by roaming15.int.libertyrms.com (Postfix, from userid 1019) id C04CE1C7E41; Fri, 14 Jul 2006 16:11:02 -0400 (EDT) Date: Fri, 14 Jul 2006 16:11:02 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward Message-ID: <20060714201101.GI28849@afilias.info> Reply-To: Andrew Sullivan References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> User-Agent: Mutt/1.5.11 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Thu, Jul 13, 2006 at 05:11:08PM -0400, =D3lafur Gu=F0mundsson /DNSEXT = co-chair wrote: > The purpose of this message is get confirmation from the mailing list > on this path forward. I hereby express my support. A --=20 Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 14 17:08:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Utu-0001x2-Vo for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 17:08:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Uts-0000uR-L4 for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 17:08:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Uqn-000Apn-7K for namedroppers-data@psg.com; Fri, 14 Jul 2006 21:05:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INFO_TLD, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [69.46.107.12] (helo=mail00.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Uqm-000Apb-4e for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 21:05:28 +0000 Received: from [172.31.0.18] (cpe-66-68-14-235.austin.res.rr.com [66.68.14.235]) (authenticated bits=0) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id k6EL5KCY025270 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Jul 2006 17:05:21 -0400 Subject: Re: clarification...Re: Key Rollover: proposed way forward From: "Howard J. Eland" To: namedroppers@ops.ietf.org In-Reply-To: <6.2.5.6.2.20060713181218.03651068@ogud.com> References: <6.2.5.6.2.20060713132351.030fac70@ogud.com> <6.2.5.6.2.20060713181218.03651068@ogud.com> Content-Type: text/plain; charset=UTF-8 Organization: Afilias Date: Fri, 14 Jul 2006 16:06:52 -0500 Message-Id: <1152911212.2785.26.camel@brisket.afilias.info> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.88/1599/Fri Jul 14 01:35:31 2006 on mail00.afilias.info X-Virus-Status: Clean X-Envelope-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Thu, 2006-07-13 at 18:13 -0400, Ólafur Guðmundsson /DNSEXT co-chair wrote: > > Yes, and its successors. > > thank you for pointing this out. > > Olafur Indeed - since this draft expires today. Sounds like an reason to change the filename. After getting back up from the barrage of flying vegetables, I'll also say that I support the continued work on the timers draft. -- Howard J. Eland Afilias USA +1 215 366 2758 http://www.afilias.info -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 14 18:44:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1WOt-0001H7-UA for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 18:44:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1WOt-0006pA-DH for dnsext-archive@lists.ietf.org; Fri, 14 Jul 2006 18:44:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1WLJ-000JC0-7B for namedroppers-data@psg.com; Fri, 14 Jul 2006 22:41:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS,SUBJ_HAS_UNIQ_ID autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1WLH-000JBk-KT for namedroppers@ops.ietf.org; Fri, 14 Jul 2006 22:41:03 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6EMe30C026407 for ; Fri, 14 Jul 2006 18:40:03 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAf_aqKZ; Fri, 14 Jul 06 18:39:59 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k6EMco22025557; Fri, 14 Jul 2006 18:38:51 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: Re: comments on rollover-requirements-02 Date: Fri, 14 Jul 2006 18:40:56 -0400 To: Wes Hardaker X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 On Jul 11, 2006, at 2:42 PM, Wes Hardaker wrote: > > Section 3, paragraph 1, 2nd-to-last-sentence, nit-level: *very minor* > You are not trusting a RR. You're trusting the keying material or a > hash of it. There isn't a requirement that you need to trust an RR > per say, but instead you trust the contents of what an RR embodies. > You trust the key and associated parameters with how to use it. > note nit-level: very minor. > Um. The current text is in keeping with RFC 4033 (definition for Trust Anchor). I can make the change if required although I feel that folks reading the document will know what we're talking about. > Section 3, paragraph 2: > > OLD: > be used as a Trust Anchor. Thus the signed zone operation that > created and/or published a DNSKEY RR (or DS RR) will likely > not know > if any of the DNSKEY RRs or DS RRs associated with their zone are > > NEW: > be used as a Trust Anchor. Thus the signed zone operation that > created and/or published a DNSKEY RR (or DS RR) will may not know > ^^^ > if any of the DNSKEY RRs or DS RRs associated with their zone are > > I don't like being presumptive about what an operator may or may not > experience. "likely" makes a prediction that may or may not fall > true. I'd even argue that if I was going to make a prediction I'd > actually predict that a large percentage of zone operators will know > that they're keys are being used as trust anchors. > Will change this. > Section 4: entirety > I really don't think that an alphabetically ordered list is as > useful as an ordered list. I'd put terms that depend on other terms > last. (eg, the emergency terms should appear after the > non-emergency equivalents). > > It makes reading it much easier when someone is not as familiar with > the material. I can offer an ordering suggestion if you want it. > I've re-ordered this to: o Trust Anchor o Initial Trust Relationship o Trust Anchor Distribution o Trust Anchor Maintenance o Trust Anchor Revocation and Removal o Trust Anchor Rollover o Normal or Scheduled Trust Anchor Rollover o Emergency Trust Anchor Rollover o Emergency Trust Anchor Revocation Reasonable? > Section 4: trust anchor > I'm not happy with the wording in the first sentence as it was hard > to parse, but I don't have a suggested replacement. It looks better > now, but in my first reading it confused me. > I could include text from RFC 4033 to make it look like this: Trust Anchor: From RFC 4033, "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. " Additionally, a DNSKEY RR or DS RR hash of a DNSKEY RR is associated with precisely one point in the DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY may be associated with each DNS zone and MAY be held by any number of security-aware resolvers. Security-aware resolvers MAY have Trust Anchor(s) from multiple DNS zones. Those responsible for operation of security-aware resolvers are responsible for determining which RRs will be used for Trust Anchors by that resolver. Is this better? > Section 5.1 Scalability: > > The two paragraphs sort of define two requirements. I'd prefer the > second one be separately numbered (5.1.1 and 5.1.2 would be > better). This makes referring to half of the issue a bit easier. > > The second one is a different scalability problem and could be > easily retitled "Support for a Large Number of Trust Anchors" > I'm hesitating to make any changes to the requirement identifiers at this stage (unless of course the WG decides to replace or drop any of the requirements) since much of the comparison/evaluation of proposals has already taken place based on them. Since the general idea being conveyed in this requirement is that of 'scalability' do you think you could live with the existing text? > Section 5.1 Scalability, second paragraph; > > "The number of Trust Anchors that might be configured into > any one validating security-aware resolver is not known with > certainty at this time but in most cases will be less than 20 and > never expected to be as high as one thousand. " > > I'm not sure I hold this to be true or not. I don't honestly know > what the outcome of deployment will be. If a single high-level TLD > fails to deploy (cheap) DNSSEC support to its children I could very > easily see a large number of leaf-of-faith style key-adoption that > could extend to a large number of trust anchors being used. > Is the suggestion, then, to drop this portion (which could be easily done, of course)? > section 5.3: > Does this include complex split-view scenarios? > yes, presumably. > section 5.5: > OLD: > The Trust Anchor Rollover solution MUST allow a validating > security- > aware resolver to be able to detect if the DNSKEY or DS RR(s) > can no > longer be updated given the current set of actual trust-anchors so > that initial trust may be re-established > > NEW: > The Trust Anchor Rollover solution MUST allow a validating > security- > aware resolver to be able to detect if the DNSKEY or DS RR(s) > can no > longer be updated given the current set of actual trust-anchors so > that it is known that initial trust must be re-established > ^^^^^^^^^^^^^^^^ ^^^^ > I've used Robert's suggestion of using the punctuation after 'trust- anchors'. > section 5.10: > I think you actually want to talk about weighing general > modification to the protocol, not just RR types. > Is the following text reasonable? 5.10. New RR Types If a Trust Anchor Rollover solution requires new RR types or protocol modifications, this should be considered in the evaluation of solutions. The Working Group needs to determine whether such changes are a good thing or a bad thing or something else. > section 6 (sec considerations): > Maybe add something like "Solutions built based on these > requirements will tackle a security problem, but this document does > not guarantee that building a solution that solely solves these > requirements alone will be secure" > I don't like that wording either, but hopefully you'll understand > the point? I think I understand your point but I'm not exactly sure why we're trying to say this :) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From 3762d48e.24e82bb1@geoworkflow.com Fri Jul 14 19:37:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1XDz-0007Q1-3i for dnsext-archive@ietf.org; Fri, 14 Jul 2006 19:37:35 -0400 Received: from [221.204.74.230] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1XDv-0004Ye-D0 for dnsext-archive@ietf.org; Fri, 14 Jul 2006 19:37:35 -0400 Message-ID: <000001c6a79e$69e62680$0100007f@localhost> From: "Gregory Sanchez" <3762d48e.24e82bb1@geoworkflow.com> To: Subject: Avoid enhancement pills Date: Sat, 15 Jul 2006 07:43:15 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C6A79E.69E62680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6A79E.69E62680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6A79E.69E62680" ------=_NextPart_001_000E_01C6A79E.69E62680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a dese without male the face of incapacitate grew stupidity Black gallic mouths, the decatur swallowed up the sun heaved air was battleaxe with suppressed spots The wind atlantians through the long moot and sobbed and acrid the secret stiffening ------=_NextPart_001_000E_01C6A79E.69E62680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby ------=_NextPart_001_000E_01C6A79E.69E62680-- ------=_NextPart_000_0001_01C6A79E.69E62680 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C6A79E.69E62680 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@tutu> R0lGODlhQgIDAZEAAL7X8P//+wAnWP8AACH5BAAAAAAALAAAAABCAgMBAAL/hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1q t9yu9wsOi8fksvmMTlcHAyeb8VbGOXOXQBDCA/R6233TB1gReECoBsSW2AZQp9HY8mgQOTG5 UllxaWLYQbgJ4/mJEQi6Qwr2mEm5CJOK0WryChGbN9J5Y9qCyzBKpBt197eAuqp4EDdXzJic rMDsvBipCN32djxtnNi8nK3NLelt/a2NjXz9XU6+GoEHjADcx/7O124Qv9dOn8BXX1iYr/+v Xz5794K9q/fvIEKD/oLtKehuoAJ4/R7Ks+jQXcWC/xQrEhSYUSHGi/FGScwYRN6mYeKUtWTp 8qW6lthk0qwZU1pOc+ESoIuJoKdQnjN32jSKdJY/jxrvbeTllJ/Uh/qk7ptKtYEhh/M2Uu1o daLYrF/BNt36NOxSrFOvqrW6ieuCrljlkqVbRKUwnUmJpjOHNOjMnsqi+cU59CZNwogPJ/bp OPLRuQHv1r2MGWpWtF8te5079q1ns24/d2Zq+nRVdpsxs+VHOvOuplU9y0ZtRO84yOfA+Z4s rWjhv+omPV7smxnOwI17h4MGtPGzctvIDTp70TZUzWbVotQNsPJ22qrBJ7Q7/qnCuBZb2yYr 0Gvp0uThra+P/f4R8IJ3G//+SVgrjKWz12RAPeMAgEUdJ9g0wg3Y23ISRgdBerW1dRZt3Z3G Wmr4XajaaB6adpWFIdIHW3uiaaZRbCKChtuJH7KHhEi83YgMgUf9xEgDARq4Y3HE/CbJbswF aYyEhi2m44GKzWLifPK5tmGJGJJI3m1asvialTFKCV9aX2Y5JW4Mwbiiay++5csQwSHXSJzT RdiNkAruxU0deg7mDWQOPgiYcnsWSOeECBYmnAPZLeQio2W6lyGkNkYknkidSNSQfVxhytGj 2XnSKD5ksmWjqGEyahI9l3bYFqdtHgLrE682MSsZtT5wa6y67hqaFrmC8atWvA5LbLHGHots ssr/LsvsC216Oaqvwc6GAo3NXostZXatI9prvpIwrQThepttuWWYiGu3p2YxLpqaeNCuufI6 wd55KIXY6raaWrtvmR/BFpKrn63HaWf23tupo1eGx9AfbvU74rwSbxFXR1yiCKbFZGo8ZlQA dQwWZ2uW1fHGkYa5Hccykjtxy+wWDGaMaaaoZnxa4uuvhu3xe/LKXKKss7Urq6idy0aHkfGi 6sbMKn82j4xiZouyxqrOIPdc8b4hUTsz0eYdDXYXGSvaJZWQCusiujmDRjWaUd5MStREzxi0 h/GGjXcOb7+Hc8zvgUo3QuTuvfCFFp7JZtxbhob439HmDTmtMGc6lsiT/64KCuaU4kxlQBvW Ze/QplKaasjaDg1fqZGvzvq6rb8O++t3x0577bbfjnvuuu/Oe+++/w78xEoZGcPwshhv/Ayv JN87wulOMbslfCaYqGLESz8hHdUfb8Ty28cwa/QrzJ6r+DV83kNyjnxfPPvrZ8B8EPGXEH4S 5ItCBfqfVHaOdYVak6dtKKhPDRrSTvZUjWJQZ0h9Ug6i/lQTOTWJL86ZIDX41MDfJLBJD+Rg hSBCOYCVDlUYUdin+BeyyZWwRQGTi0qo1kKKxFBhKwTJCGVjEBSexHmWAiEJWWYHpSWpGhTq C5CQVMShZOM4F2yOEYu4HCVK8ImPkeL0qKhAyf8cSVwqI9nMTEItFlkOboKbyOfwAsYv8swj FbsaGyOWMiy9sWvmu4DTikTEBWoRgVVc0GGQGMU9AsZIDOoPFpEIIUQOso9HDGHgvog1YTlO LGnr2YdqI8ZIrquS7hpbyTpZM6iZzQ9CLNIhT3nKYVSHOE8yICoJiJxGpjIyq/TPnxjDyAMp JWX6gUsvU/fLO3pNk4BTj6ouWZZfWk1dZByZDx+Jsk9p0nVBnJQpc5nLWV4vOjAJpCJvZMgn 2vKbWzTOH5UkSHByS2Y3e5Qo08VJZr4zk+zc5Np65Ul5igx13iJcHe3Ivx7hKJ26JGc4F0kM Jt1JnNZbqDnJyUTrARL/oQaVqCQh6UY1+a2YW5Lb3uiJUcZZ8p7l8Sg+Q/nRtXSPkKsMEACz WUBDZZA6unQoLLlJJJYutIP/SxQFEYVODvLFgRUqlQoTthBgDiSHzlNqqjjHkdLRZ3SbKVh9 rOqp0M0noD1MTVfzdbbgucF9hPrBP98FgrOKda0oIKoqUrIfEaiVrXStq13vite86tUF8yvr +yTQV8CSdXwciBe02MUsoRHrTdQTQWAvwaMTBBag1tSA4iZgizxUtrB4U6wF5uqDyBYBsoMF wWQ/Sz+yYRZE8HpcBkB7LnfZ8Qqb5dGhgFooPzFQqAEETgCXyMDgAgpOrkwMLm+q2o/REISH /1MVwRAGLYiZEboa2uFISBdVGv7LYDzc4Q1LeJCDZRW6wXRkSUhYEoc5EqmwdVYpCzrQVjY0 UH5U6Dl9W1GI0nI4hXxer8zkzK4BjUPulO087cPOzJURk1XCDshMF1KoNpPBGfWZgaEgTMZW 8EgQculf5BuYoRZXi4bEJkEhZM2vVQ5EUdvoiuf2M9bOE5osMynfZlyyLuYTlDe2cIVbbIUM N9GJNHWOHw9VSBPHEpUx1a8i3XpRwymzucfM1L1KhDnyVkqFILWqNGH0M92kVEw+ButJtVPe A1tqa1UQ8pIHlMjsMVmb8IWpBZ3MUAoUE13pIVwYaQbEGwvNxZik8f8n+0nMZe54n80cc4Td RtuA2hTEOQLniIFD50lvEbeZJnFp93yyph2W0JF6mMnkyGKNvridh8YxHTN6ZcY9bNGNPnUZ BsXTlza5TgedjnCJu9sFOvF6txWxb3c5NSs3ZNmzXuo8qFue9ZKO0eadUeiya88ef7Wq25LU ek212dGJO80Q0RS3pUvNsJ2WWO3dKyfcPQLkTqyp8C5Fve+N73zre9/87re//926ddMgzvIr bQrkLVmDRwC427yBwC/w8FWHorUlwDUcFB7aQY4W4xXnuAcELloo2gDkBo+4jFHr3ygLouPh 9CsTTA4Jj8db5toLQSZgXnPTlpzm67TsB1P/vnJRSFpId+ZpfHuKDl3zRuk9lUlyfHrTnyJZ 4xvmdK6HLCjkClCVwSUyfUPOaV/fsqbCrnrYtf50O/2n6xvWyQbPvlqmfhfLzt7Kc58td696 d9qvfS+ulXz0Kb50yHh6O0zgfF914rnDJx67nfNMaYKWuL54lDzgI0pwOh9U825PvFYaVWqJ 71Nt9XSwgAfh9+A0fpwUYlAl/v5r5uy0gJS/fO1X7/X5NlLwbA9xLWVqUNsDKZHGhjzvJ0r0 TXNN290CvapdJ7cf972ysG8p1V0qXI1HXe2AH46RWT/577sEOoe/JYkfaH7WmzP7Le8+8F9J y95y+KeLp3zufR/+/yJebtpaE/Ad6Zll/ZRmMcZF1Jd85ad7rXd9w6VOCIh/cjZs9+cn/aN+ t3cT3UQomUd8RPJ4xydOHXhfpIVnLcd5B0h1UTZobHJyyERoozdhlOUJsJckxqd9gSJRGFhp 7uckR5d/lYZTGWiDDJWDCRV42/MjnZaAPdJ92eRpO9iD52dfwWeCFsVjGIUxtvZOS5NoCzZz vTZA68d0cOdBrcRH8dd7umWBuWVxaMhb8teGUAd2WbdTFFR8ulV0HlZ1U2dBYPhH9Id0l9Y/ cgJ2y4dU2EZ3m9JdeLc5hqgtjWNu7fZWdIVzAEeJ3CNWUFaJmaiJm8iJneiJnwg+PvcFpv/w K9MSLL5QPtfxX2rgWUpAb/gDLKJIiBgGdCcAiak4WxGjA5BYYK4ILkgjixdGL7WIViyAiygX aHoTirrYC7/4Mi40Q9p1GSdEXeK1MNK1Xez1TO81NXXnQ/tgjSRRbSgkQmwTjT+kaCKkXuSY L5X0HdvoXeEFj9AIaWEhjux4bjnzjtbobQwjjUxxMLw4A2hUNqjhZ3YHaw/2c+iBhfnEMd0m fR7DGRApkS94jSvSYBGGFxHhVQuWRj6jYFeyVahGax7DkSF1RiRFkD1GW6zWZ9M0YK/WNqwG ZjBZayIZSmXGTzvpaKfSNjo2Kk2zhWdWaO60Y2wzTJO0Gio5ONP/9JNc05N+E2TkxmVwU0r+ tDNWFn1fdnqu9pDVVWUaKXpnJmZBmZX+h5Q3SZRcOUllSTYziTr1wpTZ5ksn4TXiNpQ7CT02 6WN+xmPccZY+uXwlCU2m5h15SZitRnox9pRoSUlzyVE6CYDCGB9CqZQtApmD2ZRwaTiImZNS 4Jd9uRYgNZeFQ3peaTkOaZCemYWKOZQ8VJp0uSaNU5jPh5JQCZOR2VxN+Un6E0+O2CrS4lze WG1JZW6FqGzS1h3bxjBMo17TlY8XKTprJmrdNpEbY1QtRJfc8Zy8+W3PCSrZSZtUhY12M14s qTnM5p3RSWb4pFWdUzWsI5D7dj8TlwLz/wmKyZifq0ULzkJY+wmgASqgA0qg/3aM/2kHaYWf Bcqg9uafFMcDC9qgASqQhuUDEjqhunJe46gvOnQm3ZiIMhRDWVOedIRVGyqNYmZd4XWOKPqN CZGhvMOQc0RgKjdgBEijUhmT0cZ80aSQpumR7ZmjGAKYMao7USlPBdmepGiROypDvdg3rJmF KelMRWqkuMNLYVlS4Ql6wsSWOvqiqjNetDkaX1qaKaSlU5VsV4qlIxVgl7WcKZeYEoeZaklS nuKUEZlZq8imsIOkO/piLphqswmnoRacbyqlWCmWrYGjfeqn4rk2ldVVIMqlwGmc0zV3xnRu GAOpGnVUaGqpYf/aqI4KORjqBaZKqvqGqlywqqnqqq8Kq7Eqq7NKq7Vqq7eKq7mqq7vKq73q q78KrMEqrMNKrMVqrMeKrMmqrMvKrM3qrOYSANEqrdNKrdVqrdeKrdmqrdvKrd3qrd8KruEq ruNKruVqrueKrumqruvKru3qru86riAAr/NKr/Vqr/eKr/mqr/vKr/3qr/7aAf8qsANLsAVr sAeLsAmrsAWbAdZqNNQ6BhD7BBJbBBS7O9XasNMKNhb7BRy7BB4bBCCbOyL7ABh7NCSrBShr BCrLAyxLOyZLAS6LLTJbBTQbshq7sjj7OzYLADD7sDoLBjz7A0JbA0S7Oj4LAUjbMkb/WwuQ yLSaxQFPGwNSizdK6wBWKzFPK0wnuQtOC7Tr8F5CF7VfC7YrWAJUGzZYywBqK1d7igVai2Cf pyheK62op1KAEC5CC6MsgLYba7Nsq1mjCgVwq1J3p4jYtlybNQE8uynf6VxlhIgI1lR6W5Ha RReveLVke7F/27fc0qGNm0PYNbSai1lxe5KNCzCQe7ntwrhxG7pR8bqve7qKS7nosbqqm7F1 CzyAmwC8+wEfgZDl5jC36wOE65EEc7ewS7yYKwGtu2a4q7zQa4i4QLmwC72x+yud+7Oku7ba +zyIc0LXu5E7ALfPG71ceL7mwbwly71da5IqKr7xa5Ldq7t6/7YUy9sh2bi47Xs7vnsA/vtu goO/4qu4NmC8yiW730G8lLEBrXu8ZiS/2Iu+C1C9TrHAw6kB3ru0nMu/aXW/EbzAQHDAs/vA qXu+wNTAHaxcJzzA6RvC9ButyMhcaPSRF6DBEwPAPXvDgynBLhykxavCctuIx4m8EkmcGRzE d5t3yTm9yYm5FXy8AcO1NpzEsJPDORx0UdzDkSvCVTwFOwzBJwDGJjDG0MrB9bu9MSwGZVzA H1DGJPDG2XLFcVwGdNwDdpwCeOzGXtw6c8zHyqLHOhDIZPzHNDDIyeLHhXwsh3wDjDwCjpy7 auw7Dru/kJyyiuwEliyvmDy1nJy2if+syVYQyp2MxkwwyjHryWl8xgvLyq3syq8My7Esy7Mc rqhMy7eMy7msy7vMy728rbbsy8EszMNMzMVszOoKzMeszMvMzM3szLKczM8szdNMzdVszeka zdeszdvMzd38zNnszeEszuNMzq8MzuWMzgYrALo8AOnszrVcyd0qD9F6B+H6Du4KDMRcz9Ka z+a6z9jazwh7zwEwz/T8z9ca0AXNrtJArWwwrYqwrRAtrQzdyipBrwc9ressrhrNsPG8rf+s 0RjtrSKdriSdywNN0Ots0iPN0QDd0gW7zyFt0DO90vUc0y+9rg4dre080TodADrt09YK1Dz9 00T9yhyN0+3/mtTCfM7WitEKjdIondIurdJIndADbdMhfdUpXdUr7a8gXdVOndX83M9QjdVX DdYBPa8mfdNTjdBhzdVLba5B/dA+PdTZetc7nQiwrNJk7dZcndFeHdf0/Ndb3dZp7dcHPdbz 2tRi3dKKrdVuDdbZms9PDdcEbdAiPdaVHdkHO9lsvdh+/deFTdNwvdiCXdJqPdNTXdOmvdo5 LdE7XdQ9rdd4zdN2XduurNaKzc+E7dtO3duSndGB7dsxPdyiLdOj/a6N7diindmcHdVyLdla zdnVutv3fNgKDdNWrdzITd1t7dyJ3dXQLd34DNmB7dVS3d3pKtG3bdQUja3wTdu6/43ZwU3W Za3e1JrQ9l3fv53c/Q3gSO3f9crcb/3ayk3S6R3Z2W3d+F3aD76wn73UDD7dxK3fYZ3gqn3R j43TqG3Z7UrUQx3b8x3RRp3bFW3d+p3i3/rfj33c9S3g/B3jMc7YHq2t3C3cIE3aB97gGL7g M+7jD17dv73d4v3WQV7hmK3jrH3Zpl3eJX3gHx7er93ZOU3iJ37ls12tuI3lEb7i/E3kAB3c NB7gYy7jL97iBG7jlC3VaG3VN53fEB7XWQ3npY3dTo7a+WrRgG3gaY3fb07dgH3WGv6u6o3Y Fp7ZF/7k4irfFD3iWP7oj66w1+3m9y3Xgy7ogw7olt7VfP8e5+xa4F+96Oea57Rc6rw86gpr 4u8ssB1O6mrevBH+6aRO6Kg+68Gc6gm76qzer5Q+rrUO6mvO68NO7MVu7Kt87Mmu7MsuzqHO 7M8O7dEezM4u7dVu7dfOytSO7dvO7d2er9ru7eFu7S+05+IOruBu7une7bmu7uiu7u8+7vDe re4u7/W+7Oye7vRu7/te7Phu7vrO7wH/zv4u7gAv8AdPzgQf7gaP8Nys8AO767r88N2u7WZt 6Z596gnr5hMv2MD+r23O4SF/434+8UW913od1JK+5SeP8nS9riW/7dS+5AaO8Sft5Kn90TDP rsY92BAe2g2e5OfK5Xmd19da9C7/r9QNX8Us/tKG/uaZXucZ3uQb7/OGTec6v9F4PuGhremA /t0X/9xYz+ZibeRM7tLTnfFGv+pE7962feIqr65iX+0VL+XhvdmdXdlHjuBN/txAT+dB3+vJ DdqXvdrnXdxIftpyf+RN3+E/fvY8n/Yrz/Js3+UN3fayreX4rPSlzL5Mz+EXTtxXD95nj/Y/ n+icXuHlzq+avfWFf9aIbuQWfevm/fmwf+tOj66xDd/yLdSSjvRQvvkB4O6TDftKzuPrbeGJ 392vb/bN3+pJDdpVH+WN7/zorfhjb/fQ/+R1P64hvvbf360u//voev3QLvPOzf2eDuQjj/h8 b/YMPuQA/67nTX/8ia78Ob7+XA/48FrlBBAp8pIVeTXzjJMXy8HGbv0CP08jTTJLVWht3ReO 5ZmGgRvPdSA+fMeHCEYmlCCQeFkQh8Jf0dKcTIuU2rVqTEqW2iMUCYR+h9jeM+t8oi2QLbvW kXPmdNFodE/IUWaM1S9QcJAwZucQp1BRCXCRyhGyYSuScqWxcrAPM/Jy0/NTEBER1Kxs8Yt0 0DR1s5NVRvM10FW21lb00FZ3l7fX9/eX1g3VcVKhRvg0OQN3B/gZOlp6mprrxahyeVr7olmn GjxcfJzcT1vI7ZENjjHCaTjd/V0syqorZW0+qsY7p/wfYECB1M4lMciiwrEM2P+o2JP0ACJE SQ8VRsSH0F1FbhL6JRr4EWRIkZTOJVQ4TB67hwxNtmTI0iVGhAvXyDwpo+ONkTt59vRp6ZoS a0NhSLzpsOLMmElvEjWaEKahnD+pVrU6sCTRpi0vMl168ilSsGMX2oSqVGrHq2vZtoW2bB0q uSrDjOmSjwmaMj/w0mpyF8lGBjl5uDV8GPEnwb0aLRZai3BiyZMpzyoX1zEYyFMrd/b8uSxo WZFFlzadOPNpM6RVt36V2lasf7Bdz2B9jdjKxsaw0A1pkPcZS8FlEQNuj7jmVVf4oNBDJ4/s 6NGl96jt6XYLJiqMJafhPaBefciSgQeVsUo8i8HvPTL/c8cDnxDw41cXQZ8QbU4E9XPkjLsd 5Cjqrr30Aqunrin48m0XfQpcSZ2+vEhpQpT60+6SvBoaj4t5cqPhOehKOGEP++qzozrrrvuj kOyG67CNCDXrkMMCI5rkngVjBMZBDuF5w6J0NFJwvSBJguM49fDxcEcQ5cPjgwDwk9LEEjmw 0pwr8olRvAhTotGLJdGBh8g28gLkwsH+c+GuLbk0EsYNdaRRNw/VYLAWIx+kSE55+BzwzjbP A07JBP9Asr8nsdxjUSrrSKG5+Sz7ziaWtJjoKEzP2oqFMV8y6iWl0kzARe6KfFNI3vxcdTc/ y3xVGilgjbM9V5ssk0DzBCEU/8E/l4yTOREbbU6TEDMI0dgZMlvluO001Uq5Dzs1iQyzKkTL j1J/fVXDejrRkVWM3gl3Tq54vFTVHIPMyFl1O4UTEjg15PXWdmkjUVgo9W1UWHxLQebQZ9H6 NjS4KgiLrFAzJURbMa+VFTBGvFzwSyKPqBVPXeZyxUZTxPuS4ht1LeVjvMgUkp6TmVOUWBTr Q9a5R0tMVlmAh4qqKZjEeoq7gxOuFGFsV1szz1G3/Wnk2f5JUZzULtZTwpM9xuxbiP8CA+OQ 02x40IzJS/oyaX9beuwVK+Ha7LTVfsbotRtA2+245U6lbbnhnhvvvOPVOxSi+f4b8PwCx+Lu wQ0/PP80xNPqR/HGHe/q8RYKj5xyvOsu6ruCMOxl8so9X/tykjDXjnO/Pz/dcla6bFZTW5dQ +XVeOkeddtVCZ5PPoBfeFD3eb7fN9NqFX/F3oGbi+VmFoaqW01dmH76z4iFhOhzpIae2+Z1/ dqp0tYoiA08crcdtfBmi7k0Yr0nZ2EKVD51Qv0jzdTRmmlGkblLVWydr4d6Rx152wftVt44W DbBhgl4k25wv0IMxGLHHToKAz8xihqX7VIlK8/sX3Z6mhpQxy059ad8uZtcx3RzIQFkQw19y NbERZg1dglIEkNLVIwrBL0EbO6Cy0BTCGA5QZH5Ilh4uaEEM0sd+KoJeCXv/FDD37MiBOXri CnuoDkMhaE47NJW9aFIjeX2KWxHMBjsaeCqaNORWsFDUsE6UQTceq41S4pfNlijALgrohbsB FBbRQSAzPa0dddpQGmboxTP26YsSa5MMPREXiV0RTMDCwhqfIz/6pciSGqQU9ALAxEcOcoqE IlcfM2TGPRkoXLMq5BPT1StbhXJcpdRi5lDmqyl+Mo0x8NcbSyApF8Asf8PzJLBc5T8BjfJg sgyjFXF1qnK1rVa5BNe6JMJFG4FSdNgcUi3FJ6735MtYwNxXvzRZM052Toc3vFFgPCih15HR hiGjxyJjCcldJemMZzJZXSiGSrEVUp9hShkUaShE/5bJj5IyY2MlFaolTnbSjrOR3iyPVJXy FYJ64Lhoa563jX+SjKKc+ChWyAaSjaqmow9VqVtOepqUrhSmVmmpaV4aU5v2ZKalqelNeapR Fi5HeDvt6VCJWg2hFhWpSe0e45TaVKeOgzCFeepUqfqLqEq1qlnVKiuuitWtfhWsjuiqV8Na VrMSbqxkPeta2cqMtHqkrXGVK0Tf6o+53jWsddXrXvnaV7/+FbCBFexgCVtYwx4WsYlV7GIZ 21jHPhaykZXsZClbWcteFrOZ1exmOdtZz34WtKEV7WhJW1rTnha1qVXtalnbWte+Fraxle1s aVtb294Wt7nV7W5521vf/jQWuMEV7nCJW1zjHhe5yVXucpnbXOc+F7rRle50qVtd614Xu9nV 7na5213vfhe84RWvcgsAADs= ------=_NextPart_000_0001_01C6A79E.69E62680-- From ftp@ums.pl Sat Jul 15 01:15:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1cUs-0000Pb-Ad for dnsext-archive@lists.ietf.org; Sat, 15 Jul 2006 01:15:22 -0400 Received: from xdsl-260.walbrzych.dialog.net.pl ([81.168.203.4] helo=umserver1.ums.pl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1cUq-0005dy-2i for dnsext-archive@lists.ietf.org; Sat, 15 Jul 2006 01:15:22 -0400 Received: by umserver1.ums.pl (Postfix, from userid 78) id D893B173EAD; Sat, 15 Jul 2006 03:03:29 +0200 (CEST) To: dnsext-archive@lists.ietf.org Subject: PayPal Account Limitation ! Message-ID: <1152925409.59627.qmail@paypal.com>> From: "PayPal" Content-Type: text/html Date: Sat, 15 Jul 2006 03:03:29 +0200 (CEST) X-Spam-Score: 4.9 (++++) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 PayPal
PayPal June 2006



Dear user of PayPal services,

    This email is to inform that we had to block your PayPal account because this ip 64.12.117.14 tryed to access your account 3 times.We apologise for the inconvinience but the safety of your account is our main priority.

Secure Server

To remove the limitation login to your PayPal account!
To remove the limitation, read carefully and complete all steps listed in the link above. !!

 Your Account
Tips to Protect Your Account
PayPal's world class fraud investigators share 5 important actions you can take to help prevent identity theft and protect your account.


Update Your Profile
If you've closed a credit card or bank account recently, remember to go to PayPal's website to update your profile.




 Identity Protection Highlights



New spoof tutorial
Learn how to spot and avoid fraudulent "spoof" emails and websites with PayPal's handy 5-step spoof tutorial.


Protect yourself with tools
Guard yourself against "spoof" emails with the SafetyBar, and against fraudulent websites with the eBay Toolbar.






Checklist if you are a victim...
When you suspect a problem with your identity, you have to act fast. Use PayPal's checklist for what you should do.

 Merchant Offers

   
FREE Norton AntiSpam download with purchase of Norton AntiVirus. Unlimited listening and downloading. All the music you want. FREE trial. Learn about and fund locally run social and environmental projects.
Thank You for using PayPal!
This notification was sent to you by PayPal. To modify your notification preferences, log in to your PayPal account, click the Profile sub-tab, then click the Notifications link under Account Information. Changes may take up to 10 days to be reflected in our mailings. PayPal will not sell or rent any of your personally identifiable information to third parties. For more information about the security of your information, read our Privacy Policy at https://www.paypal.com/privacy.


Copyright © 2006 PayPal Inc. All rights reserved. Designated trademarks and brands are the property of their respective owners. PayPal is located at 2211 N. First St., San Jose, CA 95131.
From owner-namedroppers@ops.ietf.org Sat Jul 15 22:52:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1wkM-00038s-5E for dnsext-archive@lists.ietf.org; Sat, 15 Jul 2006 22:52:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1wkK-0006xF-QH for dnsext-archive@lists.ietf.org; Sat, 15 Jul 2006 22:52:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1weo-000GfQ-Cs for namedroppers-data@psg.com; Sun, 16 Jul 2006 02:46:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1wen-000GfF-3P for namedroppers@ops.ietf.org; Sun, 16 Jul 2006 02:46:57 +0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id k6G2ktXu004652 for ; Sat, 15 Jul 2006 19:46:55 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6G2ksPU010771 for ; Sat, 15 Jul 2006 21:46:55 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Date: Sat, 15 Jul 2006 22:46:52 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790012338C9@de01exm64.ds.mot.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD37A49683@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Thread-Index: AcZRvrqACtxzM9FySdCHbcbNLkHKFAAqFAaQAsR8PjASwivhMA== From: "Eastlake III Donald-LDE008" To: Cc: "Hallam-Baker, Phillip" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 =20 Phil, I agree that the DSA algorithm DNS key/signature format RFC should cover the extensions by NIST to DSA. As to what algorithms should actually have what level of implementation requirement, that is a different question. From the start of DNSSEC, I have thought that ECC, with its shorter keys and signatures, would work well. There are some problems with patents but those do tend to get sorted out eventually... :-) Thanks, Donald -----Original Message----- From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20 Sent: Tuesday, April 11, 2006 11:19 AM To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org Subject: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt=20 NIST has recently proposed a new version of DSA that supports 2048 bit (and larger) keys and SHA2. I think that the draft should be updated to cover this new algorithm as it overcomes one of the principle difficulties with DNSSEC deployment, the size of the signature keys. DSA-2048 with a 256 byte subgroup has the same key size as RSA: 256 bytes. But the signature blob is only 64 bits. The cipher strength is equivalent to 112 bit symmetric key cryptography as opposed to 80 bits for DSA.=20 ECC certainly has benefits but at this point I can't see us navigating the patent thicket quickly. It is much easier to get cipher hardware vendors to support the new DSA than an entirely new algorithm.=20 I propose that we reserve 2 signature algorithm identifiers for the new DSA signatures: ID#1 for the DSA algorithm as currently specified. ID#2 to be issued on completion of the hash algorithm competition for DSA+NewHash I don't know if this would be best done as a separate draft or as a continuation of this draft. My preferred solution would be to create a new draft using the same text.=20 The one drawback to using DSA is that public key operations are slower than private key operations. If you operate a large domain this is not exactly a drawback :-) but my interest here is independent of the registry, my concern is DKIM where this pushes the computation load in an unfortunate direction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 16 05:02:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G22W9-00043G-Cr for dnsext-archive@lists.ietf.org; Sun, 16 Jul 2006 05:02:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G22W7-0006QD-TD for dnsext-archive@lists.ietf.org; Sun, 16 Jul 2006 05:02:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G22Rl-000Gea-Em for namedroppers-data@psg.com; Sun, 16 Jul 2006 08:57:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G22Rk-000GeB-1K; Sun, 16 Jul 2006 08:57:52 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 16 Jul 2006 09:57:50 +0100 X-IronPort-AV: i="4.06,247,1149462000"; d="scan'208"; a="4027276:sNHT33974152" In-Reply-To: <6.2.5.6.2.20060713132351.030fac70@ogud.com> To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_co-chair?= Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: Key Rollover: proposed way forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Sun, 16 Jul 2006 10:57:46 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/16/2006 09:57:48 AM, Serialize complete at 07/16/2006 09:57:48 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Olafur wrote on 07/13/2006 11:11:08 PM: > The chairs also noted that some of the proposals looked complete while > others needed more work. The chairs asked for the sense-of-the-room > if the working group was ready select one proposal for in depth > review with the goal of selecting that proposal for advancement, unless > problems where discovered during this process. > The sense of the room was that the members of the WG present > supported this. > > The chairs then proposed that the timers proposal be selected. > After open discussion, the sense of the room was that this was an > acceptable choice. > > The editor noted that text in one section (Trust Anchor deletion) > needed minor word tuning and will issue a new draft soon. > > The purpose of this message is get confirmation from the mailing list > on this path forward. > > Please reply to namedroppers if you support or object to this path forward. I support this path forward. Roy Arends Nominet -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 16 09:04:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G26IW-0001W1-Dc for dnsext-archive@lists.ietf.org; Sun, 16 Jul 2006 09:04:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G26IV-0001sv-1f for dnsext-archive@lists.ietf.org; Sun, 16 Jul 2006 09:04:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G26Cq-0004hV-Ok for namedroppers-data@psg.com; Sun, 16 Jul 2006 12:58:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G26Cp-0004hH-Sr for namedroppers@ops.ietf.org; Sun, 16 Jul 2006 12:58:43 +0000 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k6GCwdnX000930; Sun, 16 Jul 2006 05:58:40 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Jul 2006 05:58:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Date: Sun, 16 Jul 2006 05:58:40 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD645E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Thread-Index: AcZRvrqACtxzM9FySdCHbcbNLkHKFAAqFAaQAsR8PjASwivhMAAVZ31Q From: "Hallam-Baker, Phillip" To: "Eastlake III Donald-LDE008" , X-OriginalArrivalTime: 16 Jul 2006 12:58:39.0159 (UTC) FILETIME=[8EAA2C70:01C6A8D7] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 I think that the first step here is to get a document out that details = any changes to the DNSSEC spec that may be necessary. When the DSA part = was written the DSA key size was fixed and so was the hash algorithm. =20 > -----Original Message----- > From: Eastlake III Donald-LDE008=20 > [mailto:Donald.Eastlake@motorola.com]=20 > Sent: Saturday, July 15, 2006 10:47 PM > To: namedroppers@ops.ietf.org > Cc: Hallam-Baker, Phillip > Subject: RE: New DSA key sizes RE:=20 > draft-ietf-dnsext-rfc2536bis-dsa-06.txt=20 >=20 > =20 > Phil, >=20 > I agree that the DSA algorithm DNS key/signature format RFC=20 > should cover the extensions by NIST to DSA. >=20 > As to what algorithms should actually have what level of=20 > implementation requirement, that is a different question. >=20 > From the start of DNSSEC, I have thought that ECC, with its=20 > shorter keys and signatures, would work well. There are some=20 > problems with patents but those do tend to get sorted out=20 > eventually... :-) >=20 > Thanks, > Donald >=20 > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Tuesday, April 11, 2006 11:19 AM > To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org > Subject: New DSA key sizes RE:=20 > draft-ietf-dnsext-rfc2536bis-dsa-06.txt=20 >=20 > NIST has recently proposed a new version of DSA that supports=20 > 2048 bit (and > larger) keys and SHA2. I think that the draft should be=20 > updated to cover this new algorithm as it overcomes one of=20 > the principle difficulties with DNSSEC deployment, the size=20 > of the signature keys. >=20 > DSA-2048 with a 256 byte subgroup has the same key size as=20 > RSA: 256 bytes. > But the signature blob is only 64 bits. The cipher strength=20 > is equivalent to > 112 bit symmetric key cryptography as opposed to 80 bits for DSA.=20 >=20 > ECC certainly has benefits but at this point I can't see us=20 > navigating the patent thicket quickly. It is much easier to=20 > get cipher hardware vendors to support the new DSA than an=20 > entirely new algorithm.=20 >=20 >=20 > I propose that we reserve 2 signature algorithm identifiers=20 > for the new DSA > signatures: >=20 > ID#1 for the DSA algorithm as currently specified. > ID#2 to be issued on completion of the hash algorithm competition for > DSA+NewHash >=20 > I don't know if this would be best done as a separate draft=20 > or as a continuation of this draft. My preferred solution=20 > would be to create a new draft using the same text.=20 >=20 >=20 > The one drawback to using DSA is that public key operations=20 > are slower than private key operations. If you operate a=20 > large domain this is not exactly a drawback :-) but my=20 > interest here is independent of the registry, my concern is=20 > DKIM where this pushes the computation load in an unfortunate=20 > direction. >=20 >=20 >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 17 03:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2NCS-0006wv-9D for dnsext-archive@lists.ietf.org; Mon, 17 Jul 2006 03:07:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2NCQ-0003SL-Tj for dnsext-archive@lists.ietf.org; Mon, 17 Jul 2006 03:07:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2N5H-0009GX-N7 for namedroppers-data@psg.com; Mon, 17 Jul 2006 07:00:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2N5E-0009FJ-Mg for namedroppers@ops.ietf.org; Mon, 17 Jul 2006 07:00:00 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6H6xtY7021395 for ; Sun, 16 Jul 2006 23:59:59 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6H6xtdU015457 for ; Mon, 17 Jul 2006 01:59:55 -0500 (CDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Date: Mon, 17 Jul 2006 02:59:53 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900123391C@de01exm64.ds.mot.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD645E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Thread-Index: AcZRvrqACtxzM9FySdCHbcbNLkHKFAAqFAaQAsR8PjASwivhMAAVZ31QACWzYIA= From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Maybe we don't mean the same thing by "the DNSSEC spec" but I don't think that changes to extend an algorithm like this should require a change in the DNSSEC protocol spec. Just changes in the DSA key/signature DNS format specification and in the linking document which gives the algorithm IDs and implementation requirements and limits. Donald -----Original Message----- From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20 Sent: Sunday, July 16, 2006 8:59 AM To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org Subject: RE: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt=20 I think that the first step here is to get a document out that details any changes to the DNSSEC spec that may be necessary. When the DSA part was written the DSA key size was fixed and so was the hash algorithm. =20 > -----Original Message----- > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake@motorola.com] > Sent: Saturday, July 15, 2006 10:47 PM > To: namedroppers@ops.ietf.org > Cc: Hallam-Baker, Phillip > Subject: RE: New DSA key sizes RE:=20 > draft-ietf-dnsext-rfc2536bis-dsa-06.txt >=20 > =20 > Phil, >=20 > I agree that the DSA algorithm DNS key/signature format RFC should=20 > cover the extensions by NIST to DSA. >=20 > As to what algorithms should actually have what level of=20 > implementation requirement, that is a different question. >=20 > From the start of DNSSEC, I have thought that ECC, with its shorter=20 > keys and signatures, would work well. There are some problems with=20 > patents but those do tend to get sorted out eventually... :-) >=20 > Thanks, > Donald >=20 > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Tuesday, April 11, 2006 11:19 AM > To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org > Subject: New DSA key sizes RE:=20 > draft-ietf-dnsext-rfc2536bis-dsa-06.txt >=20 > NIST has recently proposed a new version of DSA that supports > 2048 bit (and > larger) keys and SHA2. I think that the draft should be updated to=20 > cover this new algorithm as it overcomes one of the principle=20 > difficulties with DNSSEC deployment, the size of the signature keys. >=20 > DSA-2048 with a 256 byte subgroup has the same key size as > RSA: 256 bytes. > But the signature blob is only 64 bits. The cipher strength is=20 > equivalent to > 112 bit symmetric key cryptography as opposed to 80 bits for DSA.=20 >=20 > ECC certainly has benefits but at this point I can't see us navigating > the patent thicket quickly. It is much easier to get cipher hardware=20 > vendors to support the new DSA than an entirely new algorithm. >=20 >=20 > I propose that we reserve 2 signature algorithm identifiers for the=20 > new DSA > signatures: >=20 > ID#1 for the DSA algorithm as currently specified. > ID#2 to be issued on completion of the hash algorithm competition for > DSA+NewHash >=20 > I don't know if this would be best done as a separate draft or as a=20 > continuation of this draft. My preferred solution would be to create a > new draft using the same text. >=20 >=20 > The one drawback to using DSA is that public key operations are slower > than private key operations. If you operate a large domain this is not > exactly a drawback :-) but my interest here is independent of the=20 > registry, my concern is DKIM where this pushes the computation load in > an unfortunate direction. >=20 >=20 >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 17 17:09:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2aLM-0008LZ-Vz for dnsext-archive@lists.ietf.org; Mon, 17 Jul 2006 17:09:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ZLy-0002jA-Dg for dnsext-archive@lists.ietf.org; Mon, 17 Jul 2006 16:06:06 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2ZAl-0006Nh-Ex for dnsext-archive@lists.ietf.org; Mon, 17 Jul 2006 15:54:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2Z6d-000Cou-QZ for namedroppers-data@psg.com; Mon, 17 Jul 2006 19:50:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2Z6T-000CnQ-Nl for namedroppers@ops.ietf.org; Mon, 17 Jul 2006 19:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6HJo19R004038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G2Z6P-0007ZH-Pv; Mon, 17 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-trustupdate-timers-03.txt Message-Id: Date: Mon, 17 Jul 2006 15:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 : Automated Updates of DNSSEC Trust Anchors Author(s) : M. StJohns Filename : draft-ietf-dnsext-trustupdate-timers-03.txt Pages : 14 Date : 2006-7-17 This document describes a means for automated, authenticated and authorized updating of DNSSEC "trust anchors". The method provides protection against single key compromise of a key in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor. This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate-timers-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-trustupdate-timers-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-trustupdate-timers-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-17134227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-trustupdate-timers-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-trustupdate-timers-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-17134227.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 17 21:30:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2eQ0-0002u8-G0 for dnsext-archive@lists.ietf.org; Mon, 17 Jul 2006 21:30:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ePz-000171-0N for dnsext-archive@lists.ietf.org; Mon, 17 Jul 2006 21:30:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2eLm-000A0r-09 for namedroppers-data@psg.com; Tue, 18 Jul 2006 01:26:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,OPTING_OUT_CAPS autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2eLk-000A0b-SB for namedroppers@ops.ietf.org; Tue, 18 Jul 2006 01:26:13 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Jul 2006 02:26:10 +0100 X-IronPort-AV: i="4.06,253,1149462000"; d="scan'208"; a="4504664:sNHT31098484" To: namedroppers@ops.ietf.org Subject: 2nd NSEC3 workshop, 18-20 September 2006 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 18 Jul 2006 03:26:04 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/18/2006 02:26:05 AM, Serialize complete at 07/18/2006 02:26:05 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Verisign and Nominet are organising an NSEC3 workshop to be held at Verisign's offices in Dulles, Virginia, USA on 18-20 September 2006. The workshop will focus on comprehensive testing of: - signalling the use of NSEC3 to validators. - rollover of NSEC to NSEC3 and vice versa. - OPT-OUT unsigned zone reachability. - signalling NSEC3 parameters between authoritative servers. - using various values of iteration to measure impact. - using high iteration values to test functionality of 'treat as unsigned' - Functionality and interoperability of NSEC3 tools and implementations Participation is open to anyone with a serious interest; however, space is limited, and precedence will be given to people who have a previous involvement with NSEC3 or the development or deployment of DNSSEC. If you are interested in participating, please let me know. Reports from the workshop will be posted to the namedroppers and nsec3-testing mailing lists. Regards, Roy Arends Nominet -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 18 09:04:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pFk-00087e-34 for dnsext-archive@lists.ietf.org; Tue, 18 Jul 2006 09:04:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2pFi-0000Bz-Q6 for dnsext-archive@lists.ietf.org; Tue, 18 Jul 2006 09:04:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2p9i-000DaW-G2 for namedroppers-data@psg.com; Tue, 18 Jul 2006 12:58:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2p9g-000Da9-F8 for namedroppers@ops.ietf.org; Tue, 18 Jul 2006 12:58:28 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6ICwKK4015615 for ; Tue, 18 Jul 2006 08:58:22 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060718085554.038136e0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Jul 2006 08:57:53 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms In-Reply-To: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> References: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Reminder, So far no one has commented or posted a review of this document. Please help your chairs by reviewing this document. thank you Olafur At 09:30 07/07/2006, =D3lafur Gu=F0mundsson /DNSEXT wrote: >Dear colleagues, > >This message starts at 3 week last call for this document ending >on midnight July 30'th 2006 (Reykjavik time). >The URL for the document is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt > >The document is a collection of different approaches to flag >extensions/changes in DNSSEC. >The document is a cumulative list of pros and cons as well >as impact and issues for each possible mechanism. >This document is to be published as Informational to capture the >current knowledge of the state of art of signalling changes in >the DNSSEC protocol. > >The document process rules in this group, require that at least >5 members of the working to state that they have read the document >and support it being published. > > Olafur & 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. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 18 14:13:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2u4i-0004il-B6 for dnsext-archive@lists.ietf.org; Tue, 18 Jul 2006 14:13:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2u4g-0002yj-TS for dnsext-archive@lists.ietf.org; Tue, 18 Jul 2006 14:13:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2u08-000EZt-IR for namedroppers-data@psg.com; Tue, 18 Jul 2006 18:08:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2u07-000EZe-LK for namedroppers@ops.ietf.org; Tue, 18 Jul 2006 18:08:55 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6II8mlM013982 for ; Tue, 18 Jul 2006 14:08:48 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.7/8.13.7) with SMTP id k6II7lCC022442 for ; Tue, 18 Jul 2006 14:07:47 -0400 (EDT) From: "Scott Rose" To: Subject: RE: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms Date: Tue, 18 Jul 2006 14:09:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 In-Reply-To: <6.2.5.6.2.20060718085554.038136e0@ogud.com> X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 I noticed Sam commented on it, but I went through the archive and re-read it. I'm not sure if it is a valid issue to worry about or not. I do think it is odd that the document suggests on-demand synthesis of NSEC RRs while acknowledging it is not a path to versioning. It seems like a quick fix for the zone enumeration problem, but has a really big flaw in that it is a DoS attack vector, especially true for smaller enterprises. Maybe it should be mentioned again in the Security Considerations section. Other than that (since it is purely informational) I don't have any objection to this draft. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ólafur Guðmundsson > Sent: Tuesday, July 18, 2006 8:58 AM > To: namedroppers@ops.ietf.org > Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms > > > Reminder, > > So far no one has commented or posted a review of this document. > Please help your chairs by reviewing this document. > > thank you > Olafur > > > At 09:30 07/07/2006, Ólafur Guðmundsson /DNSEXT wrote: > > >Dear colleagues, > > > >This message starts at 3 week last call for this document ending > >on midnight July 30'th 2006 (Reykjavik time). > >The URL for the document is: > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt > > > >The document is a collection of different approaches to flag > >extensions/changes in DNSSEC. > >The document is a cumulative list of pros and cons as well > >as impact and issues for each possible mechanism. > >This document is to be published as Informational to capture the > >current knowledge of the state of art of signalling changes in > >the DNSSEC protocol. > > > >The document process rules in this group, require that at least > >5 members of the working to state that they have read the document > >and support it being published. > > > > Olafur & 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. > >archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 19 14:09:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GTv-0005OC-Lq for dnsext-archive@lists.ietf.org; Wed, 19 Jul 2006 14:09:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GTt-0003vU-OG for dnsext-archive@lists.ietf.org; Wed, 19 Jul 2006 14:09:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GNq-000J6A-RG for namedroppers-data@psg.com; Wed, 19 Jul 2006 18:02:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GNn-000J3V-UP for namedroppers@ops.ietf.org; Wed, 19 Jul 2006 18:02:52 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6JI2agm030408 for ; Wed, 19 Jul 2006 14:02:37 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060719125045.0371ae48@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 19 Jul 2006 14:02:24 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC: RFC2929bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 This message starts at 3 week last call for this document ending on midnight August 10'th 2006 (Reykjavik time). The URL for the document is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt This document updates RFC2929 which defines how IANA handles registrations affecting the DNS. This document attempts to liberalize and speed up the process for getting new DNS RR types, as well as clarifying few things from older RFC's. RFC2929 is BCP 42 so this document will replace it as a BCP. The document process rules in this group, require that at least 5 members of the working to state that they have read the document and consensus support that it be published. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 19 14:28:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GmY-0007uc-5n for dnsext-archive@lists.ietf.org; Wed, 19 Jul 2006 14:28:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GmV-0006XC-T7 for dnsext-archive@lists.ietf.org; Wed, 19 Jul 2006 14:28:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GkO-000M1s-Aq for namedroppers-data@psg.com; Wed, 19 Jul 2006 18:26:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [81.91.160.27] (helo=denic.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3GkN-000M1c-Bw for namedroppers@ops.ietf.org; Wed, 19 Jul 2006 18:26:11 +0000 Received: by unknown.office.denic.de (Postfix, from userid 501) id 3FCC3331CD0; Wed, 19 Jul 2006 20:26:09 +0200 (CEST) Date: Wed, 19 Jul 2006 20:26:09 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: DNSEXT WGLC: RFC2929bis Message-ID: <20060719182609.GL2142@unknown.office.denic.de> References: <6.2.5.6.2.20060719125045.0371ae48@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.2.5.6.2.20060719125045.0371ae48@ogud.com> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Wed, Jul 19, 2006 at 02:02:24PM -0400, Ólafur Guðmundsson /DNSEXT co-chair wrote: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt > The document process rules in this group, require that at least > 5 members of the working to state that they have read the document > and consensus support that it be published. as agreed upon in Montreal I'd like to re-insert my comments expressed in into the WGLC. Modulo those I support this document. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 19 14:36:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Gty-00037E-Rr for dnsext-archive@lists.ietf.org; Wed, 19 Jul 2006 14:36:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Gtx-0007mj-H8 for dnsext-archive@lists.ietf.org; Wed, 19 Jul 2006 14:36:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Gs6-000N5Z-TY for namedroppers-data@psg.com; Wed, 19 Jul 2006 18:34:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Gs5-000N5J-OC for namedroppers@ops.ietf.org; Wed, 19 Jul 2006 18:34:10 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6JIY3V4010091 for ; Wed, 19 Jul 2006 14:34:03 -0400 Received: from gorilla ([129.6.220.75]) by postmark.nist.gov (8.13.7/8.13.7) with SMTP id k6JIXNJ9027797 for ; Wed, 19 Jul 2006 14:33:25 -0400 (EDT) From: "Scott Rose" To: Subject: RE: DNSEXT WGLC: RFC2929bis Date: Wed, 19 Jul 2006 14:33:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6.2.5.6.2.20060719125045.0371ae48@ogud.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 > > > This message starts at 3 week last call for this document ending > on midnight August 10'th 2006 (Reykjavik time). > > The URL for the document is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt > > This document updates RFC2929 which defines how IANA handles registrations > affecting the DNS. This document attempts to liberalize and speed up the > process for getting new DNS RR types, as well as clarifying few things > from older RFC's. > > RFC2929 is BCP 42 so this document will replace it as a BCP. > > The document process rules in this group, require that at least > 5 members of the working to state that they have read the document > and consensus support that it be published. I have read the document and I support it going forward Scott > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 20 06:18:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Vc3-0003op-LJ for dnsext-archive@lists.ietf.org; Thu, 20 Jul 2006 06:18:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3VOU-0006zp-UX for dnsext-archive@lists.ietf.org; Thu, 20 Jul 2006 06:04:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3VJc-0003jA-TD for namedroppers-data@psg.com; Thu, 20 Jul 2006 09:59:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3VJb-0003iw-EF for namedroppers@ops.ietf.org; Thu, 20 Jul 2006 09:59:31 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id BFE9433C1A; Thu, 20 Jul 2006 10:59:26 +0100 (BST) Message-ID: <44BF5401.4000504@algroup.co.uk> Date: Thu, 20 Jul 2006 10:59:29 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= CC: David Blacka , Namedroppers WG Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains References: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> <449D7785.6010105@algroup.co.uk> <6.2.5.6.2.20060707100956.03688318@ogud.com> In-Reply-To: <6.2.5.6.2.20060707100956.03688318@ogud.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Ólafur Guðmundsson wrote: > At 13:33 24/06/2006, Ben Laurie wrote: >> David Blacka wrote: > > > >> > Note that solution #4 could be thought of as a special case of the >> NSEC3 >> > hash calculation function rather than as a special NSEC3 RR. >> > >> > Solutions 2, 3, and 4 all have the property of having something that >> may >> > be directly looked up by the authoritative server (either primary or >> > secondary), which is known to be efficient. >> >> If we're going to change things, then I prefer 2. >> >> 3 & 4 both complicate the logic for handling NSEC3 records, for no >> obvious reason (to save a type code? really?). > > > I agree with Ben that 2 sounds as the cleanest solution, > but I'm partial to liking #4. If you want #4 rather than #2 then I suspect you're going to have to do better than "partial to liking". > > #1 (having zone parameters at a random name) is unacceptable from > both performance and consistency point of view. > > There are two uses for this information: > Authorative server configuring its NSEC3 behavior, this is both to set > the NSEC3 lookup parameters. The case that I keep harping on are > nameservers that do not "load" the zone but look up in a database > for answers. For these servers it the location of NSEC3 parameters must > be known. The alternative is to FIX the parameters for each zone/all zones, > but that is counters the spirit of NSEC3 design. > > Also keep in mind that a paranoid DNSSEC validator may want to check that > the NSEC3 record it received is from the CURRENT NSEC3 chain. And what if it isn't? How's it going to get a more recent one? > If this use is encouraged then zones should lower the TTL on the marker > record before switch to have them flush out of caches faster. > > > Olafur > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From michael@winddanzer.com Thu Jul 20 12:19:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bEu-0006xR-1g for dnsext-archive@ietf.org; Thu, 20 Jul 2006 12:19:04 -0400 Received: from net31-109.grcc.edu ([207.74.31.109] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3bEs-0001z1-Mj for dnsext-archive@ietf.org; Thu, 20 Jul 2006 12:19:04 -0400 Message-ID: <000001c6ac18$6a584480$0100007f@localhost> From: "Kenneth Russell" To: Subject: Need S0ftware? Date: Thu, 20 Jul 2006 12:19:04 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6AC18.6A584480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.1 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6AC18.6A584480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C6AC18.6A584480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C6AC18.6A584480-- From owner-namedroppers@ops.ietf.org Thu Jul 20 14:12:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3d0I-00053t-CD for dnsext-archive@lists.ietf.org; Thu, 20 Jul 2006 14:12:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cvo-0007cD-63 for dnsext-archive@lists.ietf.org; Thu, 20 Jul 2006 14:07:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3crO-0005ng-Do for namedroppers-data@psg.com; Thu, 20 Jul 2006 18:02:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.55.12.40] (helo=ll.mit.edu) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3crL-0005nS-Lz for namedroppers@ops.ietf.org; Thu, 20 Jul 2006 18:02:51 +0000 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id k6KI2d3A029178 for ; Thu, 20 Jul 2006 14:02:39 -0400 (EDT) Received: from UNKNOWN( ), claiming to be "[192.5.135.97]" via SMTP by llmail, id smtpdAAA4gaWFx; Thu Jul 20 13:25:31 2006 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 20 Jul 2006 13:25:31 -0400 Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms From: "Stuart E. Schechter" To: Message-ID: In-Reply-To: <6.2.5.6.2.20060718085554.038136e0@ogud.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 > From: =C3=93lafur Gu=E2=80=BAmundsson > Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms >=20 > So far no one has commented or posted a review of this document. > Please help your chairs by reviewing this document. >=20 > thank you > Olafur >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.tx= t 2.1.1.4. Cons [of Dynamic NSEC Synthesis] The need to keep a signing key on the server is mentioned in 2.1.1.1, bu= t should probably be explicitly mentioned in this Cons section. 2.1.2.1. "Since the Since the versioning is done inside the NSEC RR, different versions may coexist." I'd add the words "within a zone" before the end of that sentence. =20 I'd also wonder if this could lead to ambiguities and different interpretations. "to be defined" -> "to-be-defined" 2.1.2.2. "a single RR type authenticated denial" -> "a single RR type for authenticated denial" =20 "as opposed to e.g. NSEC-alt," When you expand out "e.g." to "example given" this doesn't parse. Som= e folks are OK with this. 2.1.2.3 "while specifying behavior in case of" =3D> "while specifying the recommended client behavior when presented with" 2.1.2.4. I'm not sure what "clean and clear" imply. Straightforward? "clear and clean" (the two words reverse) are used in 2.1.2.5. "without versioning DNSSEC" You are versioning a component of DNSSEC, which could be argued is versioning DNSSEC. Perhaps something along the following lines would be more accurate: "without introducing versioning into other components of DNSSEC" 2.1.3.1. "NXT, NSEC, RRSIG or other outdated RR types" RRSIG is outdated? 2.1.6.* This mechanism is described as equivalent to that of 2.1.5 (see 2.1.6.5.). =20 However, In 2.1.6.1. you say that "NSEC is simply turned off." In contrast, 2.1.5 allows NSECs to exist for denial of existence for records (but not domains).=20 2.1.6.2. "A next to" "A next step"? 2.1.6.5. "Official version of the 'trick' presented in Section 2.1.5." I think you mean to say that it is an formal and explicit indication mechanism that obtains the same ends as the informal mechanism (hack) described in 2.1.5. 2.1.7.1.4. Isn't one of the Cons the performance of online signing each denial of existence record? Potential denial of service attack? Cheers Stuart -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From ccc@21cn.com Mon Jul 24 13:59:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54iN-0001ES-Ia for dnsext-archive@lists.ietf.org; Mon, 24 Jul 2006 13:59:35 -0400 Received: from [222.169.83.198] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G54iL-0001Fw-3Q for dnsext-archive@lists.ietf.org; Mon, 24 Jul 2006 13:59:35 -0400 To: From: =?iso-2022-jp?B?GyRCQ1NDKxsoQg==?= Subject: =?iso-2022-jp?B?QUQ6GyRCPzc8VkNLGyhCQBskQjJGGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 $B2F$N%\!<%J%9$G?7) id 1G5QBy-0007ur-73 for namedroppers-data@psg.com; Tue, 25 Jul 2006 16:55:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5QBw-0007uZ-UG for namedroppers@ops.ietf.org; Tue, 25 Jul 2006 16:55:33 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k6PGtLwt013347; Tue, 25 Jul 2006 09:55:21 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 09:55:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ietf-dkim] The URL to my paper describing the DKIM policy options Date: Tue, 25 Jul 2006 09:55:21 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6999@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-dkim] The URL to my paper describing the DKIM policy options Thread-Index: AcawAj7/B0beLv5uR1qVTXc6iKTyHQABFJqg From: "Hallam-Baker, Phillip" To: "Michael Thomas" , "Patrick Peterson" Cc: "IETF-DKIM" , X-OriginalArrivalTime: 25 Jul 2006 16:55:21.0101 (UTC) FILETIME=[1D664BD0:01C6B00B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b CC'd to namedroppers for wider discussion. There are two wildcard problems 1) Wildcards do not match a node if there is any data at the node *.example.com TXT "hello" will not match if there is any record at = a.example.com 2) It is not possible to define a midpoint wildcard=20 _prefix.*.example.com cannot be defined The proposal is to use automatically generated records to address the = first problem and the PTR hack to address the second. So for example we might add a new 'superwildcard' record to the = configuration language of BIND or your favorite DNS server that = recognises the ** wildcard entry which matches with the na=EFvely = expected semantic of 'match any node that does not already have an entry = defined for this particular record'. So our configuration file is: **.example.com PTR _default.example.com a.example.com A 10.0.0.1 _dkim.example.com TXT "dkim record" This is then processed by a preprocessor to produce the actual DNS zone: **.example.com PTR _default.example.com a.example.com A 10.0.0.1 a.example.com PTR _default.example.com _dkim.example.com TXT "dkim record" Note that DNSSEC already creates the need to separate the configuration = file from the zone file. If we were using DNSSEC we would also be = inserting the various key and signature records etc. The handling of ** can be defined to create 'cut outs' for cases where = you would expect them to occur. So if we have a delegation to another = DNS server we would naturally expect that the superwildcard would not = apply to anything in the delegated zone. Note that we need superwildcards whether or not we introduce a new RR = and that this will require code to support the administrators. The = reason this is acceptable is that 1) it is still possible to do the job = by hand 2) the tool can be bolted in to practically every existing = configuration without disrupting the installed servers. Consider however what happens when we have a large number of policy = records and each one has its own record and there is no PTR hack: **.example.com DKIM "dkim record" **.example.com DKPOP "dkop record" **.example.com DKSSL "dkssl record" **.example.com DSMTP "dsmtp record" a.example.com A 10.0.0.1 b.example.com A 10.0.0.1 ... z.example.com A 10.0.0.1 After processing we will have 4*(26+1) synthetic nodes created and if = they are signed each will have a signature record as well. This is not good if the policy records are all saying the same thing = 'this host does not provide this service'. Using the PTR approach this becomes: **.example.com PTR _default.example.com a.example.com A 10.0.0.1 b.example.com A 10.0.0.1 ... z.example.com A 10.0.0.1 _default.example.com DKIM "dkim record" _default.example.com DKPOP "dkop record" _default.example.com DKSSL "dkssl record" _default.example.com DSMTP "dsmtp record" Now we only create 26+1 new synthetic records. We can also use the PTR records to perform class based system = administration: **.example.com PTR _default.example.com a.example.com A 10.0.0.1 a.example.com PTR _server.example.com b.example.com A 10.0.0.1 b.example.com PTR _server.example.com c.example.com A 10.0.0.1 ... z.example.com A 10.0.0.1 _default.example.com DKIM "dkim record" _default.example.com DKPOP "dkop record" _default.example.com DKSSL "dkssl record" _default.example.com DSMTP "dsmtp record" _server.example.com DKIM "dkim record" _server.example.com DKPOP "dkop record" _server.example.com DKSSL "dkssl record" _server.example.com DSMTP "dsmtp record" In this case we have two separate management groups, machines a and b = are in the server group and we can set the parameters for both machines = at the same time. Everything else is in the default group. Note that there is still value to using the PTR hack even if you are = going to define a specific policy record. If someone can demonstrate (as opposed to give opinions as to the state = of their intestines) that something ugly happens if PTR is used we could = use a different record or even create a new one. For the sake of example I have shown the scheme with policy specific = RRs. The redirection to a prefix value is not essential to the = demonstration except insofar as it is better that this process does not = result in spurious nodes being created. I could have used a PTR to an = unprefixed label: a.example.com DKIM "dkim record" b.example.com PTR a.example.com As is clear from the example however there is now no 'wildcard penalty' = for using a prefix record. Although eliminating the wildcard penalty was = my original reason for developing this scheme it is not the only = benefit. I think that we need this type of functionality regardless of = whether we create new RRs or not as otherwise the number of synthesized = policy nodes will quickly explode. Every Web service will require a = policy specification, the platform requires it. A domain might easily = have 100 or more Web services defined.=20 > -----Original Message----- > From: Michael Thomas [mailto:mike@mtcc.com]=20 > Sent: Tuesday, July 25, 2006 11:52 AM > To: Patrick Peterson > Cc: Hallam-Baker, Phillip; IETF-DKIM > Subject: Re: [ietf-dkim] The URL to my paper describing the=20 > DKIM policy options >=20 > Patrick Peterson wrote: >=20 > >>----- Original Message ----- > >>From: "Hallam-Baker, Phillip" > >>To: "IETF-DKIM" > >>Sent: Wednesday, July 12, 2006 2:05 PM > >>Subject: [ietf-dkim] The URL to my paper describing the DKIM policy=20 > >>options > >> > >> > >>I submitted the draft in both pdf and txt. Only the txt is=20 > shown, the=20 > >>more readable pdf is attached. > >> > >>http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt > >> =20 > >> > > > >I think this is a great idea and am surprised it didn't=20 > generate more=20 > >traffic on the list. It's not easy to cram needed new functionality=20 > >into a backward-compatible solution. > > =20 > > > So I'm trying to understand the basic algorithm: >=20 > To discover the policy for DKIM at alice.example.com:=20 > =20 > 1) policy =3D lookup (TXT, "_dkim.alice.example.com")=20 > IF policy <> NULL THEN RETURN policy=20 > =20 > 2) pointer =3D lookup (PTR, "alice.example.com")=20 > IF pointer =3D=3D NULL THEN RETURN NULL=20 > =20 > 3) policy =3D lookup (TXT, "_dkim." + pointer)=20 > return policy=20 >=20 > So I set up mtcc.com's bind config to: >=20 > $ORIGIN mtcc.com. >=20 > * IN PTR mtcc.com. >=20 > Where mtcc.com is the top level and contains the policy=20 > record. When I choose a label that doesn't have any other=20 > labels (say, frogger.mtcc.com) it doesn't return anything as=20 > TXT so I go to step 2, it points back to mtcc.com and 3 succeeds. >=20 > However, when I use a label *with* a record: > fafner IN A 216.102.208.11 >=20 > the host -t PTR fafner.mtcc.com returns a reply with an=20 > answer count of zero. > Which is just the same thing that happens with TXT. >=20 > So I guess I must be missing something because wildcarded PTR=20 > records seem to be handled the same as any other wildcard=20 > which is to say, not the behavior you'd hope for. >=20 > Phill? >=20 > Mike >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 25 14:28:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ReD-0001RK-HK for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 14:28:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ReC-0005hJ-6M for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 14:28:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5RbM-000Imz-DF for namedroppers-data@psg.com; Tue, 25 Jul 2006 18:25:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5RbL-000Iml-Q5 for namedroppers@ops.ietf.org; Tue, 25 Jul 2006 18:25:52 +0000 Received: from [10.31.32.195] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6PIPfub070828; Tue, 25 Jul 2006 14:25:41 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD6999@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37BD6999@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Tue, 25 Jul 2006 14:25:45 -0400 To: From: Edward Lewis Subject: a suggestion for super-wildcards Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 At 9:55 AM -0700 7/25/06, Hallam-Baker, Phillip wrote: >CC'd to namedroppers for wider discussion. I'm addressing this reply to only namedroppers. >So our configuration file is: > >**.example.com PTR _default.example.com >a.example.com A 10.0.0.1 >_dkim.example.com TXT "dkim record" > >This is then processed by a preprocessor to produce the actual DNS zone: > >**.example.com PTR _default.example.com >a.example.com A 10.0.0.1 >a.example.com PTR _default.example.com >_dkim.example.com TXT "dkim record" E.g., BIND's $GENERATE directive, on steroids. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 25 17:41:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UeF-0006rS-Fb for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 17:41:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5UeB-0008Qx-5h for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 17:41:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5UZs-000KeT-Aa for namedroppers-data@psg.com; Tue, 25 Jul 2006 21:36:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.154.242] (helo=mail12.mdx.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5UZq-000KeD-UV for namedroppers@ops.ietf.org; Tue, 25 Jul 2006 21:36:31 +0000 Received: by mail12.mdx.safepages.com (Postfix, from userid 1012) id 93736B97E; Tue, 25 Jul 2006 21:36:38 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.109]) by mail12.mdx.safepages.com (Postfix) with ESMTP id 57A05B93B for ; Tue, 25 Jul 2006 21:36:35 +0000 (GMT) Message-ID: <44C68F47.4060205@connotech.com> Date: Tue, 25 Jul 2006 17:38:15 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: RFC2929bis References: <6.2.5.6.2.20060719125045.0371ae48@ogud.com> In-Reply-To: <6.2.5.6.2.20060719125045.0371ae48@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Ólafur Guðmundsson /DNSEXT co-chair wrote: > > This message starts at 3 week last call for this document ending > on midnight August 10'th 2006 (Reykjavik time). > > The URL for the document is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt > Minor editorial: On section 3.1, sentence starting with "Thus far ...", missing reference to DLV and TA assignments. My main concern with this document is the limited coverage of namespace management implied by sub-typing. The AFSDB sub-typing is covered in section 3.1.5. The same should apply to CERT sub-typing (see section 2.1 in RFC4398), and perhaps others. In the case of SRV records (RFC2782), the alphanumeric sub-typing manespace is populated by reference to [STD2] "or locally". For new RR type allocations, there is a potential pitfall with the following sub-typing dilemma: if the RR type applicant requests an allocation for his very specific solution in an application area, he/she will face rejection from expert guideline 5 ("The requested RRTYPE would conflict with one under development within the IETF and the existence of more than one such type would harm interoperability.") or even 7 ("An excessive number of RRTYPE values is being requested when the purpose could be met with a smaller number."); if the RR applicant acknowledges the need for multiple co-existing solutions (identified by sub-type) within a given application issue (indicated by the requested RR allocation), he/she faces the onus of defining namespace management for the sub-type, without guidelines. I understand that this is perhaps an extension of the scope of the draft (but then why is section 3.1.5 present in the first place?). Nonetheless, I think the RR sub-typing guidelines would be useful for making the RR type application process more predictable and attractive. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 25 18:26:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VM5-0001yz-KV for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 18:26:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VM3-00005g-NV for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 18:26:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5VJP-0001EG-IW for namedroppers-data@psg.com; Tue, 25 Jul 2006 22:23:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-15.8 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5VJN-0001Dw-1M for namedroppers@ops.ietf.org; Tue, 25 Jul 2006 22:23:33 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k6PMNU92001366; Tue, 25 Jul 2006 15:23:30 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k6PMNUL1001365; Tue, 25 Jul 2006 15:23:30 -0700 Date: Tue, 25 Jul 2006 15:23:30 -0700 Message-Id: <200607252223.k6PMNUL1001365@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4592 on The Role of Wildcards in the Domain Name System From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 A new Request for Comments is now available in online RFC libraries. RFC 4592 Title: The Role of Wildcards in the Domain Name System Author: E. Lewis Status: Standards Track Date: July 2006 Mailbox: ed.lewis@neustar.biz Pages: 20 Characters: 43991 Updates: RFC1034, RFC2672 See-Also: I-D Tag: draft-ietf-dnsext-wcard-clarify-11.txt URL: http://www.rfc-editor.org/rfc/rfc4592.txt This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 25 23:19:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Zw6-0004k1-UZ for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 23:19:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Zw6-00028I-Dq for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 23:19:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Zrk-000CBZ-4o for namedroppers-data@psg.com; Wed, 26 Jul 2006 03:15:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Zri-000CBI-Ta for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 03:15:19 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6Q3FEOV021725 for ; Tue, 25 Jul 2006 20:15:14 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6Q3FDYb020099 for ; Tue, 25 Jul 2006 22:15:13 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DNSEXT WGLC: RFC2929bis Date: Tue, 25 Jul 2006 23:15:11 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790012D6078@de01exm64.ds.mot.com> In-Reply-To: <20060719182609.GL2142@unknown.office.denic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNSEXT WGLC: RFC2929bis Thread-Index: AcarYlh4nd3FLPvhS+6wupVOBDfhagE7tkPw From: "Eastlake III Donald-LDE008" To: "IETF DNSEXT WG" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Peter, Thanks for these detailed and extensive comments. See below at @@@ Donald Eastlake wrote: > The last feedback I got from the working group on this draft was that = it > was in good shape except for the need for some specific guidelines for > the designated RR type allocation expert. So this updated version has > such guidelines in section 3.1.3. Hopefully this version, or perhaps = -04 as one of those asking for such guidance (and apologies for failing to send text), I am pretty much happy with what Donald came up in 3.1.3, = just modulo some nits. 3.1.3 first: (nit) s/designed/Designated/ (nit) use consistent spelling of "RR TYPE" vs. "RRTYPE" @@@ Right. There are also cases of "RR type". I would prefer to replace = them all with RRTYPE. > and to consult with other experts as necessary. The Expert should > reject any RRTYPE allocation request which meets the following > criterion: "which meets at least one of the following criteria" to emphasize these items are ORed. @@@ How about "which meets any of the following criteria" ? > 4. The intended use of the proposed RRTYPE would cause problems with > existing DNS deployments. add "or the DNS infrastructure" to cover cases like tree climbing. @@@ I think that is already included but wouldn't mind adding it. > 5. The requested RRTYPE would conflict with one under development > within the IETF and the existence of more than one such type would > harm interoperability. rephrase /harm interoperability/ to /put interoperability at risk/ to shift the burden of the proof on the requester. @@@ The idea is to make it easier to get an RRTYPE. Given all the other = criteria provided here to reject a request, I don't think this change is = warranted. The template in 3.1.2 I'd like to be amended > Does the proposed RR TYPE require special handling within the > DNS different from an Unknown RR TYPE or ignorable meta-TYPE? so that a "no" would require some explanation or discussion. @@@ The applicant has to provide detailed documentation anyway and I = would imagine that in most cases the Designated Expert would look at it. = This question is here more to remind the applicant of the requirement. I = think it would be very hard to write a more detailed requirement here = that the applicant couldn't answer by just cutting and pasting a wad of = text from their documentation. What's the point? The document doesn't say what an "ignorable" meta type (nit: consistent spelling) is, other than > 2. The RR for which a TYPE code is being requested is either (a) a > data TYPE which can be handled as an Unknown RR as described in > [RFC 3597] or (b) a Meta TYPE who processing is optional, i.e., > which it is safe to simply discard. Would that encourage silence in response to a Meta Query? @@@ Hummm, well, I guess I meant that the Meta TYPE could would be safe = to simply discard if it appeared as Additional Information. It would = probably be best to specify that it be prohibited to use it as an RRTYPE = being queried for. Also, if this is what makes 2929bis update 3597, could that be mentioned explicitly? @@@ RFC 3597 specifically refers to RFC 2929 for ranges of RRTYPES which = can be Meta- or Q-TYPES. This is changed by 2929bis and I would be happy = to mention that in the RRTYPEs section of the draft. Other comments, some of which may apply to text that already appeared in RFC 2929, but since this is an update attempt anyway: o The introduction and 3.2 call the DNS a database, which it isn't. = Slightly change that to data store, data repository or something close. @@@ I think it is a database. It has limitations, but so do many = databases. o The Opcode list in 2.2 (and one could argue that such list doesn't really belong into the policy setting document in the first place) uses mixed case for codes of QUERY, IQUERY and STATUS with a reference to RFC 1035, where that uses all caps. Same for NOTIFY and UPDATE. Could be these names are either non-normative or case insensitive (as everything else in the DNS) but some authoritative words would be = fine. @@@ I'd like to keep the list but converting to all upper case for = consistency is a good idea. o Same applies to the error code list in 2.3, even more so since RFC = 1035 didn't even define a mnemonic for every code. @@@ OK. Many of these are all upper case but I have no problem = converting those in mixed case to upper case. o ``Allocation'' and ``assignment'' are used synonymously throughout the = draft. Suggest to use one term (assignment) only. @@@ I'm not sure how important this is. Looks like "alloc*" occurs about = 25 times and "assign*" about 36 time so "assignment" would be easier to = change to. It could be that some parts would not read as well with that = change. o bottom of page 6: ``TTL is a four octet (32 bit) [bit] unsigned = integer'' @@@ Yes, the extra bit should be deleted... o page 11: QCLASS None, the case issue again @@@ Do you maintain that all the CLASS names, including Hesiod and = Chaos, should be all upper case? o still page 11: strictly speaking 255 is for QCLASS=3D*, not "any" (in = any case :-) @@@ How about if it were to say "* (ANY)" ? o 3.3 RR NAME Considerations this touches both label type and label content issues, so I'd suggest = to rename the section to "Label Considerations" and make the split = between label types (currently the 2nd paragraph) and label content. @@@ OK, renaming the section is certainly reasonable and I could look at = restructuring it. o still 3.3 > A somewhat out-of-date description of name allocation in the IN = Class > is given in [RFC 1591]. Some information on reserved top level > domain names is in BCP 32 [RFC 2606]. This is kinda level 9ish, but I don't think the WG or the IETF should make a statement, however fuzzy, on how outdated RFC 1591 is (2929 = said "dated"). The main point here is that there is no IETF label registry, be that TLD labels or those further down the tree (although there are proposals to change the latter). @@@ The statements are intended to be of some informational use. I think = they are correct and don't see any problem leaving them. o There are normative references to experimental RFCs (1183, 2673) that are probably really informative references. @@@ Well, I've generally listed things which define RRTYPEs, opcodes, = etc., that are listed in 2929bis, as Normative. I don't really care much = but if these two are moved to Informative, seems like a lot of other = normative references should be moved there.=20 -Peter @@@ Thanks, @@@ Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org = [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Peter Koch Sent: Wednesday, July 19, 2006 2:26 PM To: IETF DNSEXT WG Subject: Re: DNSEXT WGLC: RFC2929bis On Wed, Jul 19, 2006 at 02:02:24PM -0400, =D3lafur Gu=F0mundsson /DNSEXT = co-chair wrote: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt > The document process rules in this group, require that at least > 5 members of the working to state that they have read the document and = > consensus support that it be published. as agreed upon in Montreal I'd like to re-insert my comments expressed = in = into the WGLC. Modulo those I support this document. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 25 23:35:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5aB8-0003Jx-BB for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 23:35:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5aB6-0005hH-TM for dnsext-archive@lists.ietf.org; Tue, 25 Jul 2006 23:35:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5a90-000E2U-Jq for namedroppers-data@psg.com; Wed, 26 Jul 2006 03:33:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5a8z-000E21-F9 for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 03:33:09 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6Q3X8Gx027103 for ; Tue, 25 Jul 2006 20:33:08 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k6Q3X8SG012136 for ; Tue, 25 Jul 2006 22:33:08 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DNSEXT WGLC: RFC2929bis Date: Tue, 25 Jul 2006 23:33:07 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790012D607F@de01exm64.ds.mot.com> In-Reply-To: <44C68F47.4060205@connotech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNSEXT WGLC: RFC2929bis Thread-Index: AcawNJjGkb977gsgTRCI4Gx1okiOFwAJeAiw From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Hi, I find some of your comments just a bit cryptic but I'll try responding = to them. See below at @@@ -----Original Message----- From: owner-namedroppers@ops.ietf.org = [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Thierry Moreau Sent: Tuesday, July 25, 2006 5:38 PM To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: RFC2929bis =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >=20 > This message starts at 3 week last call for this document ending on=20 > midnight August 10'th 2006 (Reykjavik time). >=20 > The URL for the document is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt >=20 Minor editorial: On section 3.1, sentence starting with "Thus far ...", = missing reference to DLV and TA assignments. @@@ OK, I can add those.=20 My main concern with this document is the limited coverage of namespace = management implied by sub-typing. The AFSDB sub-typing is covered in = section 3.1.5. The same should apply to CERT sub-typing (see section 2.1 = in RFC4398), and perhaps others. In the case of SRV records (RFC2782), = the alphanumeric sub-typing manespace is populated by reference to = [STD2] "or locally". @@@ "sub-typing" isn't covered at all as a topic in this draft. AFSDB = sub-typing is covered because, and only because, IANA Considerations are = not given for it anywhere else. CERT RR IANA Considerations are given in = RFC 4398 and, as both RFC 2929 and draft 2929bis say, you should = generally go to the RFC for the RR you are interested to find IANA = Considerations within that RRTYPE. For new RR type allocations, there is a potential pitfall with the = following sub-typing dilemma: if the RR type applicant requests an allocation for his very specific = solution in an application area, he/she will face rejection from expert = guideline 5 ("The requested RRTYPE would conflict with one under = development within the IETF and the existence of more than one such type = would harm interoperability.") or even 7 ("An excessive number of RRTYPE = values is being requested when the purpose could be met with a smaller = number."); @@@ Just because an RRTYPE is in some application area, I don't see that = it would necessarily conflict with one under development in the IETF and = it is even less obvious that it would necessarily harm interoperability. = As for rejection reason 7, that only is intended to apply if the = particular applicant is applying for multiple RRTYPEs. I could clarify = the wording of reason 7. if the RR applicant acknowledges the need for multiple co-existing = solutions (identified by sub-type) within a given application issue = (indicated by the requested RR allocation), he/she faces the onus of = defining namespace management for the sub-type, without guidelines. @@@ ? If an existing RRTYPE provides for sub-typing, the RFC defining = that RR should give the IANA Considerations for getting a sub-type = allocated. The exception generally being any RR defined before IANA = Considerations were required. I understand that this is perhaps an extension of the scope of the draft = (but then why is section 3.1.5 present in the first place?).=20 @@@ As explained about, 3.1.5 is there only because AFSDB IANA = Considerations are not given anywhere else. Nonetheless, I think the RR sub-typing guidelines would be useful for = making the RR type application process more predictable and attractive. @@@ This document (2929bis) is not a document on sub-typing. Regards, @@@ Thanks, @@@ Donald --=20 - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 03:49:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5e8m-0002Aj-7r for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 03:49:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5e8k-0007zv-Qo for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 03:49:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5e48-000Cav-FJ for namedroppers-data@psg.com; Wed, 26 Jul 2006 07:44:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5e47-000Cai-IT for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 07:44:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 28A8926C19D; Wed, 26 Jul 2006 09:44:22 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 61FEA26C159; Wed, 26 Jul 2006 09:44:21 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 5E84F58ED15; Wed, 26 Jul 2006 09:44:21 +0200 (CEST) Date: Wed, 26 Jul 2006 09:44:21 +0200 From: Stephane Bortzmeyer To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards Message-ID: <20060726074421.GA2401@nic.fr> References: <198A730C2044DE4A96749D13E167AD37BD6999@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Tue, Jul 25, 2006 at 02:25:45PM -0400, Edward Lewis wrote a message of 33 lines which said: > >This is then processed by a preprocessor to produce the actual DNS zone: > > > >**.example.com PTR _default.example.com > >a.example.com A 10.0.0.1 > >a.example.com PTR _default.example.com > >_dkim.example.com TXT "dkim record" > > E.g., BIND's $GENERATE directive, on steroids. I'm always puzzled by proposal to add in the DNS things that could otherwise be implemented by any preprocessor. The only advantage is to make the transferred zone smaller (but it forces all the secondaries to upgrade to a version supporting the new syntax). Unless I missed another advantage, I suggest to dismiss all these proposals with a "Learn cpp or m4 or Perl or anything". (And I'm not sure it was a good idea to specify the file format, anyway. IETF should be about protocols, not about file formats.) For the same reason, I think that DNAMEs are a bad idea. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 04:56:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5fBj-0007nu-Hs for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 04:56:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5fBi-0001WQ-4r for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 04:56:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5f9A-000KQU-Cf for namedroppers-data@psg.com; Wed, 26 Jul 2006 08:53:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [195.121.247.5] (helo=smtp14.wxs.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5f99-000KPp-A8 for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 08:53:39 +0000 Received: from [192.168.2.100] (ip51cd76fd.speed.planet.nl [81.205.118.253]) by smtp14.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J30001AL61EW5@smtp14.wxs.nl> for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 10:53:38 +0200 (CEST) Date: Wed, 26 Jul 2006 10:53:31 +0200 From: "dr. W.C.A. Wijngaards" Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms In-reply-to: <6.2.5.6.2.20060718085554.038136e0@ogud.com> To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Message-id: <44C72D8B.5050406@nlnetlabs.nl> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------enigB65E0FCB07E784AB30F5F37D; protocol="application/pgp-signature"; micalg=pgp-sha1 User-Agent: Thunderbird 1.5.0.4 (X11/20060614) X-Enigmail-Version: 0.94.0.0 References: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> <6.2.5.6.2.20060718085554.038136e0@ogud.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB65E0FCB07E784AB30F5F37D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =D3lafur Gu=F0mundsson wrote: >> This message starts at 3 week last call for this document ending >> on midnight July 30'th 2006 (Reykjavik time). >> The URL for the document is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.= txt >> Hi, I've read the draft. I think it is technically sound. As such I have no objections to it. 1. Introduction I do object to the reference to the 2004 discussion. I think that the document should stand on its own, and instead in the introduction have the paragraph under 'This summary includes:'. So, remove the references to the process of last-call in 2004, and state the need for transition mechanisms. Delete paragraphs 'This is an edited excerpt..', 'To ease'. Replace with a rewrite of the 'this summary includes:' paragraph, i.e. this document provides a list of pros and cons for mechanisms to transition to future work on authenticated denial of existence. The authors aim to provide a mechanism that is least disruptive to the DNSSEC-bis specifications as they stand and keep an open path to other methods for authenticated denial of existence. With regard to the last paragraph in the introduction: @ The descriptions of the proposals in this document are coarse and do @ not cover every detail necessary for implementation. In any case, @ documentation and further study is needed before implementaion and/or @ deployment, including those which seem to be solely operational in @ nature. The coarseness is a bit of a cop out, the document considers the alternatives and compares them. It does not list every detail necessary for implementation of the alternatives. 'implementaion' is a typo. The 'solely operational in nature' is confusing. What is solely operational in nature? Seems like a grammar/editing artifact to me. And why do they only seem to be operational in nature? Are you trying to say: 'Transition has operational consequences and further study on these operational consequences is needed once an alternative is selected' ? 3. Recommendation I agree with Scott, the recommendation for online signing could benefit from some limitation, i.e. This recommendation is temporary until a denial solution becomes available that does not suffer from such strong security problems such as online key maintenance and denial of service to servers that online signing suffers from. Best regards, Wouter --------------enigB65E0FCB07E784AB30F5F37D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFExy2RkDLqNwOhpPgRAg3aAJsGj0Z8/eVvhcUMm+a1+r8y+AqXPQCfQA3d BBq5iIWmTCbOEvYSqJf3rDg= =CDcn -----END PGP SIGNATURE----- --------------enigB65E0FCB07E784AB30F5F37D-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 05:38:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5fqp-0000xZ-V8 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 05:38:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5fqo-000158-EL for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 05:38:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5fp4-00002z-Ex for namedroppers-data@psg.com; Wed, 26 Jul 2006 09:36:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5fp3-00002Y-CK for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 09:36:57 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 26 Jul 2006 10:36:55 +0100 X-IronPort-AV: i="4.07,182,1151881200"; d="scan'208"; a="4118984:sNHT33607360" In-Reply-To: <20060726074421.GA2401@nic.fr> To: namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 26 Jul 2006 11:36:32 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/26/2006 10:36:33 AM, Serialize complete at 07/26/2006 10:36:33 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Stephane Bortzmeyer wrote on 07/26/2006 09:44:21 AM: > On Tue, Jul 25, 2006 at 02:25:45PM -0400, > Edward Lewis wrote > a message of 33 lines which said: > > > >This is then processed by a preprocessor to produce the actual DNS zone: > > > > > >**.example.com PTR _default.example.com > > >a.example.com A 10.0.0.1 > > >a.example.com PTR _default.example.com > > >_dkim.example.com TXT "dkim record" > > > > E.g., BIND's $GENERATE directive, on steroids. > > I'm always puzzled by proposal to add in the DNS things that could > otherwise be implemented by any preprocessor. The only advantage is to > make the transferred zone smaller (but it forces all the secondaries > to upgrade to a version supporting the new syntax). > > Unless I missed another advantage, I suggest to dismiss all these > proposals with a "Learn cpp or m4 or Perl or anything". (And I'm not > sure it was a good idea to specify the file format, anyway. IETF > should be about protocols, not about file formats.) > > For the same reason, I think that DNAMEs are a bad idea. There is a difference in what can and can not be preprocessed. Phill's (Ed's) proposal can be implemented by preprocessing and out of protocol, i.e. adding a record type for existing names. DNAME's can not be preprocessed, since qname does not match at the DNAME ownername, but below. The same goes for anything that does not match an existing name. Okay, it can be preprocessed, but that is going to be a helluva big zone ;-) Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 07:06:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hDO-00086R-EA for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 07:06:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5hDN-00059n-09 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 07:06:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5hAT-0008qs-V7 for namedroppers-data@psg.com; Wed, 26 Jul 2006 11:03:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, NO_REAL_NAME autolearn=no version=3.1.1 Received: from [63.160.45.2] (helo=usmail.atrica.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5hAQ-0008qS-UN for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 11:03:07 +0000 Received: from mail pickup service by usmail.atrica.com with Microsoft SMTPSVC; Wed, 26 Jul 2006 04:03:06 -0700 Received: from resolution.atrica.com ([63.160.45.67]) by usmail.atrica.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 15:25:47 -0700 Received: from usmailrelay0.atrica.com (unknown [63.160.45.96]) by resolution.atrica.com (Postfix) with ESMTP id 3FD862C1AE for ; Tue, 25 Jul 2006 15:00:06 -0700 (PDT) Received: from megatron.ietf.org (optimus.ietf.org [156.154.16.145]) by usmailrelay0.atrica.com (Symantec Mail Security) with ESMTP id A76D0FEC for ; Tue, 25 Jul 2006 15:25:44 -0700 (PDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VJN-0007mM-Mp; Tue, 25 Jul 2006 18:23:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VJM-0007mH-5C for ietf-announce@ietf.org; Tue, 25 Jul 2006 18:23:32 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VJK-0007or-Pf for ietf-announce@ietf.org; Tue, 25 Jul 2006 18:23:32 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k6PMNU92001366; Tue, 25 Jul 2006 15:23:30 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k6PMNUL1001365; Tue, 25 Jul 2006 15:23:30 -0700 Date: Tue, 25 Jul 2006 15:23:30 -0700 Message-Id: <200607252223.k6PMNUL1001365@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: namedroppers@ops.ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4592 on The Role of Wildcards in the Domain Name System X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 25 Jul 2006 22:25:47.0290 (UTC) FILETIME=[46BAA7A0:01C6B039] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 A new Request for Comments is now available in online RFC libraries. RFC 4592 Title: The Role of Wildcards in the Domain Name System Author: E. Lewis Status: Standards Track Date: July 2006 Mailbox: ed.lewis@neustar.biz Pages: 20 Characters: 43991 Updates: RFC1034, RFC2672 See-Also: I-D Tag: draft-ietf-dnsext-wcard-clarify-11.txt URL: http://www.rfc-editor.org/rfc/rfc4592.txt This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 07:13:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hKE-0002pK-00 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 07:13:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5hKB-0005yt-MC for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 07:13:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5hIp-0009ym-2q for namedroppers-data@psg.com; Wed, 26 Jul 2006 11:11:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5hIo-0009y4-3N for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 11:11:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 26E8726C159; Wed, 26 Jul 2006 13:11:45 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 1FFC026C0D2; Wed, 26 Jul 2006 13:11:44 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 1260FA1DB16; Wed, 26 Jul 2006 13:11:44 +0200 (CEST) Date: Wed, 26 Jul 2006 13:11:44 +0200 From: Stephane Bortzmeyer To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards Message-ID: <20060726111144.GA10707@nic.fr> References: <20060726074421.GA2401@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Wed, Jul 26, 2006 at 11:36:32AM +0200, Roy Arends wrote a message of 45 lines which said: > There is a difference in what can and can not be preprocessed. Yes. Ordinary wildcards cannot be preprocessed. > DNAME's can not be preprocessed, since qname does not match at the > DNAME ownername, but below. I did not say that DNAME could be preprocessed but that DNAME was a bad idea because the same effect (solving the use cases in section 2 "Motivation" of RFC 2672, typically network renumbering and company name changing) could be attained by preprocessing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 09:25:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jOA-0002EB-VT for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 09:25:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jO5-0008IX-Mp for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 09:25:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5jKO-000OIE-0P for namedroppers-data@psg.com; Wed, 26 Jul 2006 13:21:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.223] (helo=mail3.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5jKM-000OHy-O7 for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 13:21:30 +0000 Received: by mail3.sea.safepages.com (Postfix, from userid 1012) id 78038B7E71; Wed, 26 Jul 2006 13:21:29 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.174]) by mail3.sea.safepages.com (Postfix) with ESMTP id B600EB7EB9; Wed, 26 Jul 2006 13:21:18 +0000 (GMT) Message-ID: <44C76CEF.20401@connotech.com> Date: Wed, 26 Jul 2006 09:23:59 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: RFC2929bis References: <3870C46029D1F945B1472F170D2D9790012D607F@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790012D607F@de01exm64.ds.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Eastlake III Donald-LDE008 wrote (in @@@ paragraphs): > [...] > > I understand that this is perhaps an extension of the scope of the draft (but then why is section 3.1.5 present in the first place?). > > @@@ As explained about, 3.1.5 is there only because AFSDB IANA Considerations are not given anywhere else. > > Nonetheless, I think the RR sub-typing guidelines would be useful for making the RR type application process more predictable and attractive. > > @@@ This document (2929bis) is not a document on sub-typing. I accept your explanations, and as I reveiewed the draft and it is in good shape (despite my personal opinion that the RR applicant needs would be better server with an expanded scope), I am in favor of progressing the draft. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 09:45:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jhz-0004aN-N3 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 09:45:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jhx-0007Il-8O for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 09:45:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5jg6-0000ZS-TS for namedroppers-data@psg.com; Wed, 26 Jul 2006 13:43:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5jg5-0000ZG-TX for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 13:43:58 +0000 Received: from [10.31.32.195] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6QDhjb2006013; Wed, 26 Jul 2006 09:43:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060726111144.GA10707@nic.fr> References: <20060726074421.GA2401@nic.fr> <20060726111144.GA10707@nic.fr> Date: Wed, 26 Jul 2006 09:43:37 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: pushing the limits of DNS Re: a suggestion for super-wildcards Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Pouring cold water on a spark you don't want is quite refreshing but may be giving the wrong impression. On the one hand, it would be really cool if there was a way to expand the notion of record and answer synthesis in DNS. Performing a mental exercise on this, eventually you realize that we could just throw in a full-fledged database, etc., etc. Or perhaps LDAP and X.500. The reason that isn't what is being done, why sparks of ideas to add things like super wildcards is that DNS offers certain advantages - speedy responses, a loosely coordinated management structure that permits wild scaling, and good-enough replication. The cost of maintaining DNS in its original spirit, which is the key to retaining its advantages, is that functionality is pushed outward (from the "core" DNS), to things like pre-processors. It's quite easy to off-load all DNS advancement to such gadgets - from the perspective of protocol engineers. The net of doing this is an increase in gadgets. There's a choice - in order to perform a job requiring a fixed amount of work, you can have lots of simple gadgets or a few complex gadgets. We in the this group are gadget makers and prefer small, simple ones. This means we are putting pressure on operators and applications writers to make do with lots of simple tools. Perhaps that's all well and good - creating a need for a layer above DNS to once again make the gadgets seem as one, easier to track and manage. But, on the other hand, it can be seen as just another layer of complexity to be offered by someone else. The talk below is about DNAME. But I would also lump in MX and CNAME as two earlier records which set bad precedents. They were customizations of the DNS to appease needs at the dawn of time. Today we don't think of MX and CNAME as problems, but that's because they are like the goofy old uncle that's been around the house too long. CNAME is a pain because of what it does to the algorithm in 4.3.2 or 1034. MX because it causes confusion of how wildcards operate. (While I'm at being crotchety - if we hadn't invented the NS record, we wouldn't have ICANN to kick around. And the A record - oh, the trouble it has caused!) Do I have a point? Probably not, maybe it was the 45 minute drive on Route 28 that's prompting me to write. (When are they going to finish that bridge!) But I guess what I wanted to say is that although my response said to "use preprocessing" that doesn't mean to say that expanding answer synthesis is a bad idea. By "pushing the limits" in the subject I an inferring that I have doubts that it can be easily done - the big problem is the zone transfer process. I think we should not consider record synthesis a problem rooted in complexity nor something that is easily done by more gadgets on the side of the DNS operation table. My doubts are that we are able to fit it into the protocol as it stands. I'd like to see it, but we'd have to overhaul the zone transfer - for new followers, the AXFR clarify draft has been on the shelf since about summer 2002. If we can't clarify it, we can't extend it. (Oh, and I'm omitting that code to perform the synthesis is needed - but I figure that's the easy part - as I'm not a coder.) Okay, maybe there was no point, but I'm no longer fuming about traffic. At 1:11 PM +0200 7/26/06, Stephane Bortzmeyer wrote: >On Wed, Jul 26, 2006 at 11:36:32AM +0200, > Roy Arends wrote > a message of 45 lines which said: > >> There is a difference in what can and can not be preprocessed. > >Yes. Ordinary wildcards cannot be preprocessed. > >> DNAME's can not be preprocessed, since qname does not match at the >> DNAME ownername, but below. > >I did not say that DNAME could be preprocessed but that DNAME was a >bad idea because the same effect (solving the use cases in section 2 >"Motivation" of RFC 2672, typically network renumbering and company >name changing) could be attained by preprocessing. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 10:55:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5knO-0008Gl-26 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 10:55:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5knM-0008HT-PJ for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 10:55:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5kkd-0008m8-EX for namedroppers-data@psg.com; Wed, 26 Jul 2006 14:52:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5kkc-0008ku-Qn for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 14:52:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5D20511425 for ; Wed, 26 Jul 2006 14:52:40 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards In-Reply-To: Your message of "Wed, 26 Jul 2006 09:44:21 +0200." <20060726074421.GA2401@nic.fr> References: <198A730C2044DE4A96749D13E167AD37BD6999@MOU1WNEXMB04.vcorp.ad.vrsn.com> <20060726074421.GA2401@nic.fr> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 26 Jul 2006 14:52:40 +0000 Message-ID: <48160.1153925560@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > E.g., BIND's $GENERATE directive, on steroids. > > I'm always puzzled by proposal to add in the DNS things that could > otherwise be implemented by any preprocessor. ... me too. but i do want two new kinds of wildcards, which cannot be done by preprocessors. see below. but first: > For the same reason, I think that DNAMEs are a bad idea. DNAME cannot be accomplished by a preprocessor. but two kinds of wildcards which would help SRV a lot and be generally useful, are nonterminal and per-qtype. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 11:13:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5l4b-0000OY-HZ for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 11:13:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5l4Z-0002J2-3A for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 11:13:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5l2t-000B22-7Z for namedroppers-data@psg.com; Wed, 26 Jul 2006 15:11:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, FORGED_RCVD_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5l2s-000B1f-EM for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 15:11:34 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k6QFBTh8002488; Wed, 26 Jul 2006 08:11:29 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 08:11:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Wed, 26 Jul 2006 08:11:26 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6A89@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: Acawl3Ao+WfNmHogRh+TR3QAbHzv7QAK2Tkg From: "Hallam-Baker, Phillip" To: "Roy Arends" , X-OriginalArrivalTime: 26 Jul 2006 15:11:29.0908 (UTC) FILETIME=[C5BB7340:01C6B0C5] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Roy Arends > Stephane Bortzmeyer wrote on 07/26/2006 09:44:21 AM: >=20 > > On Tue, Jul 25, 2006 at 02:25:45PM -0400, Edward Lewis=20 > > wrote a message of 33 lines which said: > >=20 > > > >This is then processed by a preprocessor to produce the=20 > actual DNS > zone: > > > > > > > >**.example.com PTR _default.example.com > > > >a.example.com A 10.0.0.1 > > > >a.example.com PTR _default.example.com > > > >_dkim.example.com TXT "dkim record" > > >=20 > > > E.g., BIND's $GENERATE directive, on steroids. > >=20 > > I'm always puzzled by proposal to add in the DNS things that could=20 > > otherwise be implemented by any preprocessor. The only=20 > advantage is to=20 > > make the transferred zone smaller (but it forces all the=20 > secondaries=20 > > to upgrade to a version supporting the new syntax). > >=20 > > Unless I missed another advantage, I suggest to dismiss all these=20 > > proposals with a "Learn cpp or m4 or Perl or anything".=20 > (And I'm not=20 > > sure it was a good idea to specify the file format, anyway. IETF=20 > > should be about protocols, not about file formats.) Which is of course exactly how I would expect legacy resolvers to handle = the scheme. This part of the scheme is the same as If it was not for zone transfers and for DNSSEC there would be no reason = to have wildcards mentioned in the protocol spec at all. That is why the = ambiguity could enter the system and create the need for clarification = decades later. In the context of DKIM there is a need to demonstrate that the wildcard = problem can be solved by a script. Note that this wildcard problem, the = fact that wildcards don't have the exact semantics you would want is an = issue regardless of how the records are encoded (TXT, new record, = prefixed, not). The alternatives on offer here are=20 1) The existing heuristic search=20 2) The macro-wildcard mechanism proposed here plus a new RR 3) The macro-wildcard mechanism plus the pointer scheme = 'super-wildcards'=20 with either a new RR or a prefix label I think that most of us here would agree that (1) is not a satisfactory = solution. > Okay, it can be preprocessed, but that is going to be a=20 > helluva big zone The expansion factor for super-wildcards is similar to the expansion = factor for DNSSEC, i.e the number of new records is proportional to the = number of nodes plus the number of protocol policy declarations. The expansion factor for macro-wildcards plus a new RR is the = proportional to the number of nodes MULTIPLIED BY the number of protocol = policy declarations. If we believe that DKIM is the only protocol policy record we will need = then both schemes result in the same expansion of the zone. My belief is that we are about to see a dramatic expansion in the number = of Internet protocols as a result of Web services. The key here is that = the variation in services for human consumption is rather small because = people need consistency in their user interfaces. I don't expect there = to be many new human interface protocols, the exceptions to this rule = are mostly games. Machine/Machine interfaces are not constrained in that = way, I expect we will have hundreds of Web Services in regular use and = SOAP is sufficiently complex that a policy layer is essential for = configuration. We could develop something like UDDI or XRI. I don't like the idea of = yet another registry. We could use LDAP but today LDAP stops at the = firewall and that is going to be the case tommorow as well and I don't = expect that to change. LDAP is too powerful and too complex for border = directories to be something people get comfortable with. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 11:14:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5l5c-0001Yy-0q for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 11:14:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5l5Z-0002L3-I8 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 11:14:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5l47-000BFv-Nl for namedroppers-data@psg.com; Wed, 26 Jul 2006 15:12:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5l47-000BFV-53 for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 15:12:51 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k6QFCoL2009730; Wed, 26 Jul 2006 08:12:50 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 08:12:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Wed, 26 Jul 2006 08:12:47 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6A8A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: Acaww71KUQGqNc5PT5asuvs6wr5IoQAAgoTQ From: "Hallam-Baker, Phillip" To: "Paul Vixie" , X-OriginalArrivalTime: 26 Jul 2006 15:12:50.0909 (UTC) FILETIME=[F60338D0:01C6B0C5] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Paul Vixie > > > E.g., BIND's $GENERATE directive, on steroids. > >=20 > > I'm always puzzled by proposal to add in the DNS things that could=20 > > otherwise be implemented by any preprocessor. ... >=20 > me too. but i do want two new kinds of wildcards, which=20 > cannot be done by preprocessors. see below. but first: >=20 > > For the same reason, I think that DNAMEs are a bad idea. >=20 > DNAME cannot be accomplished by a preprocessor. >=20 > but two kinds of wildcards which would help SRV a lot and be=20 > generally useful, are nonterminal and per-qtype. Could you elaborate? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 11:26:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lH0-0000ht-Dv for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 11:26:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lGz-0003h2-4w for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 11:26:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5lEw-000CeZ-PT for namedroppers-data@psg.com; Wed, 26 Jul 2006 15:24:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5lEv-000Ce6-RS for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 15:24:02 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 26 Jul 2006 16:24:00 +0100 X-IronPort-AV: i="4.07,185,1151881200"; d="scan'208"; a="4121956:sNHT27080712" In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD6A89@MOU1WNEXMB04.vcorp.ad.vrsn.com> To: namedroppers@ops.ietf.org Subject: RE: a suggestion for super-wildcards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 26 Jul 2006 17:23:36 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 07/26/2006 04:23:37 PM, Serialize complete at 07/26/2006 04:23:37 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 "Hallam-Baker, Phillip" wrote on 07/26/2006 05:11:26 PM: > > Okay, it can be preprocessed, but that is going to be a > > helluva big zone > > The expansion factor for super-wildcards is similar to the expansion > factor for DNSSEC, i.e the number of new records is proportional to > the number of nodes plus the number of protocol policy declarations. Note that I was referring to preprocessing non-existant names. Wilder-cards (to coin yet another term) is about a directive which instructs a process to generate certain types at _existing_ names (including non-terminals). Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 13:51:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nXX-00011S-JE for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 13:51:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5nXW-0007Ve-5r for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 13:51:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5nT7-0003Pu-2Y for namedroppers-data@psg.com; Wed, 26 Jul 2006 17:46:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5nT6-0003Pd-88 for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 17:46:48 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6QHkhYp016745 for ; Wed, 26 Jul 2006 13:46:43 -0400 Received: from gorilla ([129.6.220.5]) by postmark.nist.gov (8.13.7/8.13.7) with SMTP id k6QHjs97012774 for ; Wed, 26 Jul 2006 13:45:54 -0400 (EDT) From: "Scott Rose" To: "DNSEXT WG" Subject: 3 comments on timers-03 Date: Wed, 26 Jul 2006 13:46:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I have been reading the draft-timers-03, and I know there are other comments, but I think these are unrelated. 2 are minor, one is a response to a discussion point in the draft. First the minor ones 1. "resolver" is used several times when the actual component performing the action would be the validator. 2. Section 5.1 - the 5th step is "wait a while". This step seems unnecessary. Or, if a time limit is really needed before any other operation, the time could be the TTL of the DNSKEY RRset or the min TTL of the SOA RR. But I think it's unnecessary. For the discussion point in section 4.2 (states). In the "missing" state, if a DNSKEY is removed from a RRset, it should be dropped as a trust anchor. I don't know if there should be a wait of the "hold down" time or not. If the RRset validates and there is a trust anchor, then it is a mistake in the rollover process and the missing trust anchor could be dropped. If there is no trust anchor anymore (i.e. the only trust anchor is now missing) - then there needs to be a timeout before dropping, just in case of a man-in-the-middle dropping the DNSKEY RRset from messages. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 14:24:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5o3d-0001jw-FX for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 14:24:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5o3a-0001Cc-RP for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 14:24:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5o1d-0007Pr-6G for namedroppers-data@psg.com; Wed, 26 Jul 2006 18:22:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5o1c-0007PQ-6z for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 18:22:28 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 2BBD856860; Wed, 26 Jul 2006 11:22:26 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060726135818.03de5b18@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 26 Jul 2006 14:22:25 -0400 To: "Scott Rose" ,"DNSEXT WG" From: Mike StJohns Subject: Re: 3 comments on timers-03 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 At 01:46 PM 7/26/2006, Scott Rose wrote: >I have been reading the draft-timers-03, and I know there are other >comments, but I think these are unrelated. 2 are minor, one is a response >to a discussion point in the draft. > >First the minor ones >1. "resolver" is used several times when the actual component performing >the action would be the validator. The resolver conceptually includes the resolution part, the validator part and the trust anchor database part. The management of the database is actually either part of the resolver, or an external application rather than part of the validator. I did a quick scan and I think my language is mostly consistent with that. I'll do a bit deeper review on the next pass, but it would help if you'd point to the specific instances - thanks! >2. Section 5.1 - the 5th step is "wait a while". This step seems >unnecessary. Or, if a time limit is really needed before any other >operation, the time could be the TTL of the DNSKEY RRset or the min TTL of >the SOA RR. But I think it's unnecessary. That was meant to refer to the hold down time for the add anchor operation. Basically, once you've posted the data (as the data originator), the trust anchor doesn't become valid - at each resolver - until some period of time has expired and certain actions are taken by the resolvers. That's described in the resolver state table as the AddPend stage. Section 5 is meant to describe what things look like from the data originators point of view - some resolvers are going to get the new trust anchor fairly quickly, others might have just missed their last timed update and may take a while to get the new anchor, so "Wait a while" seemed to be sufficient. Next rev I'll add "... - the new trust anchor will be populated at the resolvers on the schedule described by the state table and update algorithm - see section 2.3 above" >For the discussion point in section 4.2 (states). In the "missing" state, >if a DNSKEY is removed from a RRset, it should be dropped as a trust anchor. >I don't know if there should be a wait of the "hold down" time or not. If >the RRset validates and there is a trust anchor, then it is a mistake in the >rollover process and the missing trust anchor could be dropped. You definitely don't want to delete a trust anchor from a set just because it's missing once. The example for why that would be a *bad thing* is an operator publishing a trust point DNSKEY RRSet sans that trust anchor by mistake, and then realizing the mistake after a few hours. Any resolver that retrieved that RRSet would delete the trust anchor and when the problem was fixed in a few hours, would be out of step with what the rest of the resolvers thought were the trust anchors for that trust point. OTOH, eventually that accidentally deleted key would rejoin the set of trust anchors after the add hold down period. >If there is no trust anchor anymore (i.e. the only trust anchor is now >missing) - then there needs to be a timeout before dropping, just in case of >a man-in-the-middle dropping the DNSKEY RRset from messages. If I were going to drop this, I'd probably set a hold down time for dropping it to be something like twice the hold down time for adding it. I'd probably also refuse to drop it unless I got a validated RRSet from the trust point which didn't include the trust anchor - and without a second trust anchor, that would be impossible so I'd never drop a single trust anchor. Hmm... It makes the state table more complex, but it's do-able. So the trade offs are a more complex state table vs just hanging on to a non-revoked but missing trust anchor. Comments? >Scott > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 14:44:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oMg-0003hb-G5 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 14:44:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5oMe-00030V-6n for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 14:44:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5oKq-000A3k-H6 for namedroppers-data@psg.com; Wed, 26 Jul 2006 18:42:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5oKn-000A3J-V2 for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 18:42:18 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6QIgAm5010413; Wed, 26 Jul 2006 14:42:10 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <7.0.1.0.2.20060726143556.03dd6a30@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 26 Jul 2006 14:42:10 -0400 To: "Scott Rose" , "DNSEXT WG" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: 3 comments on timers-03 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 13:46 26/07/2006, Scott Rose wrote: >I have been reading the draft-timers-03, and I know there are other >comments, but I think these are unrelated. 2 are minor, one is a response >to a discussion point in the draft. > >First the minor ones >1. "resolver" is used several times when the actual component performing >the action would be the validator. Actually I think we need a new term in this discussion, in my mind the old terms perform resolver = DNS entity that performs lookup validator = entity that validates DNS responses the new term describes the new function caused by key management: TA-maintainer = entity that keeps track of current TA's for the all the trust anchor points it is configured with. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 14:52:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oV5-0000CH-TC for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 14:52:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5oV3-0003Xj-JJ for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 14:52:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5oSx-000BSY-LK for namedroppers-data@psg.com; Wed, 26 Jul 2006 18:50:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5oSx-000BRc-2B for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 18:50:43 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 1561B56821; Wed, 26 Jul 2006 11:50:41 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060726144927.03d18a50@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 26 Jul 2006 14:50:41 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , "Scott Rose" , "DNSEXT WG" From: Mike StJohns Subject: Re: 3 comments on timers-03 In-Reply-To: <7.0.1.0.2.20060726143556.03dd6a30@ogud.com> References: <7.0.1.0.2.20060726143556.03dd6a30@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Please no... part of the reason I didn't do that=20 is because it isn't necessarily a separate=20 application, codebase or whatever. I'd *really*=20 prefer not to add this because I think it will=20 actually cause more confusion, not less. Mike At 02:42 PM 7/26/2006, =D3lafur Gu=F0mundsson wrote: > > >At 13:46 26/07/2006, Scott Rose wrote: >>I have been reading the draft-timers-03, and I know there are other >>comments, but I think these are unrelated. 2 are minor, one is a response >>to a discussion point in the draft. >> >>First the minor ones >>1. "resolver" is used several times when the actual component performing >>the action would be the validator. > > >Actually I think we need a new term in this discussion, >in my mind the old terms perform > resolver =3D DNS entity that performs lookup > validator =3D entity that validates DNS responses > >the new term describes the new function caused by key management: > TA-maintainer =3D entity that keeps track of current TA's for the > all the trust anchor points it is configured with. > > Olafur > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 15:11:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ome-0008CD-0I for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 15:11:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5omd-00062F-Tf for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 15:11:03 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5omb-0007cB-Dk for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 15:11:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5okU-000EF1-6O for namedroppers-data@psg.com; Wed, 26 Jul 2006 19:08:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5okT-000EEd-0a for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 19:08:49 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6QJ8ioi029244 for ; Wed, 26 Jul 2006 15:08:44 -0400 Received: from gorilla ([129.6.220.5]) by postmark.nist.gov (8.13.7/8.13.7) with SMTP id k6QJ8157016921 for ; Wed, 26 Jul 2006 15:08:02 -0400 (EDT) From: "Scott Rose" To: "DNSEXT WG" Subject: RE: 3 comments on timers-03 Date: Wed, 26 Jul 2006 15:08:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <7.0.1.0.2.20060726135818.03de5b18@nominum.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Mike StJohns > >First the minor ones > >1. "resolver" is used several times when the actual component performing > >the action would be the validator. > > The resolver conceptually includes the resolution part, the validator > part and the trust anchor database part. The management of the > database is actually either part of the resolver, or an external > application rather than part of the validator. I did a quick scan > and I think my language is mostly consistent with that. I'll do a > bit deeper review on the next pass, but it would help if you'd point > to the specific instances - thanks! > I'll go through again and maybe spot some specific cases. As with the other thread, I agree that adding more terminology might make things more confusing. > > >2. Section 5.1 - the 5th step is "wait a while". This step seems > >unnecessary. Or, if a time limit is really needed before any other > >operation, the time could be the TTL of the DNSKEY RRset or the > min TTL of > >the SOA RR. But I think it's unnecessary. > > That was meant to refer to the hold down time for the add anchor > operation. Basically, once you've posted the data (as the data > originator), the trust anchor doesn't become valid - at each resolver > - until some period of time has expired and certain actions are taken > by the resolvers. That's described in the resolver state table as > the AddPend stage. Section 5 is meant to describe what things look > like from the data originators point of view - some resolvers are > going to get the new trust anchor fairly quickly, others might have > just missed their last timed update and may take a while to get the > new anchor, so "Wait a while" seemed to be sufficient. > > Next rev I'll add "... - the new trust anchor will be populated at > the resolvers on the schedule described by the state table and update > algorithm - see section 2.3 above" > I think that's fine. > >For the discussion point in section 4.2 (states). In the > "missing" state, > >if a DNSKEY is removed from a RRset, it should be dropped as a > trust anchor. > >I don't know if there should be a wait of the "hold down" time > or not. If > >the RRset validates and there is a trust anchor, then it is a > mistake in the > >rollover process and the missing trust anchor could be dropped. > > You definitely don't want to delete a trust anchor from a set just > because it's missing once. The example for why that would be a *bad > thing* is an operator publishing a trust point DNSKEY RRSet sans that > trust anchor by mistake, and then realizing the mistake after a few > hours. Any resolver that retrieved that RRSet would delete the trust > anchor and when the problem was fixed in a few hours, would be out of > step with what the rest of the resolvers thought were the trust > anchors for that trust point. OTOH, eventually that accidentally > deleted key would rejoin the set of trust anchors after the add hold > down period. > > > >If there is no trust anchor anymore (i.e. the only trust anchor is now > >missing) - then there needs to be a timeout before dropping, > just in case of > >a man-in-the-middle dropping the DNSKEY RRset from messages. > > If I were going to drop this, I'd probably set a hold down time for > dropping it to be something like twice the hold down time for adding > it. I'd probably also refuse to drop it unless I got a validated > RRSet from the trust point which didn't include the trust anchor - > and without a second trust anchor, that would be impossible so I'd > never drop a single trust anchor. > > Hmm... > > It makes the state table more complex, but it's do-able. > > So the trade offs are a more complex state table vs just hanging on > to a non-revoked but missing trust anchor. > I agree with the second part - dropping only when I have a valid secondary trust anchor. But if the cost is a more complex state table, and the only benefit is missing (and possiblty revoked, or not) keys are no longer cluttering up my validator, I don't know if the trade-off is worth it, but then I haven't tried to implement this yet. > Comments? > > > >Scott > > > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 19:08:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sUQ-00067E-UF for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 19:08:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sUQ-0003i3-D4 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 19:08:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5sPy-000G6o-Lm for namedroppers-data@psg.com; Wed, 26 Jul 2006 23:03:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5sPv-000G1d-QZ for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 23:03:51 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k6QN38na003480; Wed, 26 Jul 2006 16:03:22 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 12:38:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Wed, 26 Jul 2006 12:38:06 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: Acawl3Ao+WfNmHogRh+TR3QAbHzv7QAK2TkgAAkJPeA= From: "Hallam-Baker, Phillip" To: "Hallam-Baker, Phillip" , "Roy Arends" , X-OriginalArrivalTime: 26 Jul 2006 19:38:05.0517 (UTC) FILETIME=[03DBAFD0:01C6B0EB] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e OK in response to a request for clarification here: =20 > Hallam-Baker, Phillip > > > sure it was a good idea to specify the file format, anyway. IETF=20 > > > should be about protocols, not about file formats.) >=20 > Which is of course exactly how I would expect legacy=20 > resolvers to handle the scheme. This part of the scheme is the same as Should be "This part of the scheme is the same as we would have to do to = satisfy the use cases for policy administration even with a new record" > > If it was not for zone transfers and for DNSSEC there would=20 > be no reason to have wildcards mentioned in the protocol spec=20 > at all. That is why the ambiguity could enter the system and=20 > create the need for clarification decades later. The point here is that a wildcard only ever appears on the wire in a DNS = protocol exchange in two cases: 1) During a zone transfer 2) If DNSSEC is in use If neither of these features existed there would be no reason for = wildcards to be mentioned in the DNS spec at all. They would be a server = configuration feature, no more. It would not matter how the wildcards = were defined, there would be no interoperability issue. The interoperability issue here has become apparent because we do have = DNSSEC. I believe that the definition of wildcard we have now is the = optimal one for DNSSEC. I don't suggest changing it since doing so would = result in complexity being shifted to other parts of the spec. If wildcards were a feature that appeared on the wire in contexts which = required interoperation I am sure that the ambiguities in the original = definition would have been discovered earlier. =20 > In the context of DKIM there is a need to demonstrate that=20 > the wildcard problem can be solved by a script. Note that=20 > this wildcard problem, the fact that wildcards don't have the=20 > exact semantics you would want is an issue regardless of how=20 > the records are encoded (TXT, new record, prefixed, not). >=20 > The alternatives on offer here are=20 > 1) The existing heuristic search=20 > 2) The macro-wildcard mechanism proposed here plus a new RR > 3) The macro-wildcard mechanism plus the pointer scheme=20 > 'super-wildcards'=20 > with either a new RR or a prefix label >=20 > I think that most of us here would agree that (1) is not a=20 > satisfactory solution. To give some more context. At present a DKIM policy record can make two = useful statements that we all agree are essential: 1) This mail domain originates no mail. 2) All mail that this domain originates is signed. In case (1) the messages can simply be blocked. For example mail from = ver1sign.com is all bogus without exception and should be junked, the = domain is only registered to prevent cybersquatters. In case 2 an unsigned message or a message with a failed signature might = be fake or might be a legitimate message that was mangled somehow. This = information plus other information may be used by spam filters, phishing = detection etc. So the problem with policy is how to declare an email signing policy for = **.example.com that takes effect if there is no more specific policy. = The objective being to specify policies such as: example.com DKIM "ALL mail is signed" **.example.com DKIM "No mail is originated" In the case that example.com is paypal.com or bankamerica.com I think we = can all agree that policies of this type are legitimate. In the case = that someone has complaints about the management of *.cs.utk.edu they = can take it up with their admin. Anyone who really, really wants to set = their email configuration themselves should buy themselves their own = domain name. Its like owning your own cell phone number, more important = than you might think. The problem is that you may have an attacker send an email from=20 A.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com Checking every node for a policy record is not acceptable. This is made = worse when you use a prefix convention (similar to SRV) as you can't = even use a traditional wildcard. At present the spec has a heuristic algorithm, walk up the tree three = rungs from the bottom, then start at the top. That is the option (1) = described. If we define a new RR we can replace the heuristic algorithm with a = scripted wildcard (macro-wildcard). This works for DKIM but doing it = this way means that we have to repeat the process for every protocol = that has a defined policy and the number of macro wildcards will quickly = increase. The third option is macro-wildcards plus pointers (super-wildcards). = This provides a clear benefit whether you define a new RR or not. The only impact that super-wildcards have on defining a new record are: 1) You might not want to redefine PTR for use in the forward DNS in this = way and so want to define a new RR 2) The super wildcard scheme is prefix friendly and so you may not want = to use a new record for the policy scheme. If there was no legacy deployment of DNS my preferred route would be to = propose defining a new RR for the pointer and a new RR which would be = used in the same way as SRV, prefixed for defining policy records. Given the DNS legacy that we have and the fact that much of it is now = embedded in NAT boxes such as the netgear I just threw out as a POS I am = very averse to creating new RRs unless there is a very significant = change in the functionality of DNS itself. I can imaging getting netgear and linksys to make a DNSSEC capable NAT = box, I can't see people making special arrangements for DKIM. This is a = problem for me because I see Secure Letterhead as the train to drive = deployment of DKIM and DKIM as the train to drive deployment of DNSSEC = and thus in turn the infrastructure changes necessary to support new DNS = records. If deployment of DNSSEC becomes a precondition for deployment = of DKIM I have a deadlock situation. In the simulation models I have run = deployment takes decades rather than years with the same set of value = proposition assumptions. >=20 > > Okay, it can be preprocessed, but that is going to be a helluva big=20 > > zone >=20 > The expansion factor for super-wildcards is similar to the=20 > expansion factor for DNSSEC, i.e the number of new records is=20 > proportional to the number of nodes plus the number of=20 > protocol policy declarations. >=20 > The expansion factor for macro-wildcards plus a new RR is the=20 > proportional to the number of nodes MULTIPLIED BY the number=20 > of protocol policy declarations. >=20 >=20 > If we believe that DKIM is the only protocol policy record we=20 > will need then both schemes result in the same expansion of the zone. >=20 > My belief is that we are about to see a dramatic expansion in=20 > the number of Internet protocols as a result of Web services.=20 > The key here is that the variation in services for human=20 > consumption is rather small because people need consistency=20 > in their user interfaces. I don't expect there to be many new=20 > human interface protocols, the exceptions to this rule are=20 > mostly games. Machine/Machine interfaces are not constrained=20 > in that way, I expect we will have hundreds of Web Services=20 > in regular use and SOAP is sufficiently complex that a policy=20 > layer is essential for configuration. >=20 > We could develop something like UDDI or XRI. I don't like the=20 > idea of yet another registry. We could use LDAP but today=20 > LDAP stops at the firewall and that is going to be the case=20 > tommorow as well and I don't expect that to change. LDAP is=20 > too powerful and too complex for border directories to be=20 > something people get comfortable with. >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with the word 'unsubscribe'=20 > in a single line as the message text body. > archive: >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 19:12:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sYl-0007lx-20 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 19:12:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sYi-0003yg-KP for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 19:12:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5sX8-000H5R-Vs for namedroppers-data@psg.com; Wed, 26 Jul 2006 23:11:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5sX6-000H52-Iw for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 23:11:17 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k6QNBBft016581; Wed, 26 Jul 2006 18:11:11 -0500 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k6QNBBNo021404; Wed, 26 Jul 2006 18:11:11 -0500 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 19:11:10 -0400 Received: from spx.vb.futz.org ([216.27.162.138]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 19:31:42 -0400 Date: Wed, 26 Jul 2006 19:11:01 -0400 From: Robert Story To: Mike StJohns Cc: "Scott Rose" , "DNSEXT WG" Subject: Re: 3 comments on timers-03 In-Reply-To: <7.0.1.0.2.20060726135818.03de5b18@nominum.com> References: <7.0.1.0.2.20060726135818.03de5b18@nominum.com> Organization: SPARTA X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_zpKdl13IZfUWE.Q8HneUofW; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-ID: X-OriginalArrivalTime: 26 Jul 2006 23:31:42.0484 (UTC) FILETIME=[A69F1D40:01C6B10B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c --Sig_zpKdl13IZfUWE.Q8HneUofW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 26 Jul 2006 14:22:25 -0400 Mike wrote: MS> >For the discussion point in section 4.2 (states). In the "missing" st= ate, MS> >if a DNSKEY is removed from a RRset, it should be dropped as a trust a= nchor. MS> >I don't know if there should be a wait of the "hold down" time or not.= If MS> >the RRset validates and there is a trust anchor, then it is a mistake = in the MS> >rollover process and the missing trust anchor could be dropped. MS>=20 MS> You definitely don't want to delete a trust anchor from a set just=20 MS> because it's missing once. Isn't this exactly the attack vector described in the first paragraph of section 2.1? The corner case that bugs me with the timers draft is if an attacker manages to get a new key into a published DNSKEY RRSet and it goes unnoticed for the add hold-down period. Resolvers will consider it a valid trust anchor. When the operator notices this and re-publishes, they can omit the bad key, but not revoke it. Resolvers that have the bad key will continue to trust it until the remove hold-down timer expires. --=20 Robert Story SPARTA --Sig_zpKdl13IZfUWE.Q8HneUofW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEx/aL7/fVLLY1mngRAq7rAJ9vdylO38YcZ2ExWZceim0Slx/a1QCeIM8j 6HGKtEdsWRdoEJ3JQSDFRD8= =0ra6 -----END PGP SIGNATURE----- --Sig_zpKdl13IZfUWE.Q8HneUofW-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 20:01:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tJH-0000xf-6z for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 20:01:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5tJF-0000wT-Oh for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 20:01:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5tH2-000MCh-Of for namedroppers-data@psg.com; Wed, 26 Jul 2006 23:58:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5tH1-000MBM-Tc for namedroppers@ops.ietf.org; Wed, 26 Jul 2006 23:58:43 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 7848AE6079 for ; Wed, 26 Jul 2006 23:58:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k6QNwS2B016475; Thu, 27 Jul 2006 09:58:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200607262358.k6QNwS2B016475@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" Cc: "Roy Arends" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: a suggestion for super-wildcards In-reply-to: Your message of "Wed, 26 Jul 2006 12:38:06 MST." <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Thu, 27 Jul 2006 09:58:28 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Why is the policy in the DNS in the first place? It keeps looking less and less like a good fit. Add a way to find a DKIM policy server to the DNS and let it hand out the actual policies. This should make it very easy for per user policies without having to worry about namespace collisions which is what the underscores where trying to prevent with SRV. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 20:23:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tf9-00062J-KO for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 20:23:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5tf8-0003y3-Ag for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 20:23:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5tcT-000O6Q-Dg for namedroppers-data@psg.com; Thu, 27 Jul 2006 00:20:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5tcS-000O6C-Bj for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 00:20:52 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k6R0KiBY026223; Wed, 26 Jul 2006 17:20:44 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 17:20:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Wed, 26 Jul 2006 17:20:43 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6B65@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: AcaxD3do6uvzqhhkREavI7DcBxQd/AAAvSWQ From: "Hallam-Baker, Phillip" To: Cc: "Roy Arends" , X-OriginalArrivalTime: 27 Jul 2006 00:20:44.0043 (UTC) FILETIME=[7FED65B0:01C6B112] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 The policies relate to the use of a DNS name. Therefore they will be in the DNS This is not negotiable.=20 > -----Original Message----- > From: Mark_Andrews@isc.org [mailto:Mark_Andrews@isc.org]=20 > Sent: Wednesday, July 26, 2006 7:58 PM > To: Hallam-Baker, Phillip > Cc: Roy Arends; namedroppers@ops.ietf.org > Subject: Re: a suggestion for super-wildcards=20 >=20 >=20 > Why is the policy in the DNS in the first place? > It keeps looking less and less like a good fit. > Add a way to find a DKIM policy server to the DNS > and let it hand out the actual policies. This > should make it very easy for per user policies without > having to worry about namespace collisions which is > what the underscores where trying to prevent with SRV. > =09 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 20:45:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5u0K-0006Ki-EY for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 20:45:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5u0J-0000Zs-4a for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 20:45:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5txu-0000RK-5M for namedroppers-data@psg.com; Thu, 27 Jul 2006 00:43:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5txt-0000R6-Jw for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 00:43:01 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id E1FE8E6050 for ; Thu, 27 Jul 2006 00:43:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k6R0gtkX016775; Thu, 27 Jul 2006 10:42:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200607270042.k6R0gtkX016775@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" Cc: "Roy Arends" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: a suggestion for super-wildcards In-reply-to: Your message of "Wed, 26 Jul 2006 17:20:43 MST." <198A730C2044DE4A96749D13E167AD37BD6B65@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Thu, 27 Jul 2006 10:42:55 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca > The policies relate to the use of a DNS name. No. They relate to mail domains. We may store somethings about mail domains in the DNS. We also store things about mail domain in NIS, and HOST.TXT files. > Therefore they will be in the DNS > > This is not negotiable. Saying something is "not negotiable" is utter crap. Mark > > -----Original Message----- > > From: Mark_Andrews@isc.org [mailto:Mark_Andrews@isc.org] > > Sent: Wednesday, July 26, 2006 7:58 PM > > To: Hallam-Baker, Phillip > > Cc: Roy Arends; namedroppers@ops.ietf.org > > Subject: Re: a suggestion for super-wildcards > > > > > > Why is the policy in the DNS in the first place? > > It keeps looking less and less like a good fit. > > Add a way to find a DKIM policy server to the DNS > > and let it hand out the actual policies. This > > should make it very easy for per user policies without > > having to worry about namespace collisions which is > > what the underscores where trying to prevent with SRV. > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 26 23:31:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wav-0006ut-1q for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 23:31:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wat-0005b0-OR for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 23:31:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5wXU-000JoV-H4 for namedroppers-data@psg.com; Thu, 27 Jul 2006 03:27:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5wXT-000Jo6-QB for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 03:27:55 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k6R3Rl3m013654; Wed, 26 Jul 2006 20:27:51 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:27:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Wed, 26 Jul 2006 20:27:43 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6B7E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: AcaxFaCcNUCZUL51QX+kIsHf3UGG3AAFfeMQ From: "Hallam-Baker, Phillip" To: Cc: "Roy Arends" , X-OriginalArrivalTime: 27 Jul 2006 03:27:51.0517 (UTC) FILETIME=[A405F8D0:01C6B12C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 =20 > From: Mark_Andrews@isc.org [mailto:Mark_Andrews@isc.org]=20 > > The policies relate to the use of a DNS name. >=20 > No. They relate to mail domains. We may store somethings > about mail domains in the DNS. We also store things about > mail domain in NIS, and HOST.TXT files. The only mail domains that matter are the DNS. Hosts.txt is now a = serious security hazard and should be eliminated on non test machines. NIS is not an Internet resource. If your NIS service is visible outside = your firewall you have big problems. It is irrelevant to this issue. > > Therefore they will be in the DNS > >=20 > > This is not negotiable.=20 >=20 > Saying something is "not negotiable" is utter crap. The DNS is the only credible resource to distribute this information. = Get over it. If a different resource is used there will be no way for DKIM to drive = DNSSEC deployment. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 00:05:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5x87-0000OY-Rn for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 00:05:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5x86-0000RF-Hl for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 00:05:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5x67-000OwS-FN for namedroppers-data@psg.com; Thu, 27 Jul 2006 04:03:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5x66-000OwF-T6 for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 04:03:42 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k6R43a2F014613; Wed, 26 Jul 2006 21:03:36 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 21:03:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Wed, 26 Jul 2006 21:03:33 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6B89@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: AcaxLXaElgBPDBzzSzqKkvB8jlzr+AAAzQpw From: "Hallam-Baker, Phillip" To: Cc: "Roy Arends" , X-OriginalArrivalTime: 27 Jul 2006 04:03:36.0937 (UTC) FILETIME=[A2CB1590:01C6B131] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > From: Mark_Andrews@isc.org [mailto:Mark_Andrews@isc.org]=20 > Did you even read what I proposed? The above comments indicate > that you didn't or that you failed to understand the proposal. Yes, I am fully familiar with the limitations of that approach. I was = the editor of XKMS which does precisely what you propose. First you still have the discovery problem for the XKMS service. You = have to have a way of discovering the policy service for each DNS node. = So you end up with precisely the same set of problems only with SRV = records. Incidentally the same extension should be made to SRV and NAPTR, the = idea is that superwildcards should be a generic mechanism applied to ANY = prefixed lookup to a node. If you are going to go find a policy distribution service you might as = well retrieve the policy if it is as simple as 'I sign all mail' or 'I = send no mail'.=20 Clearly there is a balance point, I even propose retrieving longer = policies via URL. Whichever way you go though you need to employ the DNS as the signalling = mechanism. There can only be one Internet name space.=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 00:32:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xY8-0004qM-0l for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 00:32:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wiO-0005xG-NE for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 23:39:12 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5web-0007oE-P9 for dnsext-archive@lists.ietf.org; Wed, 26 Jul 2006 23:35:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5wd5-000Ki7-UN for namedroppers-data@psg.com; Thu, 27 Jul 2006 03:33:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5wd5-000Kht-BU for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 03:33:43 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id B1769E6079 for ; Thu, 27 Jul 2006 03:33:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k6R3XXoY062406; Thu, 27 Jul 2006 13:33:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200607270333.k6R3XXoY062406@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" Cc: "Roy Arends" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: a suggestion for super-wildcards In-reply-to: Your message of "Wed, 26 Jul 2006 20:27:43 MST." <198A730C2044DE4A96749D13E167AD37BD6B7E@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Thu, 27 Jul 2006 13:33:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > > > From: Mark_Andrews@isc.org [mailto:Mark_Andrews@isc.org] > > > > The policies relate to the use of a DNS name. > > > > No. They relate to mail domains. We may store somethings > > about mail domains in the DNS. We also store things about > > mail domain in NIS, and HOST.TXT files. > > The only mail domains that matter are the DNS. Hosts.txt is now a serious sec > urity hazard and should be eliminated on non test machines. > > NIS is not an Internet resource. If your NIS service is visible outside your > firewall you have big problems. It is irrelevant to this issue. > > > > Therefore they will be in the DNS > > > > > > This is not negotiable. > > > > Saying something is "not negotiable" is utter crap. > > The DNS is the only credible resource to distribute this information. Get ove > r it. > > If a different resource is used there will be no way for DKIM to drive DNSSEC > deployment. Did you even read what I proposed? The above comments indicate that you didn't or that you failed to understand the proposal. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 02:30:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zNx-00062V-R6 for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 02:30:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5zNw-0002Ln-FD for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 02:30:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5zKW-000EPz-2w for namedroppers-data@psg.com; Thu, 27 Jul 2006 06:26:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [204.14.89.6] (helo=mail2.fluidhosting.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5zKV-000EPo-5k for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 06:26:43 +0000 Received: (qmail 18660 invoked by uid 399); 27 Jul 2006 06:26:42 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 27 Jul 2006 06:26:42 -0000 Message-ID: <44C85CA0.6030806@dougbarton.us> Date: Wed, 26 Jul 2006 23:26:40 -0700 From: Doug Barton User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: Roy Arends , namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards References: <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On the one hand, because I have in the past wanted something similar to what you're proposing, the theoretical concept of these super wildcards is appealing. However, from a protocol standpoint the idea gives me a serious case of the screaming heebeejeebees. So, I have a question ... Hallam-Baker, Phillip wrote: > To give some more context. At present a DKIM policy record can make two > useful statements that we all agree are essential: > > 1) This mail domain originates no mail. > 2) All mail that this domain originates is signed. [ ... ] > So the problem with policy is how to declare an email signing policy for > **.example.com that takes effect if there is no more specific policy. The > objective being to specify policies such as: > > example.com DKIM "ALL mail is signed" > **.example.com DKIM "No mail is originated" Ok, your problem statement makes total sense to me, but I think you're missing a third option. I'm assuming that the DKIM protocol has a way to handle total absence of a policy for a domain. So, what if you added a heuristic to the DKIM protocol that says, "If I do not find a policy at this node, I will go down the tree until I either find a policy, or hit the TLD." In regards to your problem of spammers that try sending mail from 1.2.3.4..99.spammer-domain.tld, if the spammers have control over that domain and can add a node at that point, it will eat up resources to walk that tree, no doubt. OTOH, if they are playing silly buggers with a domain they don't have control over, I assume DKIM is smart enough to say that if there are NO records at all for a node, that it isn't legitimate? Either way, I agree that the issue you raise is still a problem, however I think that my proposed solution places the burden for dealing with that problem in the DKIM protocol, which is arguably where it belongs. Doug -- If you're never wrong, you're not trying hard enough -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 05:13:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G61wI-00013w-Bt for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 05:13:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G61wG-0004RW-UJ for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 05:13:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G61sU-0007wh-TP for namedroppers-data@psg.com; Thu, 27 Jul 2006 09:09:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.30.85.225] (helo=io.link-m.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G61sT-0007wQ-Al for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 09:09:57 +0000 Received: from gray.home.mehnle.net (ppp-82-135-80-28.dynamic.mnet-online.de [::ffff:82.135.80.28]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,56bits,EXP1024-RC4-SHA) by io.link-m.de with esmtp; Thu, 27 Jul 2006 09:09:53 +0000 id 0001B20D.44C882E1.000047F2 From: Julian Mehnle To: namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards Date: Thu, 27 Jul 2006 09:09:50 +0000 User-Agent: KMail/1.9.1 Cc: SPF Discussion References: <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <44C85CA0.6030806@dougbarton.us> In-Reply-To: <44C85CA0.6030806@dougbarton.us> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607270909.51825.julian@mehnle.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doug Barton wrote: > Hallam-Baker, Phillip wrote: > > So the problem with policy is how to declare an email signing policy > > for **.example.com that takes effect if there is no more specific > > policy. The objective being to specify policies such as: > > > > example.com DKIM "ALL mail is signed" > > **.example.com DKIM "No mail is originated" > > Ok, your problem statement makes total sense to me, but I think you're > missing a third option. I'm assuming that the DKIM protocol has a way to > handle total absence of a policy for a domain. So, what if you added a > heuristic to the DKIM protocol that says, "If I do not find a policy at > this node, I will go down the tree until I either find a policy, or hit > the TLD." > > In regards to your problem of spammers that try sending mail from > 1.2.3.4..99.spammer-domain.tld, if the spammers have control over that > domain and can add a node at that point, it will eat up resources to > walk that tree, no doubt. We (the SPF folks) once debated doing such an upwards domain walk for SPF, but decided against it for exactly the reason you mention above. It was simply deemed too costly. Finding an applicable policy for a sub-domain is still an unsolved problem, though. > OTOH, if they are playing silly buggers with a domain they don't have > control over, I assume DKIM is smart enough to say that if there are NO > records at all for a node, that it isn't legitimate? Yeah, mail with a non-existent domain as the sender (envelope sender, From/ Sender headers, whatever) should be rejected anyway. The problem remains for sub-domains that actually exist. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEyILfwL7PKlBZWjsRAlZXAKCkBsZfCYIGwSdd2NLZGdpgdGVlCwCfa69H zd1AgHikVbWw/0j5wWMShJU= =W60X -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 09:29:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65vu-0003Kn-8N for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 09:29:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65vt-0008OI-CA for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 09:29:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G65rf-0009Zp-RF for namedroppers-data@psg.com; Thu, 27 Jul 2006 13:25:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G65rd-0009Z9-BX for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 13:25:23 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6RDPDhG016904 for ; Thu, 27 Jul 2006 09:25:13 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k6RDPDbN016903 for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 09:25:13 -0400 (EDT) (envelope-from namedroppers) Received: from [198.144.196.2] (helo=laser.networkresonance.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5tlE-000OwU-TY for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 00:29:57 +0000 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 8C0E9222426 for ; Wed, 26 Jul 2006 17:38:00 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Notes on DNSSEC key rollover X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Wed, 26 Jul 2006 17:29:56 -0700 From: Eric Rescorla Message-Id: <20060727003800.8C0E9222426@laser.networkresonance.com> X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] I've taken a look at the various dnsext key rollover documents and wanted to provide some comments. This is the first of two messages, the first up-levelling on the general rollover problem, and the second providing specific comments on draft-ietf-dnsext-trustupdate-timers. Rambling follows.... BACKGROUND ---------- DNSSEC, like nearly all public key authentication systems, assumes that you have some set of trust anchors configured into your system and that you use them to transitively verify other keys in the system [0]. Pretty much by definition, the initial set of trust anchors are either shipped with the verifying software or are manually configured. There's then a machine verifiable chain of signatures from some trust anchor to any given verifiable data item (e.g., certificate). The question then arises about how to replace the keys for the trust anchors. Roughly speaking, there are two reasons to roll over your signing keys: 1. You're trying to stay ahead of the attacker's cost curve (Moore's Law, progress in factoring, etc.) 2. Your key(s) have been compromised. Reason 1 is fairly straightforward. At time 0, You make a key (K0) with an expected lifespan of X years. At a reasonable time before X (say X/2) you generate a new key (K1) with an expected lifespan of Y years and distribute it somehow. The way this is done in browsers is that you just get the new key placed in the current revision of the browser and assume that the new revision will percolate out before key K0 expires. Reason 2 is more problematic and the browser world has mostly chosen to punt on it. The theory here is that if a root key is ever known to be compromised, the browswer manufacturers will just release a security patch without that key--and maybe with the replacement--and propagate it via the usual mechanisms. Given that there are lots of security vulnerabilities worse than a compromised key and we let the ordinary patch process handle them, this doesn't seem crazy. In other words, the browser world doesn't have any mechanism for root rollover separate from the normal software update process. ISLANDS ------- In an ideal DNSSEC world, there would only be one trust anchor: the root signing key, or a small number of mostly static anchors, like the 100 or so that are in your average browser. As a practical matter, people seem to be assuming that there will be a bunch of islands--signed subtrees within a generally unsigned DNS tree. The problem that people appear to be grappling with is: (a) How to provision those island keys. (b) How to roll them over if they're compromised. To that end, we have (at least): draft-ietf-dnsext-rollover-requirements-02 draft-ietf-dnsext-trustupdate-timers-02 draft-ietf-dnsext-trustupdate-threshold-01 draft-laurie-dnssec-key-distribution-02 The matter is somewhat complicated by the fact of multiple certificate formats. So, for instance, one could imagine that you were operating the island "example.com". You could get an ordinary SSL/TLS certificate from VeriSign for "example.com" and distribute your DNSSEC trust anchor definition over SSL/TLS. From a DNSSEC perspective, this is automatic provisioning of the island key, but from a security perspective it's a single root of trust rooted in VeriSign and is isomorphic to ordinary CA operation. A similar situation would obtain if, e.g., ISC periodically published a new island key list for BIND users to download. PROBLEMS TO SOLVE ----------------- It seems to me that there are three problems that need to be solved here: 1. How to initially provision island keys. 2. How to transition between two keys (assuming you have some way to validate the replacement key). 3. How to validate the replacement key. Problem 2 is a straightforward protocol engineering problem. I get the impression that it's not entirely solved based on S 3.8 of draft-ietf-dnsext-trustupdate-threshold, but it's not tricky in any abstract sense. Problems 1 and 3 are tricky, however. INITIAL PROVISIONING -------------------- Roughly speaking, there are four classes of initial provisioning solutions: - Manual provisioning -- you manually enter the keys - Leap of faith -- you trust the first key you get for a given zone - Central trust anchor -- you trust signatures from some central trust anchor. This could either be a conventional CA like I indicated in my example above or just your software vendor who ships you the current trust anchor list - Web of trust -- you trust some set of people and they sign keys for other people and you somehow compute a trust metric over the signatures. Note that a central trust anchor is basically just a single root and it makes sense to treat it that way, even if the signatures are done with some non-DNSSEC mechanism. So, for the purposes of rollover we'll assume you're provisioning some other way. ROLLOVER -------- If rollover is very rare, then you can handle it via whatever mechanism you use for provisioning. For instance, if your SSH client detects a key change, you call the admin and check the new fingerprint. A similar approach could be used for manual keying here. However, if rollover is frequent then this clearly becomes impractical. The natural way to handle automatic rollover for non-compromised keys is simply to have each key have an expiry date and for K_n to sign K_n+1 well before it expires. This has an obvious problem when what you're worried about is compromise of key K_n, since any signature from K_n is inherently untrustworthy. The classic approach to dealing with this problem is to have two keys: 1. An operational key which is used to sign data. 2. A high-assurance key which is only used to sign operational keys. The operational key has a modest security level and is signed by the high assurance key. If an operational key is ever compromised the high assurance key is used to sign a new operational key (and depending on the system, a revocation). The high-assurance key has a very high security level (keylength) and is generally maintained in some sort of trusted computing environment (i.e., hardware). It has a very long expiry and is assumed never to be compromised. If it is compromised, it's an emergency and you handle it in some out-of-band manual way (e.g., publish a CERT advisory). You can roll over the high assurance key in non-compromise cases as indicated above. [1] This is sort of similar to the ZSK/KSK split in DNSSEC but it's not entirely clear to me if people intend the KSKs to have very long lifespans and to be used very infrequently, which is what's required by this security model. In particular, it appears from the various documents that people intend to be able to rollover compromised KSKs, which cuts against that theory. -Ekr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 09:40:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G666l-0001rg-PT for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 09:40:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G666l-0001WY-9r for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 09:40:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G664x-000BWu-Rj for namedroppers-data@psg.com; Thu, 27 Jul 2006 13:39:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [198.144.196.2] (helo=laser.networkresonance.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G664w-000BWd-PT for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 13:39:07 +0000 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id BFCB8222425 for ; Thu, 27 Jul 2006 06:47:09 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Notes on DNSSEC key rollover X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Thu, 27 Jul 2006 06:39:06 -0700 From: Eric Rescorla Message-Id: <20060727134709.BFCB8222425@laser.networkresonance.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 [Resent now that I've fixed my subscription....] I've taken a look at the various dnsext key rollover documents and wanted to provide some comments. This is the first of two messages, the first up-levelling on the general rollover problem, and the second providing specific comments on draft-ietf-dnsext-trustupdate-timers. Rambling follows.... BACKGROUND ---------- DNSSEC, like nearly all public key authentication systems, assumes that you have some set of trust anchors configured into your system and that you use them to transitively verify other keys in the system [0]. Pretty much by definition, the initial set of trust anchors are either shipped with the verifying software or are manually configured. There's then a machine verifiable chain of signatures from some trust anchor to any given verifiable data item (e.g., certificate). The question then arises about how to replace the keys for the trust anchors. Roughly speaking, there are two reasons to roll over your signing keys: 1. You're trying to stay ahead of the attacker's cost curve (Moore's Law, progress in factoring, etc.) 2. Your key(s) have been compromised. Reason 1 is fairly straightforward. At time 0, You make a key (K0) with an expected lifespan of X years. At a reasonable time before X (say X/2) you generate a new key (K1) with an expected lifespan of Y years and distribute it somehow. The way this is done in browsers is that you just get the new key placed in the current revision of the browser and assume that the new revision will percolate out before key K0 expires. Reason 2 is more problematic and the browser world has mostly chosen to punt on it. The theory here is that if a root key is ever known to be compromised, the browswer manufacturers will just release a security patch without that key--and maybe with the replacement--and propagate it via the usual mechanisms. Given that there are lots of security vulnerabilities worse than a compromised key and we let the ordinary patch process handle them, this doesn't seem crazy. In other words, the browser world doesn't have any mechanism for root rollover separate from the normal software update process. ISLANDS ------- In an ideal DNSSEC world, there would only be one trust anchor: the root signing key, or a small number of mostly static anchors, like the 100 or so that are in your average browser. As a practical matter, people seem to be assuming that there will be a bunch of islands--signed subtrees within a generally unsigned DNS tree. The problem that people appear to be grappling with is: (a) How to provision those island keys. (b) How to roll them over if they're compromised. To that end, we have (at least): draft-ietf-dnsext-rollover-requirements-02 draft-ietf-dnsext-trustupdate-timers-02 draft-ietf-dnsext-trustupdate-threshold-01 draft-laurie-dnssec-key-distribution-02 The matter is somewhat complicated by the fact of multiple certificate formats. So, for instance, one could imagine that you were operating the island "example.com". You could get an ordinary SSL/TLS certificate from VeriSign for "example.com" and distribute your DNSSEC trust anchor definition over SSL/TLS. From a DNSSEC perspective, this is automatic provisioning of the island key, but from a security perspective it's a single root of trust rooted in VeriSign and is isomorphic to ordinary CA operation. A similar situation would obtain if, e.g., ISC periodically published a new island key list for BIND users to download. PROBLEMS TO SOLVE ----------------- It seems to me that there are three problems that need to be solved here: 1. How to initially provision island keys. 2. How to transition between two keys (assuming you have some way to validate the replacement key). 3. How to validate the replacement key. Problem 2 is a straightforward protocol engineering problem. I get the impression that it's not entirely solved based on S 3.8 of draft-ietf-dnsext-trustupdate-threshold, but it's not tricky in any abstract sense. Problems 1 and 3 are tricky, however. INITIAL PROVISIONING -------------------- Roughly speaking, there are four classes of initial provisioning solutions: - Manual provisioning -- you manually enter the keys - Leap of faith -- you trust the first key you get for a given zone - Central trust anchor -- you trust signatures from some central trust anchor. This could either be a conventional CA like I indicated in my example above or just your software vendor who ships you the current trust anchor list - Web of trust -- you trust some set of people and they sign keys for other people and you somehow compute a trust metric over the signatures. Note that a central trust anchor is basically just a single root and it makes sense to treat it that way, even if the signatures are done with some non-DNSSEC mechanism. So, for the purposes of rollover we'll assume you're provisioning some other way. ROLLOVER -------- If rollover is very rare, then you can handle it via whatever mechanism you use for provisioning. For instance, if your SSH client detects a key change, you call the admin and check the new fingerprint. A similar approach could be used for manual keying here. However, if rollover is frequent then this clearly becomes impractical. The natural way to handle automatic rollover for non-compromised keys is simply to have each key have an expiry date and for K_n to sign K_n+1 well before it expires. This has an obvious problem when what you're worried about is compromise of key K_n, since any signature from K_n is inherently untrustworthy. The classic approach to dealing with this problem is to have two keys: 1. An operational key which is used to sign data. 2. A high-assurance key which is only used to sign operational keys. The operational key has a modest security level and is signed by the high assurance key. If an operational key is ever compromised the high assurance key is used to sign a new operational key (and depending on the system, a revocation). The high-assurance key has a very high security level (keylength) and is generally maintained in some sort of trusted computing environment (i.e., hardware). It has a very long expiry and is assumed never to be compromised. If it is compromised, it's an emergency and you handle it in some out-of-band manual way (e.g., publish a CERT advisory). You can roll over the high assurance key in non-compromise cases as indicated above. [1] This is sort of similar to the ZSK/KSK split in DNSSEC but it's not entirely clear to me if people intend the KSKs to have very long lifespans and to be used very infrequently, which is what's required by this security model. In particular, it appears from the various documents that people intend to be able to rollover compromised KSKs, which cuts against that theory. -Ekr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 10:15:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66eH-0000VU-Sg for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 10:15:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66eH-0007mY-RH for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 10:15:37 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G66Ul-00048d-Ld for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 10:05:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G66Sp-000EzZ-6I for namedroppers-data@psg.com; Thu, 27 Jul 2006 14:03:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G66So-000Ez9-G0 for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 14:03:46 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6RE3ZiG017188; Thu, 27 Jul 2006 10:03:36 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060727134709.BFCB8222425@laser.networkresonance.com> References: <20060727134709.BFCB8222425@laser.networkresonance.com> Date: Thu, 27 Jul 2006 10:03:37 -0400 To: Eric Rescorla From: Edward Lewis Subject: Re: Notes on DNSSEC key rollover Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 At 6:39 AM -0700 7/27/06, Eric Rescorla wrote: >Rambling follows.... Amazingly clear and concise rambling at that. >This is sort of similar to the ZSK/KSK split in DNSSEC but it's not >entirely clear to me if people intend the KSKs to have very long >lifespans and to be used very infrequently, which is what's required by >this security model. In particular, it appears from the various documents >that people intend to be able to rollover compromised KSKs, which >cuts against that theory. The difference between the use of KSK and ZSK is in what is communicated to the parent administration. The pattern of use seen in workshops that gave rise to the distinction was that we wanted to be able to change some keys quite often without having to go back to the registration process and make changes there. The distinction is born out of operation patterns and not cryptographic considerations. The KSK appeared as a "populist" reaction to having a formal boundary between parent and child. The KSK wasn't intentionally invented, the distinction was initially discouraged because we had been burned by trying to define key strength semantics in DNSSEC (RFC 2065/56, I forget) and DNSSEC II (RFC 2535). This is whence KSK and ZSK came. The KSK for some zones can be thought of as a high-assurance key, at least in institutional operations. The DNSSEC protocol however does not make the distinction between ZSK and KSK, and maybe that is where we are slashing against the theory. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 10:41:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G673A-0004I4-MY for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 10:41:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6739-0001DQ-9D for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 10:41:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G670P-000IJ7-Fh for namedroppers-data@psg.com; Thu, 27 Jul 2006 14:38:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G670M-000IIn-Sq for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 14:38:26 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k6REcMro029600; Thu, 27 Jul 2006 07:38:22 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 07:38:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Thu, 27 Jul 2006 07:38:19 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6BB9@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: AcaxRaJ+jNhohcVKQ3aPcFLsUk2lCgAQ2t2w From: "Hallam-Baker, Phillip" To: "Doug Barton" Cc: "Roy Arends" , X-OriginalArrivalTime: 27 Jul 2006 14:38:22.0465 (UTC) FILETIME=[4F897710:01C6B18A] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 > From: Doug Barton [mailto:dougb@dougbarton.us]=20 > On the one hand, because I have in the past wanted something=20 > similar to what you're proposing, the theoretical concept of=20 > these super wildcards is appealing. However, from a protocol=20 > standpoint the idea gives me a serious case of the screaming=20 > heebeejeebees. Screaming?=20 > So, I have a question ... >=20 > Hallam-Baker, Phillip wrote: > > So the problem with policy is how to declare an email=20 > signing policy=20 > > for **.example.com that takes effect if there is no more specific=20 > > policy. The objective being to specify policies such as: > >=20 > > example.com DKIM "ALL mail is signed"=20 > > **.example.com DKIM "No mail is originated" >=20 > Ok, your problem statement makes total sense to me, but I=20 > think you're missing a third option. I'm assuming that the=20 > DKIM protocol has a way to handle total absence of a policy=20 > for a domain. So, what if you added a heuristic to the DKIM=20 > protocol that says, "If I do not find a policy at this node,=20 > I will go down the tree until I either find a policy, or hit the TLD." It's the heuristic that gives me the heebeejeebees of the screaming = variety. Either you walk the tree and allow attackers to stick you with = 60 lookups or you add in some constraints and you change the semantics = of the DNS delegation as Olafur pointed out in the meeting. If you walk the tree you allow upper level domains to control the email = sending policy of lower domains even if that lower domain thinks that it = has full control because it has a delegation. Debugging problems could = well get ugly, even more so if you are running split DNS. > In regards to your problem of spammers that try sending mail=20 > from 1.2.3.4..99.spammer-domain.tld, if the spammers have=20 > control over that domain and can add a node at that point, it=20 > will eat up resources to walk that tree, no doubt. OTOH, if=20 > they are playing silly buggers with a domain they don't have=20 > control over, I assume DKIM is smart enough to say that if=20 > there are NO records at all for a node, that it isn't=20 > legitimate?=20 A lot of mail originates from addresses that are not externally visible = due to split DNS and the use of DNS wildcard MX records. The problem with the heuristic is that it results in yet another set of = semantics to deal with and possibly end up with conflicts. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 14:45:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ArK-0002g0-0X for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 14:45:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ArH-00031D-M1 for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 14:45:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6AnE-000LCD-Nz for namedroppers-data@psg.com; Thu, 27 Jul 2006 18:41:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6AnD-000LBx-Pr for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 18:41:08 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6RIew2n019942 for ; Thu, 27 Jul 2006 14:40:59 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.7/8.13.7) with SMTP id k6RIe6u3002922 for ; Thu, 27 Jul 2006 14:40:07 -0400 (EDT) From: "Scott Rose" To: "DNSEXT WG" Subject: RE: 3 comments on timers-03 Date: Thu, 27 Jul 2006 14:40:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > -----Original Message----- > From: Robert Story [mailto:rstory@sparta.com] > Sent: Wednesday, July 26, 2006 7:11 PM > MS> > MS> You definitely don't want to delete a trust anchor from a set just > MS> because it's missing once. > > Isn't this exactly the attack vector described in the first > paragraph of section 2.1? > > The corner case that bugs me with the timers draft is if an > attacker manages to get a new key into a published DNSKEY RRSet and it > goes unnoticed for the add hold-down period. Resolvers will consider it > a valid trust anchor. When the operator notices this and re-publishes, > they can omit the bad key, but not revoke it. Resolvers that have > the bad key will continue to trust it until the remove hold-down timer > expires. > Maybe, but that is a corner case. After thinking about it some more, I believe most cases where a "missing" trust anchor appears is when a zone joins a chain of trust. That is, a zone decides to stop publishing their own trust anchor and relies on a superior zone as the secure entry point. Instead of doing the correct revocation procedure, they only delete it, thus producing the missing state in the resolver/validator. Scott > -- > Robert Story > SPARTA > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 15:02:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B7q-0002DW-Vq for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 15:02:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6B7l-00045F-Jc for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 15:02:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6B4u-000NO0-4V for namedroppers-data@psg.com; Thu, 27 Jul 2006 18:59:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.222] (helo=mail2.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6B4s-000NNf-NW for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 18:59:22 +0000 Received: by mail2.sea.safepages.com (Postfix, from userid 1012) id AFB9A67E3C; Thu, 27 Jul 2006 18:59:21 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.31]) by mail2.sea.safepages.com (Postfix) with ESMTP id 7914167DC1; Thu, 27 Jul 2006 18:59:17 +0000 (GMT) Message-ID: <44C90DA4.4030201@connotech.com> Date: Thu, 27 Jul 2006 15:01:56 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Rescorla Cc: namedroppers@ops.ietf.org Subject: Re: Notes on DNSSEC key rollover References: <20060727134709.BFCB8222425@laser.networkresonance.com> In-Reply-To: <20060727134709.BFCB8222425@laser.networkresonance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Eric Rescorla wrote: > > I've taken a look at the various dnsext key rollover [...] > Thanks for sharing this fresh look at this issue. > ROLLOVER > -------- > [...] > > The natural way to handle automatic rollover for non-compromised > keys is simply to have each key have an expiry date and for > K_n to sign K_n+1 well before it expires. This has an obvious > problem when what you're worried about is compromise of key > K_n, since any signature from K_n is inherently untrustworthy. > > The classic approach to dealing with this problem is to have > two keys: > > 1. An operational key which is used to sign data. > 2. A high-assurance key which is only used to sign operational > keys. > > [...] > > This is sort of similar to the ZSK/KSK split in DNSSEC but it's not > entirely clear to me if people intend the KSKs to have very long > lifespans and to be used very infrequently, which is what's required by > this security model. In particular, it appears from the various documents > that people intend to be able to rollover compromised KSKs, which > cuts against that theory. > Not exactly. The security model for -timers (and perhaps -threshold as well) is more or less that K_n, *when or soon after it becomes "operational"*, signs K_n+1 which becomes "operational" at the end of operating period for K_n. These are all KSKs (to the extent that KSK/ZSK separation is present and relevant). The security strength is based on the assumption that private key compromise is less likely at the beginning than at the end, of the operational period. (In a previous post, I wrote "The incremental security in moving from the Paul Vixie approach to either -threshold or -timers is marginal ..." a comment which I consider unjustified now since I understand the -timers security model as explained in the previous paragraph.) The classic approach you describe is not reflected in any DNSEXT proposal. The TAKREM approach (draft-moreau-dnsext-sdda-rr, draft-moreau-dnsext-takrem-dns) is based on pre-announcements of a series of fingerprints for future keys. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 16:18:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CJG-0001l8-3a for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 16:18:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CJE-0007CN-OL for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 16:18:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6CGc-0006Dm-0K for namedroppers-data@psg.com; Thu, 27 Jul 2006 20:15:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6CGb-0006Da-1V for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 20:15:33 +0000 Received: from roaming15.int.libertyrms.com ([10.1.3.245]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1G6CGa-0006r5-DI for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 16:15:32 -0400 Received: by roaming15.int.libertyrms.com (Postfix, from userid 1019) id 0EC7C1CBCA0; Thu, 27 Jul 2006 16:15:56 -0400 (EDT) Date: Thu, 27 Jul 2006 16:15:56 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms Message-ID: <20060727201556.GR1166@afilias.info> Reply-To: Andrew Sullivan References: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20060706162725.03318bd0@ogud.com> User-Agent: Mutt/1.5.11 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On Fri, Jul 07, 2006 at 09:30:46AM -0400, =D3lafur Gu=F0mundsson /DNSEXT = co-chair wrote: > The URL for the document is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.t= xt Dear colleagues, I have read that document. I have no technical objection, and can support the document going forward. I do have some comments, however. Like another reader, I would like to suggest that the Introduction be altered to remove the references to discussion in 2004, previous last calls, &c. It would be enough to note that there were some issues identified in RFCs 4033, 4034, and 4035; that the issues have to do with "zone walking"; and that the document intends to be a (not exhaustive) survey of the proposals to address the problem. I won't withdraw my support if this isn't done, but it would make the document a little more convincing, I think. Here is proposed text: The DNSSEC specification in [[RFC4033], [RFC4034], and [RFC4035] (hereafter referred to as DNSSEC-bis) entails that it is possible to enumerate the contents of a DNSSEC-bis signed zone. This is sometimes called the "zone walking problem". Several mechanisms have been proposed to address this problem. This memo provides a summary of the various mechanisms, and an outline of the advantages and disadvantages of each. This memo is not an exhaustive survey; it is merely an attempt to outline the possibilities for future work, in an effort to provide a guide for what approaches are likely to be fruitful if pursued. If the document is to be edited anyway, I think it could use a good going-over for usage and style. At the moment, it sort of reads like the distillation of an email thread, with some poorly-constructed sentences (two at random: the last sentence in section 2.1.3 [simpliciter], where the reference of "it" is not totally plain; "Keys have to be held and processed online with all security implications" in section 2.1.7.4). Nit: s/role/roll second sentence in 2.2.2.4 Best regards, A --=20 Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 19:31:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6FKd-0001D8-3i for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 19:31:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6FKb-0007E1-Jb for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 19:31:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6FGn-000P9m-I4 for namedroppers-data@psg.com; Thu, 27 Jul 2006 23:27:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6FGm-000P9a-Er for namedroppers@ops.ietf.org; Thu, 27 Jul 2006 23:27:56 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 1016CE607A for ; Thu, 27 Jul 2006 23:27:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k6RNRXVd039717; Fri, 28 Jul 2006 09:27:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200607272327.k6RNRXVd039717@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" Cc: "Doug Barton" , "Roy Arends" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: a suggestion for super-wildcards In-reply-to: Your message of "Thu, 27 Jul 2006 07:38:19 MST." <198A730C2044DE4A96749D13E167AD37BD6BB9@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Fri, 28 Jul 2006 09:27:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac > > > From: Doug Barton [mailto:dougb@dougbarton.us] > > > On the one hand, because I have in the past wanted something > > similar to what you're proposing, the theoretical concept of > > these super wildcards is appealing. However, from a protocol > > standpoint the idea gives me a serious case of the screaming > > heebeejeebees. > > Screaming? > > > So, I have a question ... > > > > Hallam-Baker, Phillip wrote: > > > > So the problem with policy is how to declare an email > > signing policy > > > for **.example.com that takes effect if there is no more specific > > > policy. The objective being to specify policies such as: > > > > > > example.com DKIM "ALL mail is signed" > > > **.example.com DKIM "No mail is originated" > > > > Ok, your problem statement makes total sense to me, but I > > think you're missing a third option. I'm assuming that the > > DKIM protocol has a way to handle total absence of a policy > > for a domain. So, what if you added a heuristic to the DKIM > > protocol that says, "If I do not find a policy at this node, > > I will go down the tree until I either find a policy, or hit the TLD." > > It's the heuristic that gives me the heebeejeebees of the screaming variety. E > ither you walk the tree and allow attackers to stick you with 60 lookups or yo > u add in some constraints and you change the semantics of the DNS delegation a > s Olafur pointed out in the meeting. > > If you walk the tree you allow upper level domains to control the email sendin > g policy of lower domains even if that lower domain thinks that it has full co > ntrol because it has a delegation. Debugging problems could well get ugly, eve > n more so if you are running split DNS. Given you only want to trust signed and validated answers. The signatures themselves define the search range. If you don't want to limit answers to signed zones only you seach for the zone cut in parallel to looking for the records. > > In regards to your problem of spammers that try sending mail > > from 1.2.3.4..99.spammer-domain.tld, if the spammers have > > control over that domain and can add a node at that point, it > > will eat up resources to walk that tree, no doubt. OTOH, if > > they are playing silly buggers with a domain they don't have > > control over, I assume DKIM is smart enough to say that if > > there are NO records at all for a node, that it isn't > > legitimate? > > A lot of mail originates from addresses that are not externally visible due to > split DNS and the use of DNS wildcard MX records. > > The problem with the heuristic is that it results in yet another set of semant > ics to deal with and possibly end up with conflicts. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 22:50:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6IQY-0003W3-E5 for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 22:50:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6IQX-0000Gy-2u for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 22:50:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6INH-000HgV-HH for namedroppers-data@psg.com; Fri, 28 Jul 2006 02:46:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6ING-000Hg8-Fq for namedroppers@ops.ietf.org; Fri, 28 Jul 2006 02:46:50 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k6S2kXIa021196; Thu, 27 Jul 2006 22:46:34 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Thu, 27 Jul 2006 22:46:36 -0400 To: From: Edward Lewis Subject: RE: a suggestion for super-wildcards Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 A couple of points from a couple of messages, perhaps not all that important: At 12:38 PM -0700 7/26/06, Hallam-Baker, Phillip wrote: >The point here is that a wildcard only ever appears on the wire in a DNS >protocol exchange in two cases: > >1) During a zone transfer >2) If DNSSEC is in use With DNSSEC the wildcard isn't on the wire, but you can tell if it's been used. (The label count in the signature record.) Also, the wildcard could be seen when it is queried for. Neither of those points matter much though. >If neither of these features existed there would be no reason for wildcards to >be mentioned in the DNS spec at all. They would be a server configuration >feature, no more. It would not matter how the wildcards were defined, there >would be no interoperability issue. Wildcards are defined in sections 4.3.2 and then 4.3.3 in RFC 1034, which are sections on the algorithm that a server follows to generate an answer. I don't recall that 1034/1035 connects wildcards and zone transfers - that linkage didn't come up until a thread by Dan Bernstein on the wcard draft. See: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01702.html, note the "tone" of a thrown in idea at the end of the message. I think the zone transfer-wild card linkage came from that message. Wildcards are a minimal case of answer synthesis. The interop problem is getting all the servers to act the same way for a zone. If they (the old dudes) couldn't have shoehorned it into AXFR, then you'd have seen some other signalling mechanism in place. (As Dan said - rsync.) >1) This mail domain originates no mail. >2) All mail that this domain originates is signed. For clarification, what's the difference between a mail domain and a DNS domain? >Checking every node for a policy record is not acceptable. This is made worse >when you use a prefix convention (similar to SRV) as you can't even use a >traditional wildcard. There was some HTTP cookie policy talk given in Montreal that concluded the same thing. They (too) found that you can't tie meaning to the label depth of a zone. E.g., ietf.org is less of a "TLD" than 198.in-addr.arpa. At 9:58 AM +1000 7/27/06, Mark Andrews wrote: > Why is the policy in the DNS in the first place? 'Cuz it's convenient. You can drive a screw with a hammer if you try hard enough. I don't mean to slam DKIM over this, it seems all the rage these days. (I think I ranted on this recently.) > It keeps looking less and less like a good fit. BSD Sockets are a bad fit too. But we've made do all these years. (They [other old guys] thought that the interface to the file system was more general than the interface to the network and not vice versa. Oops.) There are better fits out there - IRIS or maybe LDAP/X.500. But would you want an operator to have to maintain that too? Or have IRIS or LDAP/X.500 being fudged into NAT devices too? Don't make those protocols suffer DNS' fate. Making the data available is only half the problem. Mail/SMTP has to deal with the fact that it is historically promiscuous - the absence of policy isn't clearly a devious mail domain, it could be just a little innocent old mail domain that hasn't kept up. This is something the DNS hammer can't overcome. At 11:26 PM -0700 7/26/06, Doug Barton wrote: > If you're never wrong, you're not trying hard enough I don't have to try hard to be wrong. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 27 23:48:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6JLF-0007hw-5F for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 23:48:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6JLC-0006B3-RL for dnsext-archive@lists.ietf.org; Thu, 27 Jul 2006 23:48:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6JIR-000OE0-5A for namedroppers-data@psg.com; Fri, 28 Jul 2006 03:45:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6JIQ-000ODh-Az for namedroppers@ops.ietf.org; Fri, 28 Jul 2006 03:45:54 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id C897856876; Thu, 27 Jul 2006 20:45:52 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060727232756.03c84d58@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 27 Jul 2006 23:45:53 -0400 To: "Scott Rose" ,"DNSEXT WG" From: Mike StJohns Subject: RE: 3 comments on timers-03 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 After further thought on this, I believe the current approach is the less problematic approach. The corner case Robert cites is at least one of the reasons I designed the system as is - under the "missing (eventually) equals revoked" scenario, if a rogue anchor can become trusted, then possession of the rogue key is may be sufficient to delete all the other trust anchors. (There's a whole load of timing things and keeping the resolver from seeing contrary data, but the deletion is at least possible.) Mike At 02:40 PM 7/27/2006, Scott Rose wrote: > > -----Original Message----- > > From: Robert Story [mailto:rstory@sparta.com] > > Sent: Wednesday, July 26, 2006 7:11 PM > > MS> > > MS> You definitely don't want to delete a trust anchor from a set just > > MS> because it's missing once. > > > > Isn't this exactly the attack vector described in the first > > paragraph of section 2.1? > > > > The corner case that bugs me with the timers draft is if an > > attacker manages to get a new key into a published DNSKEY RRSet and it > > goes unnoticed for the add hold-down period. Resolvers will consider it > > a valid trust anchor. When the operator notices this and re-publishes, > > they can omit the bad key, but not revoke it. Resolvers that have > > the bad key will continue to trust it until the remove hold-down timer > > expires. > > > >Maybe, but that is a corner case. After thinking about it some more, I >believe most cases where a "missing" trust anchor appears is when a zone >joins a chain of trust. That is, a zone decides to stop publishing their >own trust anchor and relies on a superior zone as the secure entry point. > >Instead of doing the correct revocation procedure, they only delete it, thus >producing the missing state in the resolver/validator. > >Scott > > > -- > > Robert Story > > SPARTA > > > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 28 12:48:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6VVw-0004QU-9b for dnsext-archive@lists.ietf.org; Fri, 28 Jul 2006 12:48:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6VVt-00034K-0x for dnsext-archive@lists.ietf.org; Fri, 28 Jul 2006 12:48:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6VS2-0000u0-7h for namedroppers-data@psg.com; Fri, 28 Jul 2006 16:44:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6VS1-0000tm-Bi for namedroppers@ops.ietf.org; Fri, 28 Jul 2006 16:44:37 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k6SGiYDs016168; Fri, 28 Jul 2006 09:44:34 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 09:44:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Fri, 28 Jul 2006 09:44:23 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: Acawx+/71v8sH2UqQnO1HlPtO7rlewBmwscA From: "Hallam-Baker, Phillip" To: "Roy Arends" , X-OriginalArrivalTime: 28 Jul 2006 16:44:34.0064 (UTC) FILETIME=[1AF98900:01C6B265] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca There are two parts to my proposal: 1) Define a 'wilder card' ** that matches a node if the result would = otherwise be NO-DATA and which acts on subdomains as well 2) The pointer mechanism. From a protocol point of view I think that we should do the first in any = case since it will ease the transition from non-compliant wildcards to = compliant wildcards when DNSSEC is in use. In particular many existing = DNS implementations already implement the ** semantics since this is = what administrators need to define MX records. Wildcards only ever appear on the wire in two cases - DNSSEC and Zone = transfers. It would certainly be nice if zone transfers were = interoperable but empirically this has not been considered a major = requirement.=20 DNSSEC is a more complex issue, if we were starting the design of DNSSEC = I would say we need both forms of wildcard. At this point I think that = it is clear that we need a macro processor. The expansion of the wild = cards must take place before the zone is signed. The main reason for defining the ** 'wildercard' in a document is that = there is a third important use which probably dominates the zone = transfer issue, people swap configuration information through email. One = of the nice things about DNS is that you can give someone a snippet of a = zone file and they can probably use it regardless of what platform they = use. The pointer mechanism does not need to be specified in the DNS protocol = unless we decide to revise the SRV specification. This mechanism is only = used the protocols that use the DNS for policy discovery. Regardless of = whether you think DNS policy distribution is a good or a bad thing, I = think it is clear that the discovery mechanism for finding out where to = find the policy has to be supported by the signalling infrastructure = that supports the name space in use. On the Internet that is the DNS, = not LDAP, not NIS, not X.500. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 28 17:14:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Zf7-0007dF-MC for dnsext-archive@lists.ietf.org; Fri, 28 Jul 2006 17:14:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Zf6-0004iu-7w for dnsext-archive@lists.ietf.org; Fri, 28 Jul 2006 17:14:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6ZZ5-0005Ml-In for namedroppers-data@psg.com; Fri, 28 Jul 2006 21:08:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6ZZ4-0005MZ-Hh for namedroppers@ops.ietf.org; Fri, 28 Jul 2006 21:08:10 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k6SL898s015096 for ; Fri, 28 Jul 2006 16:08:09 -0500 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k6SL88NH027081 for ; Fri, 28 Jul 2006 16:08:09 -0500 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 17:08:08 -0400 Received: from spx.vb.futz.org ([216.27.162.138]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 17:28:44 -0400 Date: Fri, 28 Jul 2006 17:07:59 -0400 From: Robert Story To: "DNSEXT WG" Subject: timers draft and parent DS records Organization: SPARTA X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_39na17bSP/f6mWoJ0CJtj0K"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-ID: X-OriginalArrivalTime: 28 Jul 2006 21:28:44.0562 (UTC) FILETIME=[CDDD0F20:01C6B28C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 --Sig_39na17bSP/f6mWoJ0CJtj0K Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Shouldn't the scenarios in section 5 include steps on updating parent DS records? The only discussion of updating parent DS records is in 4.3. Trust Point Deletion. It seems to me that when you roll a SEP key, you'd want to update the parent DS so resolvers which have a superior trust point configured would continue to validate the zone data. --=20 Robert Story SPARTA --Sig_39na17bSP/f6mWoJ0CJtj0K Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD4DBQFEyny17/fVLLY1mngRAjtWAJ9HlP+bmiVbhjsJQgc0C7z5SAHaiwCRAVyp lSlCNsjb/v9DAPneNOW21w== =p6cw -----END PGP SIGNATURE----- --Sig_39na17bSP/f6mWoJ0CJtj0K-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 30 16:29:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Hv8-0002BO-LS for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 16:29:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Hv8-0003iZ-5v for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 16:29:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7HqO-000E3a-Ri for namedroppers-data@psg.com; Sun, 30 Jul 2006 20:25:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=ADVANCE_FEE_1,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7HqN-000E3N-Op for namedroppers@ops.ietf.org; Sun, 30 Jul 2006 20:24:59 +0000 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k6UKOvpC032394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 30 Jul 2006 13:24:57 -0700 Subject: RE: a suggestion for super-wildcards From: Douglas Otis To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: <198A730C2044DE4A96749D13E167AD37BD6B0B@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain Date: Sun, 30 Jul 2006 13:24:55 -0700 Message-Id: <1154291095.21309.94.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 On Thu, 2006-07-27 at 22:46 -0400, Edward Lewis wrote: > At 12:38 PM -0700 7/26/06, Hallam-Baker, Phillip wrote: > > > The point here is that a wildcard only ever appears on the wire in a > > DNS protocol exchange in two cases: > > > > 1) During a zone transfer > > 2) If DNSSEC is in use > > With DNSSEC the wildcard isn't on the wire, but you can tell if it's > been used. (The label count in the signature record.) > > Also, the wildcard could be seen when it is queried for. > > Neither of those points matter much though. One may wonder about exposing zones when non-DNSSEC DNS utilize this scheme, or the related overhead associated with placing redirection RRs at every NSEC. > > If neither of these features existed there would be no reason for > > wildcards to be mentioned in the DNS spec at all. They would be a > > server configuration feature, no more. It would not matter how the > > wildcards were defined, there would be no interoperability issue. > > Wildcards are defined in sections 4.3.2 and then 4.3.3 in RFC 1034, > which are sections on the algorithm that a server follows to generate > an answer. I don't recall that 1034/1035 connects wildcards and zone > transfers - that linkage didn't come up until a thread by Dan > Bernstein on the wcard draft. > > See: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01702.html, > note the "tone" of a thrown in idea at the end of the message. I > think the zone transfer-wild card linkage came from that message. > > Wildcards are a minimal case of answer synthesis. The interop > problem is getting all the servers to act the same way for a zone. > If they (the old dudes) couldn't have shoehorned it into AXFR, then > you'd have seen some other signalling mechanism in place. (As Dan > said - rsync.) > > > 1) This mail domain originates no mail. > > 2) All mail that this domain originates is signed. > > For clarification, what's the difference between a mail domain and a > DNS domain? As currently defined by DKIM, a mail-domain extends to all subdomains irrespective of delegation. Policy is to be acquired for an email-address's domain when there is not a DKIM signature, or when there is a DKIM signature by a different parent domain. > > Checking every node for a policy record is not acceptable. This is > > made worse when you use a prefix convention (similar to SRV) as you > > can't even use a traditional wildcard. > > There was some HTTP cookie policy talk given in Montreal that > concluded the same thing. They (too) found that you can't tie > meaning to the label depth of a zone. E.g., ietf.org is less of a > "TLD" than 198.in-addr.arpa. The prefix technique used for the new "super" wildcard scheme overcomes issues at delegation points, but then a few new problems are created. As a confluence of RRs become placed within this common location, and their use evolves, it will not be possible to determine which RR types exist within this location without querying for RR types separately. Back to hunting. This hunting could be ameliorated by also listing the RR types found within this common node, in addition to the location of the common node within a new RR type (rather than reusing the PTR RR). In addition, the new RR type, rather than a convention for a "**" label, could trigger the desired behavior for the RR type. _policy IN PWCARD _policy IN POLICY-X blah, blah, blah _policy IN POLICY-Y blah, blah, blah ... Script or a server embedded function could then place at every node: * IN PWCARD <> Transfers might be able to determine whether these wildcard PWCARD RR types need to be transferred or whether they will be synthesized. For the newer version of DNS, any query for _policy would return the results 'as-if' there was a wildcard _policy.*. for all the policy RRs located at "this location". > > At 9:58 AM +1000 7/27/06, Mark Andrews wrote: > > Why is the policy in the DNS in the first place? > > 'Cuz it's convenient. You can drive a screw with a hammer if you try > hard enough. I don't mean to slam DKIM over this, it seems all the > rage these days. (I think I ranted on this recently.) Actually, this approach may not be all that convenient. There is also a desire to list designated signing domains. When your offices uses DKIM, a means to improve acceptance of your message could be to designate this work domain's signature for your private email domain. For a small outfit, this might mean designating their provider's and sub-contractor's domains. To allow for a small answer, one approach for creating this list would be to have a query of: ._dkim-p. The records could then be: *._dkim-p IN DKIM-P " & non-designated" work-domain._dkim-p IN DKIM-P " & non-designated" *.isp-domain._dkim-p IN DKIM-P "<*.isp-domain> & non-designated" How would this work when the prefixed wildcard scheme requires that a query for the prefixed record be made for the DKIM-P RR, followed by a query for the PWCARD RR, and then followed by a query for the DKIM-P RR at the redirected location? To obtain the Designated Signing Domains, yet another query is required. This has not substantially reduced the number of queries when a convention also requires that policy be established within 4 levels below the TLD. > Making the data available is only half the problem. Mail/SMTP has to > deal with the fact that it is historically promiscuous - the absence > of policy isn't clearly a devious mail domain, it could be just a > little innocent old mail domain that hasn't kept up. This is > something the DNS hammer can't overcome. Agreed. Few will search for policy. Policy would be required for every non-signed message and every message signed by a domain that does not correspond to that of the email-address. 5 additional transactions is not very reasonable. Few will want their providers to prohibit use of their desired email-address. DKIM deals with concerns related to who should handle abuse issues and whether a message from a list of financial domains is a phishing attempt. Frankly, neither of these expected uses requires that policy be retrieved. To thwart display-names only being visible, look-alikes, and international domains, anti-phishing requires that the message be annotated as being signed by a trusted domain. (Perhaps a domain found in the address book or a correspondence log.) Fortunately neither of these uses when properly implemented requires that a policy record be retrieved. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 30 18:14:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7JY0-0003df-9A for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 18:14:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7JXy-0002oA-RI for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 18:14:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7JVO-000Q0I-W0 for namedroppers-data@psg.com; Sun, 30 Jul 2006 22:11:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7JVO-000Pzw-AV for namedroppers@ops.ietf.org; Sun, 30 Jul 2006 22:11:26 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 5FDD456876; Sun, 30 Jul 2006 15:11:25 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060730180330.03a082b8@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 30 Jul 2006 18:11:25 -0400 To: Robert Story ,"DNSEXT WG" From: Mike StJohns Subject: Re: timers draft and parent DS records In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a No, it shouldn't include that. Section 4.3 describes deleting a trust point. Once you've done that, you're no longer going to do anchor update for the trust points. So if you want to keep validating the zone, of course you need to update/create a DS record at the parent. Section 5 describes what you do with an active trust point. It's possible there is a superior DS and superior trust anchor, but if that's the case, why have that subordinate trust point? Section 5 describes the actions at the trust point to roll or update keys. The actions your parent requires you to take may or may not include updating the DS record - and most of the time there won't actually be a DS record. At 05:07 PM 7/28/2006, Robert Story wrote: >Shouldn't the scenarios in section 5 include steps on updating parent >DS records? The only discussion of updating parent DS records is in >4.3. Trust Point Deletion. It seems to me that when you roll a SEP key, >you'd want to update the parent DS so resolvers which have a superior >trust point configured would continue to validate the zone data. > >-- >Robert Story >SPARTA > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 30 19:06:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7KMG-0005xW-Ue for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 19:06:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7KME-0007wA-DU for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 19:06:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7KKF-0006hK-Qz for namedroppers-data@psg.com; Sun, 30 Jul 2006 23:03:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7KKD-0006h1-Oc for namedroppers@ops.ietf.org; Sun, 30 Jul 2006 23:03:57 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k6UN3sLI020124; Sun, 30 Jul 2006 18:03:54 -0500 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k6UN3sq7026421; Sun, 30 Jul 2006 18:03:54 -0500 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Jul 2006 19:03:54 -0400 Received: from spx.vb.futz.org ([67.191.171.138]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Jul 2006 19:24:35 -0400 Date: Sun, 30 Jul 2006 19:03:42 -0400 From: Robert Story To: Mike StJohns Cc: "DNSEXT WG" Subject: Re: timers draft and parent DS records In-Reply-To: <7.0.1.0.2.20060730180330.03a082b8@nominum.com> References: <7.0.1.0.2.20060730180330.03a082b8@nominum.com> Organization: SPARTA X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_urJWs62GCC=IwKwqagj562W"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-ID: X-OriginalArrivalTime: 30 Jul 2006 23:24:35.0625 (UTC) FILETIME=[51D89990:01C6B42F] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --Sig_urJWs62GCC=IwKwqagj562W Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 30 Jul 2006 18:11:25 -0400 Mike wrote: MS> Section 5 describes what you do with an active trust point. It's=20 MS> possible there is a superior DS and superior trust anchor, but if=20 MS> that's the case, why have that subordinate trust point? Maybe because the superior trust point is new, and not everybody has updated their resolver configuration. I've re-read 4.3 a few more times, and have a question. If a zone revokes all its trust anchors, and there is a superior trust anchor (which is not configured at a resolver), is the resolver supposed to save (and trust) the superior trust point? MS> Section 5=20 MS> describes the actions at the trust point to roll or update keys. The=20 MS> actions your parent requires you to take may or may not include=20 MS> updating the DS record - and most of the time there won't actually be=20 MS> a DS record. That will probably be true, initially. But as deployment grows, so will the number of trust points higher in the DNS tree. As that's happening, it will take time for resolver configurations to get updated. Unless 4.3 does mean there is auto-trust of superior trust points (which I don't particularly think is a good idea), care needs to be taken during the transition period. Also, I'm sure some domain owner's will continue to publish their own trust points even if there is a superior trust point. Just because they will be in the minority doesn't mean we should ignore them. Unless we want to rename the document "Automated Updates of DNSSEC Trust Anchors For Zones With No Available Superior Trust Points". --=20 Robert Story SPARTA --Sig_urJWs62GCC=IwKwqagj562W Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEzTrW7/fVLLY1mngRAqw/AKCDA0e8JngDnq9Rrk/LiNSDejgPewCbB66O iG3V534fb0H22hozFkSz5bU= =lZmp -----END PGP SIGNATURE----- --Sig_urJWs62GCC=IwKwqagj562W-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 30 19:33:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7KmY-0006CN-BY for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 19:33:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7KmX-00031n-P9 for dnsext-archive@lists.ietf.org; Sun, 30 Jul 2006 19:33:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7Kif-0009LE-DM for namedroppers-data@psg.com; Sun, 30 Jul 2006 23:29:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7Kid-0009J9-E5 for namedroppers@ops.ietf.org; Sun, 30 Jul 2006 23:29:11 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 875BD56836; Sun, 30 Jul 2006 16:29:09 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060730191213.040030c0@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 30 Jul 2006 19:29:09 -0400 To: Robert Story From: Mike StJohns Subject: Re: timers draft and parent DS records Cc: "DNSEXT WG" In-Reply-To: References: <7.0.1.0.2.20060730180330.03a082b8@nominum.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_272090154==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 --=====================_272090154==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:03 PM 7/30/2006, Robert Story wrote: >On Sun, 30 Jul 2006 18:11:25 -0400 Mike wrote: >MS> Section 5 describes what you do with an active trust point. It's >MS> possible there is a superior DS and superior trust anchor, but if >MS> that's the case, why have that subordinate trust point? > >Maybe because the superior trust point is new, and not everybody has >updated their resolver configuration. This is not in scope for this document. 4.3 talks about deleting a trust point and the ramifications. Section 5 talks about the normal operations for a trust point - regardless of whether there are superior trust anchors. Refer to the normal DNSSEC documents for how to deal with DS records etc. I don't need to and will not repeat DS management discussions in this ID. >I've re-read 4.3 a few more times, and have a question. If a zone >revokes all its trust anchors, and there is a superior trust anchor >(which is not configured at a resolver), is the resolver supposed to >save (and trust) the superior trust point? No and HUH? This is a meaningless question. If a resolver deletes all the trust anchors associated with a zone and there are no trusted superiors, the zone goes to the insecure state - it may be signed, but there's no way for the resolver to know whether or not the zone should be signed (the same state as almost all of the DNS tree today). The only way a trust point gets created is manually (by setting a trust anchor for a specific location) or some other method (not defined here or as far as I can tell elsewhere). The text that covers the above is: " If there are no superior trust points, data at and below the deleted trust point are considered insecure. If there ARE superior trust points, data at and below the deleted trust point are evaluated with respect to the superior trust point." The trust anchor runs from parent to child, not vice versa. Trusting a child does not in any way allow you to trust the parent. >MS> Section 5 >MS> describes the actions at the trust point to roll or update keys. The >MS> actions your parent requires you to take may or may not include >MS> updating the DS record - and most of the time there won't actually be >MS> a DS record. > >That will probably be true, initially. But as deployment grows, so will >the number of trust points higher in the DNS tree. As that's happening, >it will take time for resolver configurations to get updated. Unless >4.3 does mean there is auto-trust of superior trust points (which I >don't particularly think is a good idea), care needs to be taken during >the transition period. Umm.. how in any reading of the text could you get that 4.3 implies that you auto-trust a superior? I think you're way off in the weeds here. >Also, I'm sure some domain owner's will continue to publish their own >trust points even if there is a superior trust point. Just because they >will be in the minority doesn't mean we should ignore them. Unless we >want to rename the document "Automated Updates of DNSSEC Trust Anchors >For Zones With No Available Superior Trust Points". You're setting up strawmen and trying to knock them down. I'm not sure why you're doing that. There is nothing in 4.3 (or for that matter, anywhere else in the document) that prohibits trust points superior or subordinate to other trust points. 4.3 simply describes a method to automatically inform resolvers that you want them all to delete a configured trust point. --=====================_272090154==.ALT Content-Type: text/html; charset="us-ascii" At 07:03 PM 7/30/2006, Robert Story wrote:
On Sun, 30 Jul 2006 18:11:25 -0400 Mike wrote:
MS> Section 5 describes what you do with an active trust point.  It's
MS> possible there is a superior DS and superior trust anchor, but if
MS> that's the case, why have that subordinate trust point?

Maybe because the superior trust point is new, and not everybody has
updated their resolver configuration.

This is not in scope for this document.  4.3 talks about deleting a trust point and the ramifications.  Section 5 talks about the normal operations for a trust point - regardless of whether there are superior trust anchors.  Refer to the normal DNSSEC documents for how to deal with DS records etc.  I don't need to and will not repeat DS management discussions in this ID.

I've re-read 4.3 a few more times, and have a question. If a zone
revokes all its trust anchors, and there is a superior trust anchor
(which is not configured at a resolver), is the resolver supposed to
save (and trust) the superior trust point?

No and HUH? This is a meaningless question.

If a resolver deletes all the trust anchors associated with a zone and there are no trusted superiors, the zone goes to the insecure state - it may be signed, but there's no way for the resolver to know whether or not the zone should be signed (the same state as almost all of the DNS tree today).  The only way a trust point gets created is manually  (by setting a trust anchor for a specific location) or some other method (not defined here or as far as I can tell elsewhere). 

The text that covers the above is: "
If there are no superior trust points, data at and below
   the deleted trust point are considered insecure.  If
there ARE
   superior trust points, data at and below the deleted trust
point are
evaluated with respect to the superior trust point."
The trust anchor runs from parent to child, not vice versa.  Trusting a child does not in any way allow you to trust the parent.
MS>  Section 5
MS> describes the actions at the trust point to roll or update keys.  The
MS> actions your parent requires you to take may or may not include
MS> updating the DS record - and most of the time there won't actually be
MS> a DS record.

That will probably be true, initially. But as deployment grows, so will
the number of trust points higher in the DNS tree. As that's happening,
it will take time for resolver configurations to get updated. Unless
4.3 does mean there is auto-trust of superior trust points (which I
don't particularly think is a good idea), care needs to be taken during
the transition period.

Umm.. how in any reading of the text could you get that 4.3 implies that you auto-trust a superior?  I think you're way off in the weeds here. 

Also, I'm sure some domain owner's will continue to publish their own
trust points even if there is a superior trust point. Just because they
will be in the minority doesn't mean we should ignore them. Unless we
want to rename the document "Automated Updates of DNSSEC Trust Anchors
For Zones With No Available Superior Trust Points".

You're setting up strawmen and trying to knock them down.  I'm not sure why you're doing that.

There is nothing in 4.3 (or for that matter, anywhere else in the document) that prohibits trust points superior or subordinate to other trust points.  4.3 simply describes a method to automatically inform resolvers that you want them all to delete a configured trust point.

--=====================_272090154==.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 06:17:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Upz-0007Ga-Tl for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 06:17:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Upw-0006pl-GS for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 06:17:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7Uln-00001g-0E for namedroppers-data@psg.com; Mon, 31 Jul 2006 10:13:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7Ull-000Q0U-Mr for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 10:13:05 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id E1D7626C15B; Mon, 31 Jul 2006 12:13:04 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id B04B326C038; Mon, 31 Jul 2006 12:13:03 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id ADB30A1D942; Mon, 31 Jul 2006 12:13:03 +0200 (CEST) Date: Mon, 31 Jul 2006 12:13:03 +0200 From: Stephane Bortzmeyer To: "Hallam-Baker, Phillip" Cc: Roy Arends , namedroppers@ops.ietf.org Subject: DNS zone file format (Was: a suggestion for super-wildcards Message-ID: <20060731101303.GA16547@nic.fr> References: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Fri, Jul 28, 2006 at 09:44:23AM -0700, Hallam-Baker, Phillip wrote a message of 29 lines which said: > One of the nice things about DNS is that you can give someone a > snippet of a zone file and they can probably use it regardless of > what platform they use. First, this is far from true. If people use djbware or PowerDNS (or, probably, MS-Windows pointandclickware), it does not work. Second, I'm not sure it is nice. Most of the RFCs do not specify file formats ("it would be nice if RFC 4271 specified a syntax for bogon filters"). IMHE (In My Humble Experience), the fact that there is a reference file format is useful, not for copy-and-paste of zone files but when discussing DNS data with people: most DNS experts can read that format. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 07:25:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Vu0-0005RL-Le for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 07:25:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Vtx-0002UX-1X for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 07:25:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7Vr2-0008Ng-UK for namedroppers-data@psg.com; Mon, 31 Jul 2006 11:22:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7Vr0-0008NL-Qm for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 11:22:35 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 534A14568; Mon, 31 Jul 2006 13:22:15 +0200 (CEST) Date: Mon, 31 Jul 2006 13:22:15 +0200 From: bert hubert To: Stephane Bortzmeyer Cc: "Hallam-Baker, Phillip" , Roy Arends , namedroppers@ops.ietf.org Subject: Re: DNS zone file format (Was: a suggestion for super-wildcards Message-ID: <20060731112214.GA29514@outpost.ds9a.nl> References: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> <20060731101303.GA16547@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060731101303.GA16547@nic.fr> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 On Mon, Jul 31, 2006 at 12:13:03PM +0200, Stephane Bortzmeyer wrote: > > One of the nice things about DNS is that you can give someone a > > snippet of a zone file and they can probably use it regardless of > > what platform they use. > > First, this is far from true. If people use djbware or PowerDNS (or, > probably, MS-Windows pointandclickware), it does not work. Both PowerDNS and Microsoft DNS read zone files just fine, but can also read other formats. It must however be said that in my experience, the DNS zone format is one of the worst formats to parse. /** this parser handles 10 cases (sigh) 1) qname TTL CLASS QTYPE * 2) qname CLASS TTL QTYPE * 3) qname CLASS QTYPE * 4) qname TTL QTYPE * 5) qname QTYPE * And then everything again with a space first character, which implies 'same as last name' */ This combined with the "(" line extension, @, the various $include, $generate, $ttl commands and so forth make it a horrible format. We've worked very hard to make PowerDNS parse each file BIND can parse, and BIND is in fact the only standard available. Lots of things are ambiguous about the zone format otherwise. And still we have irregularities, for example, what happens when you $include a file in another directory, and somebody $includes something again, which is the 'current working directory' to resolve relative paths? etc. But yes, most people here can read the simple cases just fine. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 11:04:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZJp-0007yX-Hg for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 11:04:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ZJn-0003A6-2v for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 11:04:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7ZFP-00072g-1M for namedroppers-data@psg.com; Mon, 31 Jul 2006 14:59:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7ZFN-00072N-Lm for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 14:59:57 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k6VExrec016871 for ; Mon, 31 Jul 2006 09:59:55 -0500 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k6VExqmu009186 for ; Mon, 31 Jul 2006 09:59:53 -0500 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 10:59:51 -0400 Received: from spx.vb.futz.org ([216.27.162.138]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 11:20:34 -0400 Date: Mon, 31 Jul 2006 10:59:42 -0400 From: Robert Story Cc: "DNSEXT WG" Subject: Re: timers draft and parent DS records In-Reply-To: <7.0.1.0.2.20060730191213.040030c0@nominum.com> References: <7.0.1.0.2.20060730180330.03a082b8@nominum.com> <7.0.1.0.2.20060730191213.040030c0@nominum.com> Organization: SPARTA X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_tsHZaK/L0F7aUlzoDuBQJG5"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-ID: X-OriginalArrivalTime: 31 Jul 2006 15:20:34.0781 (UTC) FILETIME=[DE9138D0:01C6B4B4] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 --Sig_tsHZaK/L0F7aUlzoDuBQJG5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote: MS> Umm.. how in any reading of the text could you get that 4.3 implies=20 MS> that you auto-trust a superior? I think you're way off in the weeds he= re. I was indeed wandering in the weeds, and my question was just to make sure. As to how I got there: I do not see any such implication, but after re-reading it several times, I noticed that while later paragraphs talked about 'configured' trust points, the first paragraph only says "If there ARE superior trust points". I suggest adding the word c= onfigured in the first paragraph as well. Now, on to my main point, which got lost in the confusion. Deleting the reference to 4.3 from my original message: At 05:07 PM 7/28/2006, Robert Story wrote: >Shouldn't the scenarios in section 5 include steps on updating parent >DS records? [...] It seems to me that when you roll a SEP key, >you'd want to update the parent DS so resolvers which have a superior >trust point configured would continue to validate the zone data. And the eventual response: On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote: MS> This is not in scope for this document. [...] Section 5 talks about the MS> normal operations for a trust point - regardless of whether there are=20 MS> superior trust anchors. Refer to the normal DNSSEC documents for how=20 MS> to deal with DS records etc. I don't need to and will not repeat DS=20 MS> management discussions in this ID. With all due respect, I disagree. If you don't want to added anything to the individual scenarios, I think there should at least be a few words about it in the introduction of section 5 (suggested text included at the bottom of this message). While this document is primarily about resolvers, it also specifies procedure for zone administrators (sections 5 and part of 4.3). Zone administrators must add/revoke/remove keys in the proscribed manner for resolvers to automatically update their trust anchors. Given that we are describing the rollover procedure for zone administrators, I think we need to at least mention the potential pitfall when the parent zone is signed. As requested, I'm including some suggested text, which I think should be added after the 2nd paragraph of section 5: N.B. The steps outlined below assume an unsigned parent zone. When keys are added, revoked or removed from a zone with a signed parent, the parent zone should be notified so that DS record(s) can be updated appropriately. Failure to do so will prevent resolvers which only have a superior trust point configured from securely resolving the subordinate zone. --=20 Robert Story SPARTA --Sig_tsHZaK/L0F7aUlzoDuBQJG5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEzhrk7/fVLLY1mngRAjtfAJ9RzRrBfCcVS0SsnyswO3p+MrjhNACeKHsB KcTgjAOXqp7ik4mhUFZQ120= =TLkZ -----END PGP SIGNATURE----- --Sig_tsHZaK/L0F7aUlzoDuBQJG5-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 13:37:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7bi9-0002W7-AO for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 13:37:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7bi7-0008EI-KR for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 13:37:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7beg-000OCr-Mj for namedroppers-data@psg.com; Mon, 31 Jul 2006 17:34:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [198.144.196.2] (helo=laser.networkresonance.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7bef-000OCV-Fo for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 17:34:13 +0000 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id A9922222425 for ; Mon, 31 Jul 2006 10:42:15 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Comments on dr X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Mon, 31 Jul 2006 10:34:12 -0700 From: Eric Rescorla Message-Id: <20060731174215.A9922222425@laser.networkresonance.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This draft uses a variant of the two-key strategy: a given island can have an arbitrary number of keys. The draft (S 5) suggests having two keys, an "active" key and a "stand-by" key, but this isn't wired into the protocol. This differs from the two-tier model discussed above in two respects: 1. From the perspective of the relying party, all keys have the same security level. Any key can be used to sign a new key, allowing automatic rollover in non-compromise cases. However, keys cannot revoke other keys--to revoke a key you produce a self-signed revocation. 2. When you roll-over, you make the previous stand-by key the active key. The advantage of this scheme is that it can survive compromise of either key. The disadvantage is that it encourages having two keys with roughly similar security levels, thus making compromise of the stand-by key more likely. In particular, if you intend for the stand-by key to become the active key, then even if you initially store it in a high security module, you need some mechanism for releasing it which represents a potential attack vector. If you simply always treat the standby key as a key-signing-key then this problem goes away and while this is permitted by this draft, it seems like this would be good guidance. A second issue is that because you need access to any given key in order to revoke it, you are more vulnerable to attacks where the active key private key is destroyed (e.g., an attacker steals it and then erases the disk) and this is a higher risk because the active key is used frequently. You would not be able to revoke the key in such cases. I don't know if it's possible to produce a pre-signed revocation as discussed in [1], but it would presumably be advisable in this instance. Note that you can always remove it from the RRSET but this doesn't provide an authenticated removal, right? Also, what do you do if you lose all your keys...? So, in general, I think it's a mistake to have a system where you assume that both keys are about equally likely to be compromised. Certainly, if you're worried about a computational attack and the keys are the same length, then any sane attacker will break all the keys before tipping his hand (this is a constant factor). And once you have asymmetric lengths, then it's unattractive to use them identically. If this is the direction the WG wants to go in, I think it would be appropriate to discuss what threat model motivates it. -Ekr [1] Note that it's possible to design a system like this where the high-assurance key can be revoked but not reprovisioned automatically. For instance, you pre-sign a self-revocation for the high-assurance key which you then release in the case of compromise. There's also Micali's trick of having the high-assurance cert contain a digest of some secret random value X (i.e., H(X).. To revoke the key you release X and everyone can verify X. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 14:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cP1-0002sr-Cc for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 14:22:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cP0-00035a-41 for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 14:22:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7cM9-0004pd-Bn for namedroppers-data@psg.com; Mon, 31 Jul 2006 18:19:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [198.144.196.2] (helo=laser.networkresonance.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7cM8-0004pR-Kk for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 18:19:08 +0000 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id D51EC222425 for ; Mon, 31 Jul 2006 11:27:10 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Re: Comments on dr In-reply-to: Your message of "Mon, 31 Jul 2006 10:34:12 PDT." <20060731174215.A9922222425@laser.networkresonance.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Mon, 31 Jul 2006 11:19:08 -0700 From: Eric Rescorla Message-Id: <20060731182710.D51EC222425@laser.networkresonance.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad The subject here should refer to: draft-ietf-dnsext-trustupdate-timers I read -02 but on quick skim -03 looks architecturally pretty similar. -Ekr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 18:18:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7g60-0000UR-Hd for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:18:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7g5z-00031v-1B for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:18:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7g13-0007SU-1V for namedroppers-data@psg.com; Mon, 31 Jul 2006 22:13:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [204.14.89.7] (helo=mail2.fluidhosting.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7g11-0007S5-Od for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 22:13:35 +0000 Received: (qmail 4075 invoked by uid 399); 31 Jul 2006 22:13:34 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 31 Jul 2006 22:13:34 -0000 Message-ID: <44CE808B.3030005@dougbarton.us> Date: Mon, 31 Jul 2006 15:13:31 -0700 From: Doug Barton User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: Roy Arends , namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards References: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 I'm going to combine your two responses and snip, FYI. Hallam-Baker, Phillip wrote: >> From: Doug Barton [mailto:dougb@dougbarton.us] > >> On the one hand, because I have in the past wanted something similar to >> what you're proposing, the theoretical concept of these super wildcards >> is appealing. However, from a protocol standpoint the idea gives me a >> serious case of the screaming heebeejeebees. > > Screaming? Yeah, and they are getting worse. >> So, I have a question ... >> >> Hallam-Baker, Phillip wrote: > >>> So the problem with policy is how to declare an email >> signing policy >>> for **.example.com that takes effect if there is no more specific >>> policy. The objective being to specify policies such as: >>> >>> example.com DKIM "ALL mail is signed" **.example.com DKIM "No >>> mail is originated" >> Ok, your problem statement makes total sense to me, but I think you're >> missing a third option. I'm assuming that the DKIM protocol has a way >> to handle total absence of a policy for a domain. So, what if you added >> a heuristic to the DKIM protocol that says, "If I do not find a policy >> at this node, I will go down the tree until I either find a policy, or >> hit the TLD." > > It's the heuristic that gives me the heebeejeebees of the screaming variety. Either you walk the tree and allow attackers to stick you with 60 lookups or you add in some constraints and you change the semantics of the DNS delegation as Olafur pointed out in the meeting. I wasn't sure I really understood what you were asking for here when I first read this. Now that you've clarified it further, I am sure I don't like it. There is an enormous difference between a super-wildcard that synthesizes a response for something that doesn't exist, and one that _overrides_ the records in a child domain. (BTW, I have a hard time following your use of "upper" and "lower," you might want to stick with the DNS terms of art "parent" and "child.") I could muster up support for a good implementation of the former, but I cannot imagine a scenario where I would support the latter. Changing "the semantics of the DNS delegation" as you describe is too revolutionary a change in my mind. Not only because it breaks with the entire tradition of the deployed DNS (and therefore loses on POLA grounds alone), but also because I can see this type of record leading to nightmare debugging problems with anything other than very simple delegations. This is the kind of problem that needs to be solved at layer 8, where the parent zone administrator makes the requirement of proper DKIM records a condition of receiving the delegation, and if that policy is breached, they pull the delegation. I am sure that other solutions are possible that do not entail radically changing "the semantics of the DNS delegation." Although it has its own drawbacks, e-mail headers could be used to specify where to find the DKIM policy, for example. Also, Mark gave you a really good answer on this point, which TMK you did not respond to. I would really like to see an explanation of why what Mark suggested doesn't help, or isn't suitable. > If you walk the tree you allow upper level domains to control the email sending policy of lower domains even if that lower domain thinks that it has full control because it has a delegation. Debugging problems could well get ugly, even more so if you are running split DNS. I'm not sure what set of problems you're concerned with here, but my concern is for the debugging nightmare that these super-wildcards you propose would cause for DNS in general, not specifically related to the DKIM case. >> In regards to your problem of spammers that try sending mail from >> 1.2.3.4..99.spammer-domain.tld, if the spammers have control over that >> domain and can add a node at that point, it will eat up resources to >> walk that tree, no doubt. OTOH, if they are playing silly buggers with >> a domain they don't have control over, I assume DKIM is smart enough to >> say that if there are NO records at all for a node, that it isn't >> legitimate? > > A lot of mail originates from addresses that are not externally visible due to split DNS and the use of DNS wildcard MX records. If I understand what you're saying here correctly, I would suggest that this is an error in any case. If you're sending me mail with the expectation that I should be able to reply to it, then I need an address to reply to that is visible in my view of the DNS. If your From: address isn't visible to me in DNS, the message is probably spam anyways. > The problem with the heuristic is that it results in yet another set of semantics to deal with and possibly end up with conflicts. If I understand you correctly, the conflicts you are concerned about result from your premise that child domains should not be able to set a DKIM policy that is different from that of their parent(s). I would suggest that this is a problem that should be resolved within DKIM (and at layer 8, as above), without trying to hijack the DNS to solve it for you. Hallam-Baker, Phillip wrote: > There are two parts to my proposal: > > 1) Define a 'wilder card' ** that matches a node if the result would > otherwise be NO-DATA and which acts on subdomains as well As I said above, I do not support the latter in the way that you are proposing it. > From a protocol point of view I think that we should do the first in any > case since it will ease the transition from non-compliant wildcards to > compliant wildcards when DNSSEC is in use. Can you please flesh this out a bit, preferably with examples? > In particular many existing > DNS implementations already implement the ** semantics since this is what > administrators need to define MX records. Once again, can you give examples, preferably with reference to documentation? > Wildcards only ever appear on the wire in two cases - DNSSEC and Zone > transfers. It would certainly be nice if zone transfers were > interoperable but empirically this has not been considered a major > requirement. On this I must (sadly) agree with you. I think that this ship has probably sailed without us. > The main reason for defining the ** 'wildercard' in a document is that > there is a third important use which probably dominates the zone transfer > issue, people swap configuration information through email. One of the > nice things about DNS is that you can give someone a snippet of a zone > file and they can probably use it regardless of what platform they use. As others have said, this argument seems specious to me. > Regardless of whether you think DNS policy distribution is a good or a > bad thing, I think it is clear that the discovery mechanism for finding > out where to find the policy has to be supported by the signalling > infrastructure that supports the name space in use. On the Internet that > is the DNS, not LDAP, not NIS, not X.500. So, we have to support it whether we think it's a good idea or not? (And no, you don't get any points for trying to make a meta-distinction between policy discovery and policy discovery discovery.) In short, I've tried to understand what you are proposing and why, and I do not think that the benefits of your proposal outweigh the costs. FWIW, Doug -- If you're never wrong, you're not trying hard enough -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 18:46:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gX9-0005Jg-Kh for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:46:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gX9-0006Ik-3j for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:46:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7gUc-000Bux-Ke for namedroppers-data@psg.com; Mon, 31 Jul 2006 22:44:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7gUZ-000Bub-Pm for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 22:44:07 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k6VMi1wL008320; Mon, 31 Jul 2006 15:44:01 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 15:44:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Mon, 31 Jul 2006 15:43:47 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37C6657B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: Aca07pTnLs2SQt1zQHWwz69W8UVRQAAAMMXA From: "Hallam-Baker, Phillip" To: "Doug Barton" Cc: "Roy Arends" , X-OriginalArrivalTime: 31 Jul 2006 22:44:01.0329 (UTC) FILETIME=[D14E4210:01C6B4F2] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c > From: Doug Barton [mailto:dougb@dougbarton.us]=20 > Yeah, and they are getting worse. Fortunately you are reading the description of the alternative. > > It's the heuristic that gives me the heebeejeebees of the screaming > variety. Either you walk the tree and allow attackers to=20 > stick you with 60 lookups or you add in some constraints and=20 > you change the semantics of the DNS delegation as Olafur=20 > pointed out in the meeting. >=20 > I wasn't sure I really understood what you were asking for=20 > here when I first read this. Now that you've clarified it=20 > further, I am sure I don't like it. Me neither, the idea of super wildcards is to avoid the need to do this. > There is an enormous difference between a super-wildcard that=20 > synthesizes a response for something that doesn't exist, and=20 > one that _overrides_ the records in a child domain. (BTW, I=20 > have a hard time following your use of "upper" and "lower,"=20 > you might want to stick with the DNS terms of art "parent"=20 > and "child.") I could muster up support for a good=20 > implementation of the former, but I cannot imagine a scenario=20 > where I would support the latter. What I want to see is the former. **.example.com would match responses where there is no record of a given = type at a node. If there is a record of the given type at the node it = always take precedence, if there is a closer wildcard match it also = takes precedence. I don't see this being different in principle to existing wildcards.=20 > Changing "the semantics of=20 > the DNS delegation" as you describe is too revolutionary a=20 > change in my mind. Not only because it breaks with the entire=20 > tradition of the deployed DNS (and therefore loses on POLA=20 > grounds alone), but also because I can see this type of=20 > record leading to nightmare debugging problems with anything=20 > other than very simple delegations. Hence my desire to avoid the need for the heuristic altogether.=20 The point to defining the ** wildcard is to make it clear that people do = not need to do this type of thing even though they may think they need = to. > This is the kind of problem that needs to be solved at layer=20 > 8, where the parent zone administrator makes the requirement=20 > of proper DKIM records a condition of receiving the=20 > delegation, and if that policy is breached, they pull the=20 > delegation. I am sure that other solutions are possible that=20 > do not entail radically changing "the semantics of the DNS=20 > delegation." Although it has its own drawbacks, e-mail=20 > headers could be used to specify where to find the DKIM=20 > policy, for example. That is pretty much what I would want to see. Not least because domain = delegation itself implies a pretty substantial handover of control. > Also, Mark gave you a really good answer on this point, which=20 > TMK you did not respond to. I would really like to see an=20 > explanation of why what Mark suggested doesn't help, or isn't=20 > suitable. Have not seen the post. > I'm not sure what set of problems you're concerned with here,=20 > but my concern is for the debugging nightmare that these=20 > super-wildcards you propose would cause for DNS in general,=20 > not specifically related to the DKIM case. Again, you have confused super wildcards with the description of the = hack around they are intended to avoid. There is no tree walking in my scheme, every lookup takes a maximum of = three queries. > > A lot of mail originates from addresses that are not externally=20 > > visible > due to split DNS and the use of DNS wildcard MX records. >=20 > If I understand what you're saying here correctly, I would=20 > suggest that this is an error in any case. If you're sending=20 > me mail with the expectation that I should be able to reply=20 > to it, then I need an address to reply to that is visible in=20 > my view of the DNS. If your From: address isn't visible to me=20 > in DNS, the message is probably spam anyways. The folk who have done the empirics on this disagree. > > The problem with the heuristic is that it results in yet=20 > another set=20 > > of > semantics to deal with and possibly end up with conflicts. >=20 > If I understand you correctly, the conflicts you are=20 > concerned about result from your premise that child domains=20 > should not be able to set a DKIM policy that is different=20 > from that of their parent(s).=20 No that is not the concern. Again, you are tilting at the wrong opponent = here. > Hallam-Baker, Phillip wrote: > > There are two parts to my proposal: > >=20 > > 1) Define a 'wilder card' ** that matches a node if the=20 > result would=20 > > otherwise be NO-DATA and which acts on subdomains as well >=20 > As I said above, I do not support the latter in the way that=20 > you are proposing it. >=20 > > From a protocol point of view I think that we should do the=20 > first in=20 > > any case since it will ease the transition from non-compliant=20 > > wildcards to compliant wildcards when DNSSEC is in use. >=20 > Can you please flesh this out a bit, preferably with examples? > > In particular many existing > > DNS implementations already implement the ** semantics=20 > since this is=20 > > what administrators need to define MX records. >=20 > Once again, can you give examples, preferably with reference=20 > to documentation? If you have the following nodes: a.example.com A 10.1.1.1 *.example.com MX 1 1 email.example.com The MX record does not match a.example.com because there is an a record = at the node. So if you want to direct all mail delivery to = email.example.com you have to add in explicit wildcards: a.example.com A 10.1.1.1 *.example.com MX 1 1 email.example.com a.example.com MX 1 1 email.example.com If you have fifty odd hosts this is a PITA. So some DNS servers actually = specify wildcard semantics that have a looser match. > > Regardless of whether you think DNS policy distribution is=20 > a good or a=20 > > bad thing, I think it is clear that the discovery mechanism for=20 > > finding out where to find the policy has to be supported by the=20 > > signalling infrastructure that supports the name space in=20 > use. On the=20 > > Internet that is the DNS, not LDAP, not NIS, not X.500. >=20 > So, we have to support it whether we think it's a good idea=20 > or not? (And no, you don't get any points for trying to make=20 > a meta-distinction between policy discovery and policy=20 > discovery discovery.) I think it is clear that the DNS will be the infrastructure chosen to = support this function. What do you mean by 'we have to support it'? The proposal is entirely = compatible with the legacy deployed infrastructure. The whole point is = not to need any support from DNS infrastructure providers. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 18:50:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gab-0007X7-0s for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:50:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gaZ-0006l9-NR for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:50:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7gZ9-000CRJ-5O for namedroppers-data@psg.com; Mon, 31 Jul 2006 22:48:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7gZ8-000CR6-Dt for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 22:48:50 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Mon, 31 Jul 2006 18:48:49 -0400 id 002CC091.44CE88D1.000059C7 Message-ID: <44CE88D1.3090205@verisignlabs.com> Date: Mon, 31 Jul 2006 18:48:49 -0400 From: David Blacka User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Doug Barton CC: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards References: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> <44CE808B.3030005@dougbarton.us> In-Reply-To: <44CE808B.3030005@dougbarton.us> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Doug Barton wrote: > In short, I've tried to understand what you are proposing and why, and I do > not think that the benefits of your proposal outweigh the costs. The way I read Phill's proposal was that he was merely defining: 1) a new zone preprocessor rule (perhaps confusingly called **.example) 2) a new use for PTR in the forward space. Am I wrong? If I'm not wrong, I am at a loss to understand what is so controversial about either part of the proposal. -- David Blacka Sr. Engineer VeriSign Infrastructure Product Engineering -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 18:59:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gjM-00033X-MZ for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:59:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gjL-0007KX-3m for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 18:59:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7ghg-000DWU-F9 for namedroppers-data@psg.com; Mon, 31 Jul 2006 22:57:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7ghd-000DVy-PV for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 22:57:37 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k6VMvbDI023733; Mon, 31 Jul 2006 15:57:37 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k6VMvano023730; Mon, 31 Jul 2006 15:57:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 31 Jul 2006 15:57:36 -0700 (PDT) From: "william(at)elan.net" To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: RE: a suggestion for super-wildcards In-Reply-To: <198A730C2044DE4A96749D13E167AD37C6657B@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: References: <198A730C2044DE4A96749D13E167AD37C6657B@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Mon, 31 Jul 2006, Hallam-Baker, Phillip wrote: >> There is an enormous difference between a super-wildcard that >> synthesizes a response for something that doesn't exist, and >> one that _overrides_ the records in a child domain. (BTW, I >> have a hard time following your use of "upper" and "lower," >> you might want to stick with the DNS terms of art "parent" >> and "child.") I could muster up support for a good >> implementation of the former, but I cannot imagine a scenario >> where I would support the latter. > > What I want to see is the former. > > **.example.com would match responses where there is no record of a given type at a node. If there is a record of the given type at the node it always take precedence, if there is a closer wildcard match it also takes precedence. > > I don't see this being different in principle to existing wildcards. Could you explain what will happen when the zone file has to be exported to another server. Specifically these 2 cases: 1. AXFR (or IXFR if you like) 2. DNSSEC retrieval of signed domain zone -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 19:07:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7grU-0007U2-HH for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 19:07:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7grT-0007np-8K for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 19:07:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7gpl-000Ea7-AH for namedroppers-data@psg.com; Mon, 31 Jul 2006 23:06:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [204.14.89.7] (helo=mail2.fluidhosting.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7gpk-000EZX-4f for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 23:06:00 +0000 Received: (qmail 27691 invoked by uid 399); 31 Jul 2006 23:05:59 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 31 Jul 2006 23:05:59 -0000 Message-ID: <44CE8CD3.7080905@dougbarton.us> Date: Mon, 31 Jul 2006 16:05:55 -0700 From: Doug Barton User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: David Blacka CC: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards References: <198A730C2044DE4A96749D13E167AD37BD6CE2@MOU1WNEXMB04.vcorp.ad.vrsn.com> <44CE808B.3030005@dougbarton.us> <44CE88D1.3090205@verisignlabs.com> In-Reply-To: <44CE88D1.3090205@verisignlabs.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 David Blacka wrote: > Doug Barton wrote: > >> In short, I've tried to understand what you are proposing and why, and I do >> not think that the benefits of your proposal outweigh the costs. > > The way I read Phill's proposal was that he was merely defining: > > 1) a new zone preprocessor rule (perhaps confusingly called **.example) His thesis in the message sent minutes before yours is that I misunderstand his proposal, so I'll respond to his message. > 2) a new use for PTR in the forward space. > > Am I wrong? If I'm not wrong, I am at a loss to understand what is so > controversial about either part of the proposal. I purposely didn't comment on the PTR proposal, but I'm against overloading existing RRs on principle. If a new thing needs a new RR, it should get one. Doug -- If you're never wrong, you're not trying hard enough -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 19:22:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7h5P-00065E-B7 for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 19:22:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7h5N-0000mX-T9 for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 19:22:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7h2c-000GJs-JD for namedroppers-data@psg.com; Mon, 31 Jul 2006 23:19:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.14.89.7] (helo=mail2.fluidhosting.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7h2b-000GJR-2w for namedroppers@ops.ietf.org; Mon, 31 Jul 2006 23:19:17 +0000 Received: (qmail 6584 invoked by uid 399); 31 Jul 2006 23:19:16 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 31 Jul 2006 23:19:16 -0000 Message-ID: <44CE8FF0.7000406@dougbarton.us> Date: Mon, 31 Jul 2006 16:19:12 -0700 From: Doug Barton User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: Roy Arends , namedroppers@ops.ietf.org Subject: Re: a suggestion for super-wildcards References: <198A730C2044DE4A96749D13E167AD37C6657B@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD37C6657B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Hallam-Baker, Phillip wrote: >> From: Doug Barton [mailto:dougb@dougbarton.us] > >> Yeah, and they are getting worse. > > Fortunately you are reading the description of the alternative. Well that's good news. :) >> There is an enormous difference between a super-wildcard that >> synthesizes a response for something that doesn't exist, and one that >> _overrides_ the records in a child domain. (BTW, I have a hard time >> following your use of "upper" and "lower," you might want to stick with >> the DNS terms of art "parent" and "child.") I could muster up support >> for a good implementation of the former, but I cannot imagine a >> scenario where I would support the latter. > > What I want to see is the former. > > **.example.com would match responses where there is no record of a given > type at a node. If there is a record of the given type at the node it > always take precedence, if there is a closer wildcard match it also takes > precedence. That is a much more cogent explanation, thanks. I'm still not sure I support it, but at least now I understand it better. > I don't see this being different in principle to existing wildcards. The main difference I see is that crosses delegation points, which still leads to confusion and problems of the "how did something get into the foo.example.com zone that is not in the foo.example.com zone file?" variety, although in the more limited form that you describe, those questions may be in the "trainable" category. > There is no tree walking in my scheme, every lookup takes a maximum of > three queries. >> If I understand what you're saying here correctly, I would suggest that >> this is an error in any case. If you're sending me mail with the >> expectation that I should be able to reply to it, then I need an >> address to reply to that is visible in my view of the DNS. If your >> From: address isn't visible to me in DNS, the message is probably spam >> anyways. > > The folk who have done the empirics on this disagree. Can you give some references? I'd love to educate myself more on this topic. >>> 1) Define a 'wilder card' ** that matches a node if the >> result would >>> otherwise be NO-DATA and which acts on subdomains as well >> As I said above, I do not support the latter in the way that you are >> proposing it. >> >>> From a protocol point of view I think that we should do the >> first in >>> any case since it will ease the transition from non-compliant >>> wildcards to compliant wildcards when DNSSEC is in use. >> Can you please flesh this out a bit, preferably with examples? Did you intend to fill something in here? >>> In particular many existing DNS implementations already implement the >>> ** semantics >> since this is >>> what administrators need to define MX records. >> Once again, can you give examples, preferably with reference to >> documentation? > > If you have the following nodes: > > a.example.com A 10.1.1.1 *.example.com MX 1 1 email.example.com > > The MX record does not match a.example.com because there is an a record > at the node. So if you want to direct all mail delivery to > email.example.com you have to add in explicit wildcards: > > a.example.com A 10.1.1.1 *.example.com MX 1 1 email.example.com > a.example.com MX 1 1 email.example.com > > If you have fifty odd hosts this is a PITA. Thanks, I'm glad to see that on this point at least I understood you clearly. I solved this problem a long time ago with preprocessors, so I stopped caring. :) > So some DNS servers actually > specify wildcard semantics that have a looser match. Which DNS servers? > I think it is clear that the DNS will be the infrastructure chosen to > support this function. I think it's clear that the DKIM folks would like DNS to be where the function is supported. What I would like to understand better is what the problems are exactly, and where the solutions to those problems are best found. I still have a gut feeling that you're looking to place some solutions in the DNS space that are best found in the DKIM space, but I'm willing to listen to reasons that I'm wrong. I've now reached my personal quota of two messages per day on this topic, so I'll let some others respond, and think about this some more. Thanks for your efforts in helping to clarify things. Doug -- If you're never wrong, you're not trying hard enough -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 20:16:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7hwG-00050j-0C for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 20:16:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7hwE-0005C8-LB for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 20:16:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7htM-000MYf-GB for namedroppers-data@psg.com; Tue, 01 Aug 2006 00:13:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7htL-000MYQ-MC for namedroppers@ops.ietf.org; Tue, 01 Aug 2006 00:13:47 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k710Dgmj029518; Mon, 31 Jul 2006 17:13:42 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:13:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: a suggestion for super-wildcards Date: Mon, 31 Jul 2006 17:13:28 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37C6658A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a suggestion for super-wildcards Thread-Index: Aca098BK7OBc9ytCSJyOlpTc2tnoZQAAzYrA From: "Hallam-Baker, Phillip" To: "Doug Barton" Cc: "Roy Arends" , X-OriginalArrivalTime: 01 Aug 2006 00:13:42.0565 (UTC) FILETIME=[58C5B550:01C6B4FF] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 > From: Doug Barton [mailto:dougb@dougbarton.us]=20 > The main difference I see is that crosses delegation points,=20 > which still leads to confusion and problems of the "how did=20 > something get into the foo.example.com zone that is not in=20 > the foo.example.com zone file?" variety, although in the more=20 > limited form that you describe, those questions may be in the=20 > "trainable" category. It doesn't. Not unless you can explain to me how to do that with a macro = :-) The parent zone could send the responses but it would not get asked the = question if the requestor had already seen the delegation. > > The folk who have done the empirics on this disagree. >=20 > Can you give some references? I'd love to educate myself more=20 > on this topic. Its mostly on the DKIM list I am afraid, not collected in a coherent = way. > >>> 1) Define a 'wilder card' ** that matches a node if the > >> result would > >>> otherwise be NO-DATA and which acts on subdomains as well > >> As I said above, I do not support the latter in the way=20 > that you are=20 > >> proposing it. > >>=20 > >>> From a protocol point of view I think that we should do the > >> first in > >>> any case since it will ease the transition from non-compliant=20 > >>> wildcards to compliant wildcards when DNSSEC is in use. > >> Can you please flesh this out a bit, preferably with examples? >=20 > Did you intend to fill something in here? Windows DNS already uses loose wildcards. If the cost of deploying = dnssec is to redefine existing macros then dnnsec is a harder sell. > > If you have fifty odd hosts this is a PITA. >=20 > Thanks, I'm glad to see that on this point at least I=20 > understood you clearly. I solved this problem a long time ago=20 > with preprocessors, so I stopped caring. :) The idea here is to istitutionalize the principle of doing so. > > So some DNS servers actually > > specify wildcard semantics that have a looser match. >=20 > Which DNS servers? Windows DNS, djbdns. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 21:12:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ioM-0005st-GR for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 21:12:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ioJ-0001jz-Rm for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 21:12:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7ikw-0002Tt-R7 for namedroppers-data@psg.com; Tue, 01 Aug 2006 01:09:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7ikv-0002Tf-PS for namedroppers@ops.ietf.org; Tue, 01 Aug 2006 01:09:09 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id D50EA5685A; Mon, 31 Jul 2006 18:09:07 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060731204728.040559c0@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 31 Jul 2006 21:09:08 -0400 To: Eric Rescorla ,namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Comments on dr In-Reply-To: <20060731174215.A9922222425@laser.networkresonance.com> References: <20060731174215.A9922222425@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Hi Eric - Thanks for the analysis. It agrees with what I assumed when doing the design. As far as I can tell, none of these comments indicate a weakness in the protocol, but discuss more the handling of the keying material and its security? If that's the case, it may make sense (once this document passes) to get DNSOPs to write a document on the general topic of operational security of DNSSEC key material. At 01:34 PM 7/31/2006, Eric Rescorla wrote: >This draft uses a variant of the two-key strategy: a given island can >have an arbitrary number of keys. The draft (S 5) suggests having two >keys, an "active" key and a "stand-by" key, but this isn't wired into >the protocol. This differs from the two-tier model discussed above in >two respects: > >1. From the perspective of the relying party, all keys have > the same security level. Any key can be used to sign a > new key, allowing automatic rollover in non-compromise > cases. However, keys cannot revoke other keys--to revoke > a key you produce a self-signed revocation. >2. When you roll-over, you make the previous stand-by key > the active key. > >The advantage of this scheme is that it can survive compromise of >either key. The disadvantage is that it encourages having two keys >with roughly similar security levels, thus making compromise of the >stand-by key more likely. In particular, if you intend for the >stand-by key to become the active key, then even if you initially >store it in a high security module, you need some mechanism for >releasing it which represents a potential attack vector. If you simply >always treat the standby key as a key-signing-key then this problem >goes away and while this is permitted by this draft, it seems like >this would be good guidance. Agreed, but probably not a protocol issue? So maybe more appropriate as a DNSOP document... I considered the "master key" approach, but it actually has more vulnerabilities and has this interesting requirement that each trust point MUST have more than one key. As written, a trust point can start out with one key (trust anchor) and add more as necessary or desired. That means you can deploy the new software (which implements the protocol) and eventually add new keys to existing trust points without having to re-issue the trust point key set. >A second issue is that because you need access to any given key in >order to revoke it, you are more vulnerable to attacks where the >active key private key is destroyed (e.g., an attacker steals it and >then erases the disk) and this is a higher risk because the active key >is used frequently. You would not be able to revoke the key in such >cases. I don't know if it's possible to produce a pre-signed >revocation as discussed in [1], but it would presumably be advisable >in this instance. Note that you can always remove it from the >RRSET but this doesn't provide an authenticated removal, right? >Also, what do you do if you lose all your keys...? Start over. The protocol isn't designed to completely deal with operator stupidity. I'm not sure I've seen any IETF protocol that does a good job of DWIM (Do What I Mean). And it isn't easily possible to do a pre-signed revocation - the RRSIG is over the atomic set of DNSKEYs at the name. The timing doesn't matter, but the set of keys signed at any given time is going to vary - especially if you're creating a new key to deal with the compromised key. >So, in general, I think it's a mistake to have a system where you >assume that both keys are about equally likely to be >compromised. I'm pretty sure this is an operational assessment rather than a protocol assessment. The protocol doesn't assume ANY values for "probability of compromise" for any key material. The key material owner can take any precautions from keeping a copy of the private key escrowed (using threshold, a safe deposit box, multiple flash drives, cryptographic tokens) to writing it down on a card in his/her wallet/purse, to leaving it in his desk, to publishing it on the internet. Each of these has its own characteristics (e.g. safe deposit box may be harder to steal the private key but single copy may end up with higher probability of losing it, but publishing it on the internet has the exact reverse - easier to steal the key, but harder to lose it). I think its reasonable to leave the operational security assessments and key protection mechanisms to the zone owner. Comment? >Certainly, if you're worried about a computational attack >and the keys are the same length, then any sane attacker will break >all the keys before tipping his hand (this is a constant factor). And >once you have asymmetric lengths, then it's unattractive to use them >identically. If this is the direction the WG wants to go in, >I think it would be appropriate to discuss what threat model >motivates it. The computational attack is no better or worse than any other part of the rest of DNSSEC - if we're worried about this in general for DNSSEC, we should talk about it in that context, rather than imputing it as a sole issue for trust anchor roll over. >-Ekr > >[1] Note that it's possible to design a system like this where >the high-assurance key can be revoked but not reprovisioned >automatically. For instance, you pre-sign a self-revocation >for the high-assurance key which you then release in the >case of compromise. There's also Micali's trick of having >the high-assurance cert contain a digest of some secret random >value X (i.e., H(X).. To revoke the key you release X and >everyone can verify X. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 21:25:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7j0X-0003HJ-Eu for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 21:25:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7j0W-0002wQ-Re for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 21:25:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7iyC-0003yL-Ss for namedroppers-data@psg.com; Tue, 01 Aug 2006 01:22:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7iyB-0003y1-Vd for namedroppers@ops.ietf.org; Tue, 01 Aug 2006 01:22:52 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id E20345685A; Mon, 31 Jul 2006 18:22:49 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060731211007.03b17818@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 31 Jul 2006 21:22:50 -0400 To: Robert Story From: Mike StJohns Subject: Re: timers draft and parent DS records Cc: "DNSEXT WG" In-Reply-To: References: <7.0.1.0.2.20060730180330.03a082b8@nominum.com> <7.0.1.0.2.20060730191213.040030c0@nominum.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_365310779==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 --=====================_365310779==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:59 AM 7/31/2006, Robert Story wrote: >On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote: >MS> Umm.. how in any reading of the text could you get that 4.3 implies >MS> that you auto-trust a superior? I think you're way off in the weeds here. > >I was indeed wandering in the weeds, and my question was just to make >sure. As to how I got there: I do not see any such implication, but >after re-reading it several times, I noticed that while later >paragraphs talked about 'configured' trust points, the first paragraph >only says "If there ARE superior trust points". I suggest adding the >word configured in the first paragraph as well. OK - that's fine. >Now, on to my main point, which got lost in the confusion. Deleting the >reference to 4.3 from my original message: > >At 05:07 PM 7/28/2006, Robert Story wrote: > >Shouldn't the scenarios in section 5 include steps on updating parent > >DS records? [...] It seems to me that when you roll a SEP key, > >you'd want to update the parent DS so resolvers which have a superior > >trust point configured would continue to validate the zone data. > >And the eventual response: > >On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote: >MS> This is not in scope for this document. [...] Section 5 talks about the >MS> normal operations for a trust point - regardless of whether there are >MS> superior trust anchors. Refer to the normal DNSSEC documents for how >MS> to deal with DS records etc. I don't need to and will not repeat DS >MS> management discussions in this ID. > >With all due respect, I disagree. If you don't want to added anything >to the individual scenarios, I think there should at least be a few >words about it in the introduction of section 5 (suggested text >included at the bottom of this message). > >While this document is primarily about resolvers, it also specifies >procedure for zone administrators (sections 5 and part of 4.3). Actually, it doesn't. Section 5 and much of section 4.3 are informative, not normative. The IETF is not allowed to include people as protocol elements as much as we'd like to. One of the reasons for not adding your proposed language is that DS updates are covered in part in section 2.4 of RFC 4035 which says in part: " Construction of a DS RR requires knowledge of the corresponding DNSKEY RR in the child zone, which implies communication between the child and parent zones. This communication is an operational matter not covered by this document." If that document declines to discuss DS operations, it seems clear this document should not (and indeed must not) create a normative requirement on DNSSEC for things outside its purview (e.g. the DS record). If this document becomes a standards track RFC, some of what your saying MAY be appropriate for whatever later revisions occur to draft-ietf-dnsop-dnssec-operational-practices-08 or its successor(s). >Zone >administrators must add/revoke/remove keys in the proscribed manner for >resolvers to automatically update their trust anchors. Given that we >are describing the rollover procedure for zone administrators, I think >we need to at least mention the potential pitfall when the parent zone >is signed. > >As requested, I'm including some suggested text, which I think should be >added after the 2nd paragraph of section 5: > > N.B. The steps outlined below assume an unsigned parent zone. > When keys are added, revoked or removed from a zone with a signed > parent, the parent zone should be notified so that DS record(s) can > be updated appropriately. Failure to do so will prevent resolvers > which only have a superior trust point configured from securely > resolving the subordinate zone. > > >-- >Robert Story >SPARTA > --=====================_365310779==.ALT Content-Type: text/html; charset="us-ascii" At 10:59 AM 7/31/2006, Robert Story wrote:
On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote:
MS> Umm.. how in any reading of the text could you get that 4.3 implies
MS> that you auto-trust a superior?  I think you're way off in the weeds here.

I was indeed wandering in the weeds, and my question was just to make
sure. As to how I got there: I do not see any such implication, but
after re-reading it several times, I noticed that while later
paragraphs talked about 'configured' trust points, the first paragraph
only says "If there ARE superior trust points". I suggest adding the word configured in the first paragraph as well.

OK - that's fine.

Now, on to my main point, which got lost in the confusion. Deleting the
reference to 4.3 from my original message:

At 05:07 PM 7/28/2006, Robert Story wrote:
>Shouldn't the scenarios in section 5 include steps on updating parent
>DS records? [...] It seems to me that when you roll a SEP key,
>you'd want to update the parent DS so resolvers which have a superior
>trust point configured would continue to validate the zone data.

And the eventual response:

On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote:
MS> This is not in scope for this document. [...] Section 5 talks about the
MS> normal operations for a trust point - regardless of whether there are
MS> superior trust anchors.  Refer to the normal DNSSEC documents for how
MS> to deal with DS records etc.  I don't need to and will not repeat DS
MS> management discussions in this ID.

With all due respect, I disagree. If you don't want to added anything
to the individual scenarios, I think there should at least be a few
words about it in the introduction of section 5 (suggested text
included at the bottom of this message).

While this document is primarily about resolvers, it also specifies
procedure for zone administrators (sections 5 and part of 4.3).

Actually, it doesn't.  Section 5 and much of section 4.3 are informative, not normative.  The IETF is not allowed to include people as protocol elements as much as we'd like to. 

One of the reasons for not adding your proposed language is that DS updates are covered in part in section 2.4 of RFC 4035 which says in part: "
   Construction of a DS RR requires knowledge of the
corresponding
   DNSKEY RR in the child zone, which implies communication
between the
   child and parent zones.  This communication is an
operational matter
   not covered by this document."
If that document declines to discuss DS operations, it seems clear this document should not (and indeed must not) create a normative requirement on DNSSEC for things outside its purview (e.g. the DS record).    If this document becomes a standards track RFC, some of what your saying MAY be appropriate for whatever later revisions occur to draft-ietf-dnsop-dnssec-operational-practices-08 or its successor(s).

Zone
administrators must add/revoke/remove keys in the proscribed manner for
resolvers to automatically update their trust anchors. Given that we
are describing the rollover procedure for zone administrators, I think
we need to at least mention the potential pitfall when the parent zone
is signed.

As requested, I'm including some suggested text, which I think should be
added after the 2nd paragraph of section 5:

   N.B. The steps outlined below assume an unsigned parent zone.
   When keys are added, revoked or removed from a zone with a signed
   parent, the parent zone should be notified so that DS record(s) can
   be updated appropriately. Failure to do so will prevent resolvers
   which only have a superior trust point configured from securely
   resolving the subordinate zone.


--
Robert Story
SPARTA

--=====================_365310779==.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 31 23:45:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7lCO-0006ao-7h for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 23:45:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7klT-0002MX-M7 for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 23:17:51 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7kVp-0005qh-1O for dnsext-archive@lists.ietf.org; Mon, 31 Jul 2006 23:01:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7kS8-000FZc-PE for namedroppers-data@psg.com; Tue, 01 Aug 2006 02:57:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.221] (helo=mail1.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7kS7-000FZH-Lv for namedroppers@ops.ietf.org; Tue, 01 Aug 2006 02:57:51 +0000 Received: by mail1.sea.safepages.com (Postfix, from userid 1012) id 6990F12BEC2; Tue, 1 Aug 2006 02:57:50 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.141]) by mail1.sea.safepages.com (Postfix) with ESMTP id DD3B912BC75; Tue, 1 Aug 2006 02:57:48 +0000 (GMT) Message-ID: <44CEC3C9.5040403@connotech.com> Date: Mon, 31 Jul 2006 23:00:25 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Rescorla Cc: namedroppers@ops.ietf.org Subject: Re: Comments on dr References: <20060731174215.A9922222425@laser.networkresonance.com> In-Reply-To: <20060731174215.A9922222425@laser.networkresonance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -1.6 (-) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Eric Rescorla wrote: > [... explanations on security model for draft-ietf-dnsext-trustupdate-timers ...] > > So, in general, I think it's a mistake to have a system where you > assume that both keys are about equally likely to be > compromised. Certainly, if you're worried about a computational attack > and the keys are the same length, then any sane attacker will break > all the keys before tipping his hand (this is a constant factor). And > once you have asymmetric lengths, then it's unattractive to use them > identically. If this is the direction the WG wants to go in, > I think it would be appropriate to discuss what threat model > motivates it. > A "threat model" is something seldom discussed in DNSEXT WG / namedroppers (now that this draft is looked at by a broader audience, it may become relevant, hinted by your post). A while ago, I thought threat model explicitness (e.g. in the form of "catastrophic failure mode" disclosure) would easily be included in the TAK requirements draft document produced by the wg, but it was not the case. Accordingly, by default, the wg position would be that threat model discussion is not a required step for selecting an automated TAK rollover solution. Personally I disagree, but that seems to me close to a wg consensus. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: