From owner-namedroppers@ops.ietf.org Mon Aug 01 02:43:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzU0r-0007Wz-Bc for dnsext-archive@megatron.ietf.org; Mon, 01 Aug 2005 02:43:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06930 for ; Mon, 1 Aug 2005 02:42:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzTtA-000EF5-IA for namedroppers-data@psg.com; Mon, 01 Aug 2005 06:35:04 +0000 Received: from [193.0.1.50] (helo=localhost.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzTt8-000EEC-H7 for namedroppers@ops.ietf.org; Mon, 01 Aug 2005 06:35:02 +0000 Received: by localhost.ripe.net (Postfix, from userid 4133) id A222E7C069; Mon, 1 Aug 2005 08:35:01 +0200 (CEST) To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Message-Id: <20050801063501.A222E7C069@localhost.ripe.net> Date: Mon, 1 Aug 2005 08:35:01 +0200 (CEST) From: olaf@ripe.net (Olaf Kolkman) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - 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 Mon Aug 01 04:50:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzVzs-0004KY-SY for dnsext-archive@megatron.ietf.org; Mon, 01 Aug 2005 04:50:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05989 for ; Mon, 1 Aug 2005 04:50:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzVud-0000o7-1P for namedroppers-data@psg.com; Mon, 01 Aug 2005 08:44:43 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzVuX-0000nn-Sj for namedroppers@ops.ietf.org; Mon, 01 Aug 2005 08:44:39 +0000 Received: from impact.jinmei.org (unknown [2001:688:ffff:24:cc29:28a1:1048:3bab]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7B50215218 for ; Mon, 1 Aug 2005 17:44:35 +0900 (JST) Date: Mon, 01 Aug 2005 17:44:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org Subject: Resend: Re: RFC2181 section 9.1: TC bit handling and additional data References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Mon_Aug__1_17:44:14_2005-1" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Multipart_Mon_Aug__1_17:44:14_2005-1 Content-Type: text/plain; charset=US-ASCII Apparently this was blocked or dropped due to sender address mismatch. I'm trying to resend it with (seemingly) correct address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Mon_Aug__1_17:44:14_2005-1 Content-Type: message/rfc822 Date: Thu, 28 Jul 2005 22:29:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: namedroppers@ops.ietf.org Subject: Re: RFC2181 section 9.1: TC bit handling and additional data In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Wed, 29 Jun 2005 21:00:36 +0300 (EEST), >>>>> Pekka Savola said: > We would like to get some additional feedback especially on what's in > the implementations out there (the recommendations in the > specification seem clear enough). > Specific questions (offlist responses are also fine): Answers about ISC BIND 9.3.1 and 8.4.6, and NSD 2.3.0 (authoritative only). I actually confirmed the behavior with a test zone and test queries for question 1, but the rest of the answers were just based on code inspection (so I could be wrong). > 1. how does your implementation (or the implementations you're > familiar with) handle the case of critical additional data > (example below) when the response doesn't fit. > a) set TC bit and remove all the additional data RRsets > b) set TC bit and remove some additional data RRsets so > the size is small enough > c) something else, what? ISC BIND 9.3.1: c). remove some additional data RRsets so the size is small enough. does NOT set TC bit. prefer A glues over AAAA glues by default for each glue name. configurable via the preferred-glue option. ISC BIND 8.4.6: c) same as BIND 9.3.1. NSD 2.3.0: c) remove some additional RRs of some additional data RRsets. does NOT set TC bit. The main difference from BIND is that NSD can return a partial RRset in the additional section without setting the TC bit (is this valid?). Always prefer A glues over AAAA glues (no configurable option). > 2. how does your implementation (or the implementations you're > familiar with) handle the case of courtesy additional data > (e.g., CNAME) when the response doesn't fit. > a) remove the all the additional data RRsets if some of them don't > fit, don't set TC bit. > b) remove some of the additional data RRsets if the response > then fits, don't set TC bit. > c) set TC bit and [do something, what?] > d) something else, what? ISC BIND 9.3.1: b). Actually, BIND 9.3.1 does not differentiate critical and courtesy additional data, although it prefers some critical data (e.g., glues) over some courtesy data (e.g., DNSSEC RRs). ISC BIND 8.4.6: b) (same as BIND 9.3.1, although the preference logic may be slightly different). NSD 2.3.0: same as the answer to question 1. does not differentiate critical and courtesy additional data, although it prefers some critical data over some courtesy data. > 3. if your implementation (or the implemenations you're familiar > with) receives a response with TC bit set and an additional > section, what does it do? > a) ignore everything in the response, and re-query using TCP. > b) keep some or all of the data in the response, re-query using > TCP (additional details would be welcome). > c) something else, what? ISC BIND 9.3.1 a) ISC BIND 8.4.6 a) (there seem to be some exceptional cases, but I think we can ignore such cases in this discussion). > 4. do you know of any implementations which either do not set the TC > bit when all the critical additional data RRsets don't fit, or do > not ignore the whole response when the TC bit was set? As for the former, BIND 8/9 and NSD never sets the TC due to additional data. As for the latter, none, as far as I know. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp APPENDIX: test details about question 1 - tested zone: ".example" It has a delegation to the child.example zone with one NS "ns.child.example", which has 15 AAAA glues and 9 A glues. I've checked the response from each tested server to dig @server's_address www.child.example +norec - zone file $TTL 518400 @ IN SOA ns.example. root.example. ( 2005021601 ;serial 1800 ;refresh every 30 min 900 ;retry every 15 min 604800 ;expire after a week 86400 ;minimum of a day ) IN NS ns ns IN A 127.0.0.1 child IN NS ns.child ns.child IN AAAA 2001:db8::1 ns.child IN AAAA 2001:db8::2 ns.child IN AAAA 2001:db8::3 ns.child IN AAAA 2001:db8::4 ns.child IN AAAA 2001:db8::5 ns.child IN AAAA 2001:db8::6 ns.child IN AAAA 2001:db8::7 ns.child IN AAAA 2001:db8::8 ns.child IN AAAA 2001:db8::9 ns.child IN AAAA 2001:db8::a ns.child IN AAAA 2001:db8::b ns.child IN AAAA 2001:db8::c ns.child IN AAAA 2001:db8::d ns.child IN AAAA 2001:db8::e ns.child IN AAAA 2001:db8::f ns.child IN A 192.0.2.1 ns.child IN A 192.0.2.2 ns.child IN A 192.0.2.3 ns.child IN A 192.0.2.4 ns.child IN A 192.0.2.5 ns.child IN A 192.0.2.6 ns.child IN A 192.0.2.7 ns.child IN A 192.0.2.8 ns.child IN A 192.0.2.9 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#10053(127.0.0.1) ;; WHEN: Thu Jul 28 22:25:46 2005 ;; MSG SIZE rcvd: 196 - response from BIND 9.3.1 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10928 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 9 ;; QUESTION SECTION: ;www.child.example. IN A ;; AUTHORITY SECTION: child.example. 518400 IN NS ns.child.example. ;; ADDITIONAL SECTION: ns.child.example. 518400 IN A 192.0.2.1 ns.child.example. 518400 IN A 192.0.2.2 ns.child.example. 518400 IN A 192.0.2.3 ns.child.example. 518400 IN A 192.0.2.4 ns.child.example. 518400 IN A 192.0.2.5 ns.child.example. 518400 IN A 192.0.2.6 ns.child.example. 518400 IN A 192.0.2.7 ns.child.example. 518400 IN A 192.0.2.8 ns.child.example. 518400 IN A 192.0.2.9 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#10053(127.0.0.1) ;; WHEN: Thu Jul 28 22:26:32 2005 ;; MSG SIZE rcvd: 196 - response from BIND 8.4.6 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63072 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 9 ;; QUESTION SECTION: ;www.child.example. IN A ;; AUTHORITY SECTION: child.example. 518400 IN NS ns.child.example. ;; ADDITIONAL SECTION: ns.child.example. 518400 IN A 192.0.2.1 ns.child.example. 518400 IN A 192.0.2.2 ns.child.example. 518400 IN A 192.0.2.3 ns.child.example. 518400 IN A 192.0.2.4 ns.child.example. 518400 IN A 192.0.2.5 ns.child.example. 518400 IN A 192.0.2.6 ns.child.example. 518400 IN A 192.0.2.7 ns.child.example. 518400 IN A 192.0.2.8 ns.child.example. 518400 IN A 192.0.2.9 - response from NSD 2.3.0 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31241 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 20 ;; QUESTION SECTION: ;www.child.example. IN A ;; AUTHORITY SECTION: child.example. 518400 IN NS ns.child.example. ;; ADDITIONAL SECTION: ns.child.example. 518400 IN A 192.0.2.1 ns.child.example. 518400 IN A 192.0.2.2 ns.child.example. 518400 IN A 192.0.2.3 ns.child.example. 518400 IN A 192.0.2.4 ns.child.example. 518400 IN A 192.0.2.5 ns.child.example. 518400 IN A 192.0.2.6 ns.child.example. 518400 IN A 192.0.2.7 ns.child.example. 518400 IN A 192.0.2.8 ns.child.example. 518400 IN A 192.0.2.9 ns.child.example. 518400 IN AAAA 2001:db8::1 ns.child.example. 518400 IN AAAA 2001:db8::2 ns.child.example. 518400 IN AAAA 2001:db8::3 ns.child.example. 518400 IN AAAA 2001:db8::4 ns.child.example. 518400 IN AAAA 2001:db8::5 ns.child.example. 518400 IN AAAA 2001:db8::6 ns.child.example. 518400 IN AAAA 2001:db8::7 ns.child.example. 518400 IN AAAA 2001:db8::8 ns.child.example. 518400 IN AAAA 2001:db8::9 ns.child.example. 518400 IN AAAA 2001:db8::a ns.child.example. 518400 IN AAAA 2001:db8::b (Note that the AAAA RRset is incomplete) ;; Query time: 0 msec ;; SERVER: 127.0.0.1#10053(127.0.0.1) ;; WHEN: Thu Jul 28 22:28:00 2005 ;; MSG SIZE rcvd: 504 --Multipart_Mon_Aug__1_17:44:14_2005-1-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 01 05:52:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWyV-000848-1J for dnsext-archive@megatron.ietf.org; Mon, 01 Aug 2005 05:52:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13920 for ; Mon, 1 Aug 2005 05:52:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzWuO-0006pc-IR for namedroppers-data@psg.com; Mon, 01 Aug 2005 09:48:32 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DzWuN-0006pK-Kz for namedroppers@ops.ietf.org; Mon, 01 Aug 2005 09:48:32 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j719mSI0019815 for ; Mon, 1 Aug 2005 05:48:28 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j719mS0u019814 for namedroppers@ops.ietf.org; Mon, 1 Aug 2005 05:48:28 -0400 (EDT) (envelope-from namedroppers) Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dy6CF-0000Ic-NP for namedroppers@ops.ietf.org; Thu, 28 Jul 2005 11:05:05 +0000 Received: from impact.jinmei.org (unknown [2001:200:0:4819:7972:7e9e:4f2a:e055]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9725415218; Thu, 28 Jul 2005 20:04:59 +0900 (JST) Date: Thu, 28 Jul 2005 20:04:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: namedroppers@ops.ietf.org Subject: Re: RFC2181 section 9.1: TC bit handling and additional data In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] >>>>> On Thu, 28 Jul 2005 11:46:34 +0300 (EEST), >>>>> Pekka Savola said: >>> Specific questions (offlist responses are also fine): >> >> Did you get sufficient information about these questions? As far as I >> know, there has been no public response on the list. If there has >> been no off-list response either, I'll try to answer the questions on >> one implementation I know of a bit. > There has been no response at all. I guess everyone is hoping someone > else will be responding. I'd really appreciate any responses. Okay. One quick question: 3. if your implementation (or the implemenations you're familiar with) receives a response with TC bit set and an additional section, what does it do? Does this mean "if the implementation receives a response with TC bit set and *with* a (non empty) additional section..."? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 01 05:52:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWyW-00084z-R3 for dnsext-archive@megatron.ietf.org; Mon, 01 Aug 2005 05:52:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13926 for ; Mon, 1 Aug 2005 05:52:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzWuH-0006p6-FJ for namedroppers-data@psg.com; Mon, 01 Aug 2005 09:48:25 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DzWuF-0006oo-H5 for namedroppers@ops.ietf.org; Mon, 01 Aug 2005 09:48:23 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j719mJw0019809 for ; Mon, 1 Aug 2005 05:48:19 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j719mJ7W019808 for namedroppers@ops.ietf.org; Mon, 1 Aug 2005 05:48:19 -0400 (EDT) (envelope-from namedroppers) Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dy3TY-000BmN-BB for namedroppers@ops.ietf.org; Thu, 28 Jul 2005 08:10:44 +0000 Received: from impact.jinmei.org (unknown [2001:200:0:4819:7972:7e9e:4f2a:e055]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E22A415218; Thu, 28 Jul 2005 17:10:37 +0900 (JST) Date: Thu, 28 Jul 2005 17:10:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: namedroppers@ops.ietf.org Subject: Re: RFC2181 section 9.1: TC bit handling and additional data In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] >>>>> On Wed, 29 Jun 2005 21:00:36 +0300 (EEST), >>>>> Pekka Savola said: > In the process of finalizing draft-ietf-dnsop-ipv6-issues-xx.txt, > we've had off-list discussion about TC bit handling when the > criticial/courtesy additional data section should include both A and > AAAA records. > We would like to get some additional feedback especially on what's in > the implementations out there (the recommendations in the > specification seem clear enough). > Specific questions (offlist responses are also fine): Did you get sufficient information about these questions? As far as I know, there has been no public response on the list. If there has been no off-list response either, I'll try to answer the questions on one implementation I know of a bit. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 01 12:22:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd3z-0005yj-Uq for dnsext-archive@megatron.ietf.org; Mon, 01 Aug 2005 12:22:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21805 for ; Mon, 1 Aug 2005 12:22:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dzcyz-000FAS-An for namedroppers-data@psg.com; Mon, 01 Aug 2005 16:17:41 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dzcyx-000FA2-E1 for namedroppers@ops.ietf.org; Mon, 01 Aug 2005 16:17:39 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j71GDWDl017359 for ; Mon, 1 Aug 2005 12:13:32 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAD_aO5H; Mon, 1 Aug 05 12:13:28 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j71GFMiq007700 for ; Mon, 1 Aug 2005 12:15:23 -0400 (EDT) Date: Mon, 1 Aug 2005 12:15:22 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: NSEC3 requirements question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't see this addressed by our requirements doc, draft-ietf-dnsext-signed-nonexistence-requirements-01.txt (now expired). Please tell me if I missed something. -- must it be possible to smoothly roll between NSEC and NSEC3? Specifically I mean: -- During roll between NSEC and NSEC3 (and vice-versa), must a properly configured resolver that supports both NSEC and NSEC3 always see the zone as Secure (never Insecure)? -- Or is it okay to require that the roll between NSEC and NSEC3 go through an Insecure state? -- I'm assuming that when switching between them, no properly-signed zone should be marked as Bogus by any properly-configured validator, whether it supports NSEC only, NSEC3 only, or both. Posing the question in table form, is Table 1 necessary, or is Table 2 sufficient (notice the difference in the last line of each)? Table 1: Smooth Rollover Validation Result at Stage of NSEC--->NSEC3 rollover Resolver Supports pre-roll during roll after roll NSEC only Secure ? Insecure NSEC3 only Insecure ? Secure NSEC and NSEC3 Secure Secure Secure Table 2: Unsmooth Rollover (through Insecure) Validation Result at Stage of NSEC--->NSEC3 rollover Resolver Supports pre-roll during roll after roll NSEC only Secure ? Insecure NSEC3 only Insecure ? Secure NSEC and NSEC3 Secure ? Secure ? = Insecure or Secure, perhaps cache-dependent, but never Bogus -- to unsubscribe send a message to namedroppers-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 Aug 01 13:01:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzdfF-0003gz-O2 for dnsext-archive@megatron.ietf.org; Mon, 01 Aug 2005 13:01:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24023 for ; Mon, 1 Aug 2005 13:01:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dzdb2-000IFw-3w for namedroppers-data@psg.com; Mon, 01 Aug 2005 16:57:00 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dzdb0-000IDv-7B for namedroppers@ops.ietf.org; Mon, 01 Aug 2005 16:56:58 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A9F2BC2DA8; Mon, 1 Aug 2005 17:56:31 +0100 (BST) Date: Mon, 01 Aug 2005 17:56:05 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3 requirements question Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 01 August 2005 12:15 -0400 Samuel Weiler wrote: > -- During roll between NSEC and NSEC3 (and vice-versa), must a > properly configured resolver that supports both NSEC and NSEC3 > always see the zone as Secure (never Insecure)? I actually think there are a number of possible questions there: 1. Is it a requirement that an authoritative server [*] which supports both NSEC and NSEC3 can be "rolled-over" so that a zone initially using NSEC (only) can be reconfigured so as to support NSEC3 (only) such that in the intervening time, the zone is never seen as insecure by any compliant resolver that supports both NSEC and NSEC3. [Note: "never seen as insecure" is less stringent than "always seen as secure" as the latter could be read as not allowing the server to be taken off air at all.] 2. Is the reverse of (1) a requirement (i.e. roll back to NSEC). 3. Is it a requirement that a caching resolver, which supports NSEC can be "rolled over" to one which supports NSEC and NSEC3, without any adverse security implication on its clients (whether or not they only support NSEC). [it would be pretty dumb to break that requirement, but no doubt possible by selective record serving] I think the answer to all 3 is yes, and I think you probably meant (1) only :-) 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 NellShafer@sapropelic.com Tue Aug 02 04:22:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzs2U-0001lU-Tc for dnsext-archive@megatron.ietf.org; Tue, 02 Aug 2005 04:22:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29249 for ; Tue, 2 Aug 2005 04:22:16 -0400 (EDT) Received: from [221.127.98.83] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DzsYe-0001u1-6Y for dnsext-archive@ietf.org; Tue, 02 Aug 2005 04:55:50 -0400 Received: from iXb5@localhost by sMB.int (8.11.6/8.11.6); Tue, 02 Aug 2005 02:21:38 -0700 Message-ID: From: "Concetta Garland" Reply-To: "Concetta Garland" To: dnsext-archive@ietf.org Subject: Macromedia Software titles available for Download Date: Tue, 02 Aug 2005 04:30:38 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NellShafer@sapropelic.com Content-Type: multipart/mixed; boundary="--41792255791681313" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 J162 ----41792255791681313 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable M
Opt-in Email Special Offer   = ;  unsubscribe me
<= /td>
SEARCH

=

TOP 10 NEW TITLES

<= img src=3Dhttp://g-images.amazon.com/images/G/01/icons/eyebrow-upper-right= -corner.gif width=3D5 height=3D5>
2<= td width=3D129> Flash MX 2004= Customers also bought

 = ON SALE NOW!

 1 Office Pro 2003
  Adobe Photoshop 9.0
 = 3 Windows XP Pro
&nb= sp;4 Adobe Acrobat 7 Pro
 5
 6 Corel Draw 12
 7 Norton Antivirus 2005
 = 8 Windows 2003 Server=
 9 Alias Maya 6 Wavefrt<= /a>
 10 Adobe Illustrator 11
&= nbsp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe
 
&= nbsp;  these ot= her items...

Microsoft Office Professional Edition *2003*
Microsoft

<= tr>
Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (86%)



<= b>Availability: Available for INSTANT download!
Coupon Code: uwGLg32
 

Sales Rank: #1=
S= ystem requirements  |  Other Versions
Date Coupon Expire= s: August 31st, 2005
Average Customer= Review:3D"5 Based on 14111 reviews. Write a review.

Based on 16777 reviews. Write a review.

Microsoft Windows XP Professional or Longhorn Edition
Microsoft

Choose:
 

=
List Pr= ice:$279.00
Pric= e:$49.99
You Save:$229.01 (85%)



Availability: Available for INSTANT download!
= Coupon Code: LfdB4
 

Sales= Rank: #3
System requirements  |  Other Versions
Date = Coupon Expires: August 31st, 2005
Ave= rage Customer Review:3D"5 Based on 14874 reviews. Write a review.

Ad= obe Acrobat Professional V 7.0
Adobe

= Choose:
 

= = =
List Price:$499.0= 0
Price:$69.99
You Save:$429.01 (85%)



Availability: Availabl= e for INSTANT download!
Coupon Code: tfHciIijU
 

Sales Rank: #4
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: August 31st, 2005 Average Customer Review:3D"5 Based= on 14728 reviews. Write a review= .

----41792255791681313-- From owner-namedroppers@ops.ietf.org Thu Aug 04 04:42:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bIy-0007Gg-Fv for dnsext-archive@megatron.ietf.org; Thu, 04 Aug 2005 04:42:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12497 for ; Thu, 4 Aug 2005 04:42:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0bCQ-000Of8-UZ for namedroppers-data@psg.com; Thu, 04 Aug 2005 08:35:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E0bCQ-000Oeu-2m for namedroppers@ops.ietf.org; Thu, 04 Aug 2005 08:35:34 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j748ZVkZ037355 for ; Thu, 4 Aug 2005 04:35:31 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j748ZVWG037354 for namedroppers@ops.ietf.org; Thu, 4 Aug 2005 04:35:31 -0400 (EDT) (envelope-from namedroppers) Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E0bBA-000OXf-8K for namedroppers@ops.ietf.org; Thu, 04 Aug 2005 08:34:16 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j748YBrw037330; Thu, 4 Aug 2005 04:34:12 -0400 (EDT) (envelope-from ogud+namedroppers-owner@ogud.com) Message-Id: <6.2.3.4.2.20050802113226.04cfa510@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 04 Aug 2005 10:34:05 +0200 To: Samuel Weiler , namedroppers@ops.ietf.org From: Namedroppers-owner Subject: Re: NSEC3 requirements question In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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 real important question and there are multiple possible answers IMHO I think it is going to come down to cost which solution to select. At 18:15 01/08/2005, Samuel Weiler wrote: >I don't see this addressed by our requirements doc, >draft-ietf-dnsext-signed-nonexistence-requirements-01.txt (now >expired). Please tell me if I missed something. > >-- must it be possible to smoothly roll between NSEC and NSEC3? > >Specifically I mean: > >-- During roll between NSEC and NSEC3 (and vice-versa), must a > properly configured resolver that supports both NSEC and NSEC3 > always see the zone as Secure (never Insecure)? This is real hard, as for this to work the zone must use both NSEC and NSEC3 at the same time in order to work and validator pics one to follow at any given moment. >-- Or is it okay to require that the roll between NSEC and NSEC3 go > through an Insecure state? Yes, I think so, and this is the option that is the least expensive for resolvers and has the lowest risk to the infrastructure, as there is no special code path for this case. IE. zone picks a time that it goes insecure, and for how long an interval it is insecure. 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 Aug 04 07:12:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dec-0007et-Lc for dnsext-archive@megatron.ietf.org; Thu, 04 Aug 2005 07:12:50 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27492 for ; Thu, 4 Aug 2005 07:12:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0daj-000Bsa-Bc for namedroppers-data@psg.com; Thu, 04 Aug 2005 11:08:49 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0dag-000BrJ-R5 for namedroppers@ops.ietf.org; Thu, 04 Aug 2005 11:08:46 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 91154C2DA4; Thu, 4 Aug 2005 12:08:43 +0100 (BST) Date: Thu, 04 Aug 2005 12:08:40 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3 requirements question Message-ID: <17F0ECCCBE1C56EBB6498F74@[10.16.32.104]> In-Reply-To: <6.2.3.4.2.20050802113226.04cfa510@localhost> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> X-Mailer: Mulberry/4.0.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 04 August 2005 10:34 +0200 Namedroppers-owner wrote: >> -- During roll between NSEC and NSEC3 (and vice-versa), must a >> properly configured resolver that supports both NSEC and NSEC3 >> always see the zone as Secure (never Insecure)? > > This is real hard, as for this to work the zone must use both NSEC > and NSEC3 at the same time in order to work and validator pics one > to follow at any given moment. I'd blithely assumed that was exactly what happened. Why is this bit hard? (or rather why is it harder than having a resolver which supports both NSEC plus NSEC3). I presumed the hard bit was how to deal with potentially conflicting NSEC/NSEC3 information (my answer: don't do that). 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 Thu Aug 04 07:12:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dee-0007o0-Mm for dnsext-archive@megatron.ietf.org; Thu, 04 Aug 2005 07:12:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27495 for ; Thu, 4 Aug 2005 07:12:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0dbr-000Byd-Bc for namedroppers-data@psg.com; Thu, 04 Aug 2005 11:09:59 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0dbp-000ByD-Nb for namedroppers@ops.ietf.org; Thu, 04 Aug 2005 11:09:57 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 08F3BC2DA4; Thu, 4 Aug 2005 12:09:55 +0100 (BST) Date: Thu, 04 Aug 2005 12:09:53 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3 requirements question Message-ID: X-Mailer: Mulberry/4.0.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 04 August 2005 10:34 +0200 Namedroppers-owner wrote: >> -- During roll between NSEC and NSEC3 (and vice-versa), must a >> properly configured resolver that supports both NSEC and NSEC3 >> always see the zone as Secure (never Insecure)? > > This is real hard, as for this to work the zone must use both NSEC > and NSEC3 at the same time in order to work and validator pics one > to follow at any given moment. I'd blithely assumed that was exactly what happened. Why is this bit hard? (or rather why is it harder than having a resolver which supports both NSEC plus NSEC3). I presumed the hard bit was how to deal with potentially conflicting NSEC/NSEC3 information (my answer: don't do that). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 08 02:20:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E20ze-0007QK-Q4 for dnsext-archive@megatron.ietf.org; Mon, 08 Aug 2005 02:20:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02015 for ; Mon, 8 Aug 2005 02:20:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E20tv-0005BF-Il for namedroppers-data@psg.com; Mon, 08 Aug 2005 06:14:19 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E20tu-0005Ax-HR for namedroppers@ops.ietf.org; Mon, 08 Aug 2005 06:14:18 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 9A2FF2DE35; Mon, 8 Aug 2005 08:14:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 763342DE19 for ; Mon, 8 Aug 2005 08:14:14 +0200 (CEST) Date: Mon, 8 Aug 2005 08:14:14 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: nsec3 and opt-in Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At the Paris ietf dnsext wg meeting I was allowed to steal a few minutes presenting the differences between versions 01 and 02 of draft-ietf-dnsext-nsec3. One question that came up was why the specification for NSEC3 was bundled with opt-in. Without iterating the discussions we had years ago about the applicability of optin and without giving a value judgement on the usefulness or quality of either nsec3 and opt-in I'd like to shed light on my motivation for bundling nsec3 with opt-in. Not so long ago, the opt-in draft was baptized experimental, since at the time, we (the wg) came to the conclusion that publishing the dnssec-bis drafts had higher priority than breaking up the specification at the eleventh hour, effectively delaying progress. Since then, the dnssec-bis drafts have been published and we've moved on to other fronts. Addressing the last mile, trust achor management and measures against enumeration (not an exhaustive list). It is the authenticated denial of existence that allows for enumeration of a zone, regardless of policy decisions of the zone owner. It is this same record that was used in the past to signal authenticated denial of existence of signatures for unsigned delegations (opt-in). Even though anti-enumeration and opt-in techniques offer solutions for different problems (in fact, I see them as orthogonal) they have authenticated denial in common, and authenticated denial is based on a single resource record type. I argue that it is far more complex to separate these solutions into different signaling schemes using different resource records or meta-types. I view it as logical to signal opt-in using NSEC3 instead of signaling opt-in by some other means. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 08 05:33:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2414-0000mP-Gc for dnsext-archive@megatron.ietf.org; Mon, 08 Aug 2005 05:33:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09552 for ; Mon, 8 Aug 2005 05:33:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E23xA-000KCX-Ho for namedroppers-data@psg.com; Mon, 08 Aug 2005 09:29:52 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E23x7-000KCC-Mf for namedroppers@ops.ietf.org; Mon, 08 Aug 2005 09:29:49 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1104CC2DA5; Mon, 8 Aug 2005 10:29:47 +0100 (BST) Date: Mon, 08 Aug 2005 10:29:42 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Arends , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: nsec3 and opt-in Message-ID: <53697E68ADB4B4FA7E3959B7@[10.16.32.104]> X-Mailer: Mulberry/4.0.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, --On 08 August 2005 08:14 +0200 Roy Arends wrote: > Even though anti-enumeration and opt-in techniques offer solutions for > different problems (in fact, I see them as orthogonal) they have > authenticated denial in common, and authenticated denial is based on a > single resource record type. > > I argue that it is far more complex to separate these solutions into > different signaling schemes using different resource records or > meta-types. I view it as logical to signal opt-in using NSEC3 instead of > signaling opt-in by some other means. All of the above I agree with. The "do we do these at the same time" question should thus depend on the following two thing: 1. Does incorporation of opt-in make the standards process and deployment of NSEC3 significantly harder? (for instance, because it at least arguably introduces a new state - non-authenticated denial within a signed zone - for the next layer up) 2. If the answer to Q1 is yes, does this matter (for instance, taking an extreme example, if there were 100 other showstopper issues with DNSSEC-bis that suddenly arose and required a lot of protocol reengineering to fix, (1) becomes irrelevant). Those arguing against opt-in were arguing the answer to (1) was either "yes" or at best "it will taking some serious thinking an argument to come to an answer". Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 08 10:16:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28Qk-0000lr-S3 for dnsext-archive@megatron.ietf.org; Mon, 08 Aug 2005 10:16:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23686 for ; Mon, 8 Aug 2005 10:16:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E28Mf-000I6h-Qw for namedroppers-data@psg.com; Mon, 08 Aug 2005 14:12:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E28Mf-000I6U-62 for namedroppers@ops.ietf.org; Mon, 08 Aug 2005 14:12:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 342FE139A3 for ; Mon, 8 Aug 2005 14:12:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: nsec3 and opt-in In-Reply-To: Your message of "Mon, 08 Aug 2005 10:29:42 +0100." <53697E68ADB4B4FA7E3959B7@[10.16.32.104]> References: <53697E68ADB4B4FA7E3959B7@[10.16.32.104]> Date: Mon, 08 Aug 2005 14:12:28 +0000 Message-Id: <20050808141228.342FE139A3@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk roy wrote: # > Even though anti-enumeration and opt-in techniques offer solutions for # > different problems (in fact, I see them as orthogonal) they have # > authenticated denial in common, and authenticated denial is based on a # > single resource record type. # > # > I argue that it is far more complex to separate these solutions into # > different signaling schemes using different resource records or # > meta-types. I view it as logical to signal opt-in using NSEC3 instead of # > signaling opt-in by some other means. alex added: # All of the above I agree with. the previous decision-tree on opt-in would lead to this option being hardwired to "off". after all, if opt-in were to be allowed in NSEC, such that the only names subject to zone walking were those not at delegation points or delegations to secure subzones, then there would be insufficient market pressure for NSEC3. so, to be consistent with this working group's position on opt-in in NSEC, it should not be present in NSEC3, or conversely, if this working group is willing to enable opt-in in NSEC3, then we should take the much shorter path by just enabling it in NSEC. alex continues: # The "do we do these at the same time" question should thus depend # on the following two thing: # 1. Does incorporation of opt-in make the standards process and deployment # of NSEC3 significantly harder? (for instance, because it at least # arguably introduces a new state - non-authenticated denial within # a signed zone - for the next layer up) i don't think it matters. verisign is planning to sign .COM with NSEC3+opt-in, assuming that opt-in survives in the NSEC3 design. that makes any pre-NSEC3 deployment "non-sticky" and therefore irrelevant -- since .COM is "where most the names are", there is no point in planning for a lasting population of NSEC-only validators, and NSEC3/opt-in will constitute a flag day on par with "DNSSEC-ter". due to this "additional flag day" effect, there's no reason to worry about the time or difficulty-level of getting NSEC3 completed. # 2. If the answer to Q1 is yes, does this matter (for instance, taking # an extreme example, if there were 100 other showstopper issues with # DNSSEC-bis that suddenly arose and required a lot of protocol # reengineering to fix, (1) becomes irrelevant). the reason (1) is irrelevant is explained above. # Those arguing against opt-in were arguing the answer to (1) was either # "yes" or at best "it will taking some serious thinking an argument to # come to an answer". those arguing against opt-in were protocol moralists, i.e., that DNSSEC should not be as autonomous as DNS ("other zone owners should not have this feature available, it's not enough that i myself won't use this option.") if we're ready to discard that reasoning, let's re-admit mark kosters' NSEC opt-in proposal, and find out if there's anybody left who still cares about NSEC3. if we're not ready to discard that reasoning, then opt-in has to be left out of NSEC3. paul -- to unsubscribe send a message to namedroppers-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 Aug 08 11:39:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29iN-0008OG-SR for dnsext-archive@megatron.ietf.org; Mon, 08 Aug 2005 11:39:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28626 for ; Mon, 8 Aug 2005 11:38:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E29eq-000PfS-Md for namedroppers-data@psg.com; Mon, 08 Aug 2005 15:35:20 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E29eo-000Pf5-KO for namedroppers@ops.ietf.org; Mon, 08 Aug 2005 15:35:19 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 3ED692DE77; Mon, 8 Aug 2005 17:35:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 3D6A32DE6D for ; Mon, 8 Aug 2005 17:35:16 +0200 (CEST) Date: Mon, 8 Aug 2005 17:35:16 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: Re: nsec3 and opt-in In-Reply-To: <20050808141228.342FE139A3@sa.vix.com> Message-ID: References: <53697E68ADB4B4FA7E3959B7@[10.16.32.104]> <20050808141228.342FE139A3@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul, > roy wrote: > > # > Even though anti-enumeration and opt-in techniques offer solutions for > # > different problems (in fact, I see them as orthogonal) they have > # > authenticated denial in common, and authenticated denial is based on a > # > single resource record type. > # > > # > I argue that it is far more complex to separate these solutions into > # > different signaling schemes using different resource records or > # > meta-types. I view it as logical to signal opt-in using NSEC3 instead of > # > signaling opt-in by some other means. > > alex added: > > # All of the above I agree with. > > the previous decision-tree on opt-in would lead to this option being hardwired > to "off". I'm not sure the previous decision-tree on opt-in still holds, since at least parts of that tree was based on introducing (more) delay in publishing the -bis drafts. We are past that point. > after all, if opt-in were to be allowed in NSEC, such that the only > names subject to zone walking were those not at delegation points or > delegations to secure subzones, then there would be insufficient market > pressure for NSEC3. The two solutions address different problems brought on by different partoes. I think its rather short to assume that NSEC3 'market pressure' gets insufficient if opt-in were to be allowed in NSEC. Opt-in addresses zone size, hashed-ownernames address anti-enumeration. I agree that opt-in slightly helps against enumeration (of unsigned delegations), but does not do this as efficiently as hashed ownernames. > so, to be consistent with this working group's position on opt-in in > NSEC, it should not be present in NSEC3, or conversely, if this working > group is willing to enable opt-in in NSEC3, then we should take the much > shorter path by just enabling it in NSEC. I think this argument does not hold, given it is based on an assumption that is hard to measure, and a decision tree that is at least partly invalidated. > those arguing against opt-in were protocol moralists, i.e., that DNSSEC > should not be as autonomous as DNS ("other zone owners should not have this > feature available, it's not enough that i myself won't use this option.") > > if we're ready to discard that reasoning, let's re-admit mark kosters' NSEC > opt-in proposal, and find out if there's anybody left who still cares about > NSEC3. This is very hard to do, since the -bis drafts are already published. I would not recommend updating the -bis drafts. > if we're not ready to discard that reasoning, then opt-in has to be left out > of NSEC3. There is ofcourse the third option: if we're ready to discard that reasoning, let's have the opt-in proposal with anti-enumeration:The one currently on the table, draft-ietf-dnsext-nsec3. 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 Mon Aug 08 15:54:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Di1-0004uH-5Q for dnsext-archive@megatron.ietf.org; Mon, 08 Aug 2005 15:54:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14313 for ; Mon, 8 Aug 2005 15:54:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2DdM-000Ljj-Ik for namedroppers-data@psg.com; Mon, 08 Aug 2005 19:50:04 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2DdK-000LiQ-SR for namedroppers@ops.ietf.org; Mon, 08 Aug 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2DdJ-0003m4-FM; Mon, 08 Aug 2005 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-mdns-42.txt Message-Id: Date: Mon, 08 Aug 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : B. Aboba, et al. Filename : draft-ietf-dnsext-mdns-42.txt Pages : 29 Date : 2005-8-8 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-42.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-mdns-42.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-42.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: <2005-8-8133232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-42.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-42.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-8133232.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 10 14:39:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vUI-0005Mn-Hq for dnsext-archive@megatron.ietf.org; Wed, 10 Aug 2005 14:39:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16428 for ; Wed, 10 Aug 2005 14:39:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2vOZ-00021S-Do for namedroppers-data@psg.com; Wed, 10 Aug 2005 18:33:43 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2vOW-000215-NH for namedroppers@ops.ietf.org; Wed, 10 Aug 2005 18:33:40 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E2vOV-0005EH-LM; Wed, 10 Aug 2005 14:33:39 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Wed, 10 Aug 2005 14:33:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following document: - 'Storing Certificates in the Domain Name System (DNS)' as a Proposed Standard This document updates RFC 2538. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-03.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 10 14:49:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2veD-0001TI-5w for dnsext-archive@megatron.ietf.org; Wed, 10 Aug 2005 14:49:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18085 for ; Wed, 10 Aug 2005 14:49:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2vc5-00041g-LH for namedroppers-data@psg.com; Wed, 10 Aug 2005 18:47:41 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2vc5-00041S-36 for namedroppers@ops.ietf.org; Wed, 10 Aug 2005 18:47:41 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E2vc4-0005tK-3G; Wed, 10 Aug 2005 14:47:40 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Wed, 10 Aug 2005 14:47:40 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following document: - 'Linklocal Multicast Name Resolution (LLMNR) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-42.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 10 16:11:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wuj-0006Cl-57 for dnsext-archive@megatron.ietf.org; Wed, 10 Aug 2005 16:11:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00513 for ; Wed, 10 Aug 2005 16:10:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2wrT-000FEe-Ie for namedroppers-data@psg.com; Wed, 10 Aug 2005 20:07:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2wrR-000FBy-IO for namedroppers@ops.ietf.org; Wed, 10 Aug 2005 20:07:37 +0000 Received: from [10.31.32.42] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7AK6pMN079832; Wed, 10 Aug 2005 16:06:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 10 Aug 2005 16:06:56 -0400 To: iesg@ietf.org From: Edward Lewis Subject: Re: Last Call: 'Storing Certificates in ... (DNS)' to PS Cc: , The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:33 -0400 8/10/05, The IESG wrote: >The IESG has received a request from the DNS Extensions WG to consider the >following document: > >- 'Storing Certificates in the Domain Name System (DNS)' > as a Proposed Standard Overall I think the document is well-intentioned, although I'd nit pick over wording here and there. However, there is one topic that bothers me. When it comes to "content based" naming I have concerns over zone enumeration. (Yes, that beast.) To the credit of the document, it does not require nor recommend content based names, so this isn't a serious critique, however this is something that ought to be mentioned in the security considerations section. I.e.: # If an organization chooses to issue certificates for it's employees, # placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC) is in # use, it is possible for someone to enumerate all employees of the # organization. This is usually not considered desirable, for the same reason # enterprise phone listings are not often publicly published and are even mark # confidential. That is about the text I'd recommend. The draft could go further and state that not using DNSSEC if this is a concern is one option, as the certificates may have their own validation scheme. Other notes... The draft uses "should" in lower case, e.g.: 1. If a domain name is included in the identification in the certificate or CRL, that should be used. This is likely not the same as SHOULD as is referenced at the end of section 1 (the RFC 2119 blurb). I'd probably want to include more explanation in section 3 that this is entirely a "use case" discussion - the owner name of a CERT RR isn't important to the DNS at all, just important to the applications that deal with it. I.e., there is no special distinction between a content name and a purpose name, both are just domain names. (I mention this because of the confusion over the SRV record and it's "Name" portion of the owner name.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From jakob@yahoo.com Wed Aug 10 20:46:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E31Dh-0003wq-GG for dnsext-archive@megatron.ietf.org; Wed, 10 Aug 2005 20:46:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14958 for ; Wed, 10 Aug 2005 20:46:52 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E31ls-0002qK-4s for dnsext-archive@ietf.org; Wed, 10 Aug 2005 21:22:15 -0400 Received: from yahoobb220046220205.bbtec.net ([220.46.220.205] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1E31Dc-0008DW-Fp for dnsext-archive@ietf.org; Wed, 10 Aug 2005 20:46:48 -0400 Date: Ø, 11 8 2005 09:46:32 +0100 From: "Fish" To: Subject: All love enhancers on one portal! Message-ID: <000a01c59d80$883b0070$0100a8c0@msge> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C59D99.ABD642B0" 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: 3.7 (+++) X-Scan-Signature: d9238570526f12788af3d33c67f37625 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C59D99.ABD642B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C59D99.ABD642B0" ------=_NextPart_001_0007_01C59D99.ABD642B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0007_01C59D99.ABD642B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""=20
------=_NextPart_001_0007_01C59D99.ABD642B0-- ------=_NextPart_000_0006_01C59D99.ABD642B0 Content-Type: image/gif; name="erec.gif" Content-ID: <000501c59d80$8686c0c0$0100a8c0@sanya> Content-Transfer-Encoding: base64 R0lGODlhWAIsAdUAAP//////zP/MzP/Mmf/MZv/MAMz//8z/zMzM/8zMzMzMmczMZszMAMyZM8yZ AMxmM8xmAJnM/5nMmZmZM5lmAJkzZpkzM5kzAGbM/2bMzGbMAGaZmWZmzGZmZmYzZmYAZmYAM2YA ADOZzDOZADNmzDNmZjNmADMzmTMzMzMzADMAZjMAMzMAAABmzABmZgBmAAAzmQAzAAAAZgAAMwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAABYAiwBQAb/QIBw SCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKD hIWGh4iJiouMjVMBHwYBFy6RkyJFl0UDKxFCAyoGTAEhmJyeAKQYBDAGDS0AECKaUKSYtEUNLiGw SapCBDKiwMKbncaoRLZWp6dCv0+gE6siFZIhGM8X2Zesw0fOAKAG4dBH5uLHqdi+FyLe6aiq0BCw 6Ezh5di42r31ROGQ5At1LZsydrFgqRt3ENM6g5/UzUM4hJ+ji0S2ATxxgOKae7U81mGIBaQfSMMa FMPIsqXLjyJfyjxjcqbNmziNEGhBShgE/wzQJgF1J6RBqyXliIoL9XAUwlO0xukD+lRdPG0OSRoh lUHjM4RCp74K4MGDK4dL/kFrJnEfwldfIbZzaJRcW6oG4dZEEmxYUI0m+wJrBVdWkX9NKyrVKtAq sW/oojIVYjinZYwEZsi7QIOG5iqZk52LeWhS588zGSdSfbl1zsAwHogGIBig460hhA1AceJbbQEI 4iYWCqABauFEgCMffeuCvZjGZzNP5dy2vNzkeF9r3ov2jBQGlSeePum5XOp0hWlqQMO8tqHPV55T irWo/CLif5GyVx1k9IbU8RffN5mItF57tBEGiyy0qFQQfsENh51rFFZo4YUYZqjhhhx26P/hhyDi c8ICLVyQgQURkNLZadJFhIpWtS0lCYrrrOhZi48RV9tEeXU3mlx/UWXjcXzdNwALCA5xZJLQ6BXC kPLQ6MsHB1yAgggDkKDNis/RcNRXULbDZRK1edOkjzsa+OSXUyzZi4oranbPmeOBGSeO1I0Z5EAE 5tLcLezsVwQBXnYEEVRqGoTSEIjV2NlRNUHAJm5oLQdVJCodYMmTLBJR2Xj1wOmlKChlGgmjPlJW aQN/1hnIXm8EBAyRa7BWRmghjmErG7j6QppLu0oBax6kdPDoMITSIIKT5xW1onpgaZTsDBKw0MKS na16p5g0FBOkkrelqahX7HXK12nV8hT/LTdPyqDAZLg1W9y283a2Urk3DhEjdZPiS2smF7BpWrfI ZstsE6IimPCbnCrc8KiLFgfts6Q+3Iqok+LW7bsPDmowwxuHgq2yStQUo4ruhvItbStWekSyJOdJ 8BKTCMzZzCwrezDC7XIs80oDe0vakS6fBEIK9liilINI9CSKpNfIKeVjyC0qAKlLEyluEkzXJQ4L GDjjdCwXLw3teXSSIjUqXWdM85PsDpVenwfJWyYNGERnWNt0q0q2ATsBcDV6rrrK99+x3NfE4Jqo GDfiECjuRaNrqfxrgY/PSd9hqcabY6DVMYpWoxUZuLlikuf6xbBiQICzFqyrLvvstNdu//vtuOeu ++689+7778AHL/zwVDCtzGKWjyv3J8kX6dfpZB47HqLyJlRyKWSmTrqstAEdcN9IuF6p6/8aQX6U KXrVdFXpZ9W8UwZJdVfNBErm19TE56///vz37///AAygAN8AAdQEIELlEhoGXJekegmtK/kKGoHw 5bZPWGsICfiZbyhmnS29Dlvl0xcMFKClrUCvdAbpCzT2dZAMPOk4CawYBEPowQ0wRYIWNJcDIaO+ Afrwhx6KHRCHSMQiGvGISLwVDfnQKzXgqzsM7Jz5pKcksMUKXlcQYhK3qASY4c1ZLFqZv1L0q33h K3WOwhnMHBIpKZowYzGaVrpqlLKOEf9BjhdEwhm/EcXS3QdfaOshbow1qiGMUYgo8xkOR6YtcxGN i5CMpCQnScnZFeCSmMykJjfJyU56EpOVDKXupmKRIJWyjN4rWhLqAZc7es8fsOCT5mBZhE6aoAAx YEABQqABTNJAl56EQC8zyUtMsgCYl6xbjk4XOz5NBUAWEaU0p0nNalrzmtjMpja3yc1uevOb4Ayn OMdJznKa85zoTKc618nOdrrznfCMpzzn6U21eSJiMTSkvZ7XGRuC72vmwiErKECDrqAmn0kAYTLy +UiJgY8rL7znzRTHvYAoVCcVJBzA9lmLHg6AI9iIIj+8Np/OlOCGE/0nA1c0Lo7OZ1X/ZeNo2kIw QzyBKxk4BGMhYWak25iwnwThCmc+k7abnVQUF11pZ1o6M6HmC4ySgwc9CaHFO1TVCSRFWOjSkNUQ lWeqmxhRiU5ERuV1TxKCvCMMFiCCn8hGZg10EwoPEqb12W0l3ijMLB5Gw4E5THl8Wl9d6TfXwh5v THxRUCzeATS3KC9hn1Gh+rgHVmleFRw+vQNl4deGy/qhiVIAbRq418RoakyHlU1D5K7hHuqMK6PI IMIYgdEyXxGSTbPFYbGo6CLZ0stzk5DTujRIGQF1EV3WCgAIJkDFnCZrWd1ZI82+pxiXPndnTtia a2mbLVciS7GGwWMvpKvTJV7Fu4bV/6e5CFW91JJhTmA5FdU6uEpMQC1w84XvF3/BN3sGgEZCZBxR /CulwyFBwJUKh2HuCwsEnzUuAcYaoNamUQfNdL/sgFri/hkZsz1UTcWAGoHZVgyvORhyaBxxYuDC Xr3NwsMq9qx7x+k6NGZIxjPOsY53bBOP9uYmkbmcHWBFCkjxwlft5QOOGxEsfvmlYY3dFnnhqygq 3cxGMOiIjQB1ntUyKqOicsiUsZeKTWH5GjbqkkwfBig2WtlGj9IyYp28nD9IFQxLjuSdv/DRf/JY Q2vpxEwD6bKVoYrOinEf+Eg53N6idzjbsF8T1LKuyn2Y0MxDa6GR5xv5tJJVGt1Vg/9awegeFe5H 4WMjmZWpjA8oAGyLStaXqHxoVMuI1sVp7TgI+7bqaXfXw40dOp750qKQen5vaW2vMz2VUp8Dfx8S LRelHYgmb8Haf/7Doo6kHg+vz7gmuw8r3roO7jirWZkBzxL+490jsQvcHs4P6DDBHmUbklZju95j vd20E5YJvPQ27zp0o51lfFXe43IZu/sx8IrZ+CvmNmV/JpTvr9yn4mnpjqWF/ZazZYID+pIP6Ww9 V3d7Ci1HmtScQJ7fCzw82zCPucxnTvOa2/zmeKD2ZwV+Xn3x/AhP5G4Dz9WZVJncDdh2Qp5xPhMv 5uVOYoQ6KifIwdFUfczVG7nVi/7/6JxRK489ny8j1131oFuc6lw/XpJ3W8jyllXpPUMpR8eu3qc2 lOl4z7ve9873HZOSmZUGvK9TOemM7ih02wuX5JaBFBLsOddI/lwKU4wQyRZayDdl9l2gecK+e/7z oA+96GtuvERnWuKKDvfzVPky6ZmDeuFzo2yP8qkHm0/X74s9E8SX38tp2HVAQRFxIh8P+3E8fiKb H3VNL6NnQHv00I++9KdP/fwVUB4IXPMC077DddSUuHU3PNCEn1J9VX1gR3Uqanjap03m8paYLOYl f/lJTI4Akw54wSXzr8kWRlS9DzRUNjUw/gR+FwVVPJRk1SdzX0UF9feAEPiArLaA/xRYgRZ4gRiY gRq4gRzYgR74gSAYgiI4giRYgiZ4giiYgiq4gizYgi74gjAYgzIIc0nnCKJVUZlVOr/lBkt3E5vF DDkIDgShbQ3zcwIECa8GFEqTepxmaf02KVORVwvyYor2hPXDaUXxHayHHAHBQji4GRVUe0T3JcSG VTxRFmeBesZ2aZp3He01bJtXbMVxbG44aFCQD8q3hdaTecQ3DnaEHHDxFCqzfOnlbMdThX4TSfh0 L/SSW3G3aEjSXR5UDFK4WG4nEJEYM253dOxRPWw3KV54G/mQiZXCXm9zfuXXcLsHbo3Ga74SMljj UtEjiTnVDjZjXR9zagllFbW4R/9eN0eO9op19IfcBV10xDF0J3RsVH4mMVsso4Bc1IN3oHNnUIMz +E2gBjWs4jgPoV3mY1+tEDgOBhL3YGAk92gtphl7U2KwNY5w0xS/Z2OH425luA4UJjgSFj15o45U aB9o9jh8441z6GfXqAjBFQGEcjGNlm5rhx270RsGVx0IVx+yxXOm9W+uMIXFIXAR2VpC8VUYlwu0 0hdHxw/wZW6JlZGL1SAet10L53PqVpAgUmMEOWM0KZOtUXs7oQoitTldZQSykk9K9UXr40JP1X3E BVFHGXYIZWvXx5NpJ0HD9wk/1npr9n1JmWyxAGee6JMx1VRaqX54klNQiSBDyQ3/qThQBXUBkcVB ZwmANZkUMnVl3NeUIlSTogcJE7AsG7ApZtUNsMWH0cQ6K9RtLmOIMZIUeohCGgZpYXMX0kAN1tBv tFSYdlGHCIEYwuYO8GCIlAaNj/YtgYFXANeAmukRprWLs3EyqNl5LviTZoBj0tgasImTuZIwi6ma YjCbIxGEjhAsvFkG1giDGDMMu4Y/oZgMSgULrMBWbpUM+yJXjglZbweUSCJ7HvRXBVJXJcV959Wc bYUBb+VX49Vth3Kd06UnIiEuduhagWVXoSlk0hlo1amD20Ke5yVqiVIUzAlw7Dk06GmbvROcjkCg AnqgCJqgCrqgDIpO1EgsmNcE/w+KBwaaBQ9aoYIwnDCXjYRBb+yoUrQnH9q1KOY4KI21PA5FJ8QH JgD5oUsgkK6iogY2lefwAXsJAA8gASXkjtnwKSWKH/lImU6movO1kaLxC2LIM81yOC85U/f4o8mR j9yIpCHqZz9xmpmzOQ14VrgWMXsYozHhbsqFJyO3pSp0NElDjKJTWJcwJ2haZnzUOWJ4pQwDmiXB lghZSC8ppBW3L+O2UD/HkBRpYURRbyWjpcO1p120EhM5kQfSC4qKMPIlDlrSkfD4JZFaICg5HSmn afOCJp5GlMLRmCFpBBNppLkgqoRjqP7BkdgDkoE3IHyhcY7ljwHAcmeFKwYXE/+IcWeUs59HoHWb wAKgSFSveircpqaJmBirNSfIygIiJ6dogV8PgaFdYHZgcJPh9HgNKghKaaymJpbhVxB9lDM4c4BI 2W/aV66ORpYhVZeyaJVguX1McjMFOBpYma4UlBJz6VJZVRl2eYizh1bax5/eJ4ArehgoB3YZBF9E tYSYE7Ebxi3+JK4qin5Mga648X21iLHkynVvGT5cOYkP5ZUEO68GK64UK3c4o1s0hbDvMQiWSQ/2 plFsGmmIlyoRmZvnxSMxG4y9t288a5oeuQ3v6TkCm7TMpxP3IQv4lZom9A5H4Zk1C5/BOjoZ46xo VQl9AnuslpqyBKz/cLTllrD/jxa2fxmhdVKPACO1SIVsBvGZTeBMkAm3jWCt7lSbw7Olu7lVcKC3 +sN4XnpOeAs7agsQWBQGGqp0dBlngohmtSVYa7ZldnIjjdt229kpxZlGTNIwgEK5aWSEtFMqMqAp gHOiVuu1TPsNx7kZ6olu5vmK9MJr9PlrAdqe9olanOVaMDqB6FiafIUj4PmccNUd0lkn1Em2WvW6 76G8k0OryAe5mAtcR7a5d4S5wkpXUckpilMZjKe908sygflDhbtshmuniluVvtNn3dq+7vu+8Bu/ 8ju/9Fu/9nu/+Ju/+mtO1/cM2Tev7JpPFpuKOgVmp6Orr/or2VtF3dGwBMx+//RVixqLUSQkh9OF FqySVv53lAL8skv5UzRQgDmFrk1Jo/sLhHUoeO9xSoO3elJwClulQgqMnYjzMq9UXPQVcnTzvQnl eBnTSkwwFo27hTOrwviwEMnnhpzHsycMfeXbxFAcxVI8xVRcxSwxoaHFc6Qlur6VdjBDw1s5dOzK BotrtVZ8B6VHkcAmtKc3dRR5PVvIQjjMhzqsDePrKZq4lUskLr3LhYLWhGpraX+ncliYCs93xnTg dG4XdWHkxnVnY6ICqhvkGcAYdraXjHpUdnMWkmM8xoPEW4d0uInEssWAyc54d4icyqq8yqzcyq78 ytfYv6nwvwoUwFeJsLVYL//hu7Szck8JnHU0vCPkJ4sQLDPp58HrV3WJVcHIIcc/WxsZ3JBGCUO3 /MEbFcKkbJyRSM2vY8Kw3K77YMQfacSr+8bR0Akx3JK3N2ktAMQtR0toCzC01HhmUnkvRwxVAmdE bM+e6ru6KSP1uLPffER8WwhPPNAIndAKvdCDEIEO/dCgxNCShMVRQNFZsEkOsCL6d0kMtNGe9DAe vVLIlExoUMbnKNFjkMah9j7jnHqODLW5QHulqD24p6y1NgSc5Dr3N3/IJH+e5ADDhEk3k0v9V1hQ AcigKcjKR8iI+F82hdJeoMi6LFxmNdX1aaJo9zrzAUciilxdUkcgIV5EoEn/Gb0iyNTRxER/+OfR ad0ZI10AB3Fb3xDKdjrKsTgzpkwvqAzVSATRfg2BfB3Ygj3YhF3Yhn3YiJ3Yir3YjN3Yjv3YkB3Z kj3ZlF3Zln3ZmJ3Zmr3ZnN3Znv3ZoB3aoj3apF3apn3aqJ3aqr3arN3arn1zJn0IvTIwBnQzXBwH B20ItP3UT7Db0ZC4eSe4k/rCwN0aX1gy8qXS4HvbcIe+q3O4cfCDVSDdQDmEz+3co5Dc9zxAyoU0 cOpQAwneXhOPbJi0DpKOEbCOoqC3/uGi9BiEY9OYtkfH4NxegFtK/OYECxaO6oJhq4C64VOlLMlh rTk3zgNhMBaWIXCPSqCY//6IqlFqs5ZsPlUaNSkCYFpJ3uRY4La64BdOYuvdL3fsQ6RrutSZvEjs Z9LJx8DLneBwu8Frx35Gn3Wcw0B7vBMePeEI4Nm1VuEpG98iWe3FJ31cZ0XOpdJyorg7t+rwn82C n/QNlClOjHSS4jkEvfGJF5nrSL5JRNsGretNK006cWjkqB5WiXsjcKe6pyRpRd8WIF0HtOd1qr2N q5b34KVaIAQHkQv5HWtH5v2s3Lw84F3k54NqmJ+qi42xGQbeiZznI9QNq8JA5YWKIIB+qiaZ4EvK 3CiY23ymvucLBdz6XtBtIaNexZ7OB9pKdt5pBqv+IdiabaluBhatuMWNE/+iwumGrZPqQq88YbIm JBd9VsxJNbIIuEoj61wwQFAGxTbxqhMcVJZvYq+3fuwN5SBvqbLF/DLLvpZExYzv2kAxNFKgOOKM vZPY8RNqGN5Ad4ZmAWqewh9Zy+HNZ8a/q5IMUsgZN52P22+IaBwpgBZBlmQLjOZYYreuZXxLwyZJ atl6yZd+GbOA+U+RSQDVgFbzXDqqBiSuKbFYPRj43o+jkLOO6bzmbEi7gOXpBedfilEhb4gtHbWn vtnNWr2tSIi614DihcnkZdXHJYnzZfCXSHRf1+sS/4hKMEacSJTSFdZenZJ6lZVV7Yyu+IyuDbg7 hvWiLZu2zds82PXCUur/XTDrSuT1fKHrVeDbd0Qk2GLuGehjhoIF1K3oZjD3J40GS0b2WRCceTb3 hKndeBl6HJqG76gKRx6Mh0OYE6Jh/ZXgIcYmAQGlo6pq/j3g+w04sueOnyFimm6wdB+0A+6kH84E aeLfp3Y3+5jemHBi5eiiDa54kCESJar10PdRJGIiwjdcQn7E1xEmih8/gha8Th6M+uDidCUw68Li zimeY3llutYJww95n79M2RD92CWhAE4co/ldIV+8dUadSAH76QX+Ob6AB5mQHTN8gsr79zYbMP0V xgXhh85aLI/4rtqjRsbGKeqQ2gEEAOFQGAiJAIFLKxliKp8XJKAhMyiR/w0aMyklfr+EWQpT9FKt WOq2WQa/hQRrMeRWltVguSEOMzSYIESMkKDMpoYaZiLg3gZWGIn2hozcEhcbMzU3OTs9P0FDRUdJ S01PwSpRQ1VHW1dhY2XfXmdtb3FzdXd5e31/PSFo5oDpLFnripVvhYmXn6Gjpaepq1HFIoces0Ox M2utT7fDcwdU+MhLzdHT293frcEb/IYElWiG2YXG4e6IBk4cuIDP2QAW+DBVEsZGiJZ8TTIMxATA IEJuevA9NBKRxsQ1DxsRyOiMIqQuxwAaEEnwypmGfip2vBhmJJ+NEiPd05iMypM6C7no3HAOzsKM dgaChBMzYYgMIWRCxP+ZiGWcmmbwDdVH5GbUVoAAEIBBgUbEhEnndJ3IdCY8t299gevZEFFYkiXb JmoRwIOHP4gmdaFHieedPOvAKRkczOexLlPWcYLAZZ/Jnnz9NqgLYPLjly0Xd+oMjl+lr43NYGgV uR/Pyjldf1GsbzWkxGdY10NNkSit2G0aMhH7J5CI0nVuh4a7nLkuuZxFEKAc5y6/pSomYCAgogK7 wFyPAD+Zh7Bj8Ju5LhEy+jf5b+o5T+dnLvv27obiHxouO3w/+OwdO041ngBMbb7efEPJsuf4K4Sn PW7bDL/ODtyqPP7c6Gw4sAQRkMEm0GtOxBFJMSIjGgabLYzqLGtkNPj/qEMnJhqmaMWfj2Qi7SB8 QpQEIQlY2Ou3hjLyCKOOgKTMuhe5WGmGJM0YbMYeh3AySbl0ImYlEcCy8QI8oJJBAQTfWIlGrJQC Y0o6OsCHnuccisrKIJsYZkwLjTmSS+H84LAQtGz6bU067iLR0EMRTTSXefBUFJYPHY1U0kkprdTS SzHNVNNNOe3U009BDVXUUUkt1dRTUU1V1VVZbdXVV2GNVdZZaa3V1ltxzVXXXXnt1VVvmoO0E2Bz EfYTY5chNkFUc/N1VUEk4cKhQtPDp4RzskSH0XqmmLZR9xjNVjywijqRBjAxAIqqNGUDVJsd14KX kdPWdebG1jAhIAYS/6yqqhUIJvI2EzOpJQyfDvygV9x1UbyCQCM5YateduJMmKcunZqKSHZp8vcn fIJKSquBXQABNjy8cC+sphx0zMYP2OksT/Bchm8/R+gUIoGV5w3PiIRgZhDamSFIo70QgI55uvU2 I6Dkk3mRzggrIFANNzJp3gfB78jVzDPevj2DUQ8vXhrDrMe7utEqiVGRkgtCU1jtIizIq4gPxlTg BAX4/YK9iCw5DOuizNbGsuHoZRsdlW8yjxO3D9G6JQnLFu9tyAZ/o8DxeGr2i5QiM1Gpld50bZvE CoNZtwvR/qIKCqgk5OzXAsCbBdWCHpJp1uNLzHbclQZj6H1OMCB03f9nqX0CLjcI2qVMKlScCEGk i/xxKfYjO8PCeRfPsOc3+Y4wylteLwoqNaldJSsG4HfCxiBIEXz/uJDZkcMt3l6StsFXSDlQZMe4 /hFoN5e7Xv12c4fo0SIpbnKYG8SHFxhB6Gh2UJ35umc5v3GvHnGbYBqc54LcOQ46rMOC71oiwuD5 DRE6cSCyUFE0h1EmThADj522RhLI4ciG6VnMwrZErpBkpHwn2VhUBkaMQQ0qLDwSYg0jYRD0qU8b fZuTkFAWsCLZ7YqNqAgMFkCPIE5HfHEyWhZ7VrB3EZEIUDziHMaoQYb1sF9PCpKXwIRDPN2rd1Cx SJ2q0kQe0eFEIQv/JAYJmRGLFXJ6HDQYyPp1piRcsAoP5A8jRdcwQL6Qks6wXya3wMfJgNKR1cAP LrblLHLczBYwVOUrP+XKXugEYspShud6YUtYdgKXz9Bl6zrVS2fJ8hfWsYYwXYU6Rm7SQSdyUI1U l8lFgLKZh9QEMtOBJeTNbjnYPNY23zE1PsTPknP5WQQCULeGGMlE6AKAAGySsiFVkgr/s14l22k5 Y9plcVBxJz1T+QZ4eiafqiAnZwp2znRGAqD0UMRFGuqdtqWODxGFQ2BMI7YzBqcJ01Rna0g4PPtl MAAgSMETnEc5lxVmfh0cp9E82jM3kOugMkSWQj8aI5ci1GHnAs5N/2OTB3qWaaJW69ZGzYk0dOZU c/SwqUYn1xCYLjUbfFxObdBZOdStFCkoy4iSDhIUP/6RqP0cUFcNdxGMsnRAJ6JjF77qvS8tMBVH c2tWV3pX6UluoZtEYln9sdazchSoIa1Rf27owEn+QQYHuKBVFqnYV4z0H5ZBTAU5usCKOJJBgakQ HuUI0v2ZNSRp+BI/jaEwcKZVcoIV7HP6KiIjROF8ayggVY6BxwCqRwAImNlDNyFUpN5rn4JNDRXe Or4uJPBLhhCnaF0HMS04Brh6IIlYHpCN6oZvDEg5alS1cNtGCA0RBolbe1RnkDRwQHFbXU9C1SPO CNl2uU2wQm9ntv+ssprBJ8M9rcr8Uxfhrm1lZLinabPAhpvGNwQIlmpU0VDOSBFzl5eiMK9YmYsM Q+PCvupwhSPVDAK/Mk6lPEWJqSFiELfjlysuRYu7mblZeNPFNf6GUhcLV44R5ileyZhX3FXPmCGB YBRTpEDqElAwCEyKD94IVCayMImpliMeEdg30wVJHavRKPjwKkjEQhazMNSa6UFJ8Yq8D3lxxlyW uLJQZDxEj2WZIXAe8Sk+2TlsrTZPapiv5kr5lfyBaHrlzRkAdvbndqnxVrVTwO3UJyDong55XJMW el4kIbHZ82usUUQKDuuGbXgIbrTRanvm5gk8Shq6K0LHhoojuEb/AQIzf9mgYLZSC1mvJs6b2Jxh 9HxnU+T5REhNnx+LeiTlULauKEONsoYmO25WSbEuVp8SVMjqZseosyShXsgQ+LX0RIfT4m6jC5ww sz1om9D/Ei+AVc1Wdk97r7CGDrzVhB3tcKcl4T5Pfs2NF8kd6z/MxQBdmUEZXkv4xhA09v2ywWx6 V6LJhd4pMNXUol1SMcJbXpsR2qTJbtOm1NRGUs7MuLiSawKKBpnpuUBebXExMY5w2qJ9RwzahclZ kjoNS5+Kc8S3MqmOSWKiIHvuRhOJiSjP1cQVdR6mO+EcPDpssLDzM7PLnojT0uwZ13tqTYljvBUi GcRY6zxWn4A9/5P2ugCjbUzvYijZFB9Ghd1bhfe4753vfff73wEfeMEPnvCFN/zhEZ94xS+e8Y13 /OMhH3nJT57ylbf85TGfec1vnvOd9/znQR960Y+e9KU3/elRn3rVr571LoaxW15PS7Um95p9oxSN W195M9Gew2PNFxv9CgOBmEuTvgF+KPb5YjHZ/t/BRew9SOgL3D+Oz7kHscuXPIdw+RM4EcUpN7jG e/eckoIhLeXYUSuEgbqnuMm+3r4c0Wtt9AYgAok+1Q/qfaXGtihOdXCE5cKijMj6/g6gvAyUpomt EBCvLsr9PEEkhM90bMP3uAH9CK0B2cGF5EPj0k/NGOKaSgCx6P8AfZTLa6xqdijtrpClQoyLIsIq kciK/wiw72So+9iJrZCLG0YOt4KLvWLEGwIIeSzQBe1prf5kA9WKGPArtIhgZ9pHiEaQUPZIBE8Q PGhrnXSw+pzr6gZsCb+C92YwDGWlfZRB78TwDNEwg9JwDdmwDd3wDeEwDuVwDumwDu3wDvEwD/Vw D/lQD19PFGIvKWoJDJeC+SRl+vrw83bPbqQhk0jQizhQ+fjGN9AnXDYNwpYBEY/t/hJx8LDPdbRv kf4pFB0mpkbrEhgRkfZL/eKpLtqPtN7PEAfuOmQEElgj+aSQMxyKFL8vE2rq//BpnkjxuDpx8QwQ 5tAuAbtqAXf/kAkbpLQysIGQ0NX+4QU3YQBCkHy8iP5skRvzAquYsfpY0P02CwaRSAaLEfFqUBW2 S67KoB2bcQ04kQjxxAjri7VO8Z18yxl1hiJIAAov0Ok+Q6gSpqXo4ApzEOPoB+e6cB+/MBXTMSLD gQyLwQwl8iL/ziIxciM5siM98iNBMiRFciRJsiRN8iRRMiVVcgb/8B1aEhco8vbkbyVjZRHdweuQ 7rC4bvjMxZ5GCiCTZfnaqCArESHhah51QRMbjiY55RPbiBe5jx2h0hT3KiHT53nI7+Ea6SqngJW+ Y/3O4BdLkapYMeDaBf5mERfFYxzq77TG6+p0saKmkixdxP8g/ywYzUMAq5ApKeUY22qLdCsZGXAV iQkCD0ACs+rmVmcTm+U7NFDgwAZLpPEasxFsXmO8RAYSTNAtJ20CVVAcLescWrAc/SrKmIovL2Ud kwEecZA1SYhrfCp9fJCfgNBnhNDEmqiWJuoI60u+joY3G8EJ/1FaiDIXt+1t7m+27tE1D4ghocoL L4YQUbMPN0wdZJEXNHI6tRMOUExRsnM7wTM8xXM8ybM8zfM80TM9F68A2LM93fM94TM+5XM+21M9 7VMZ6DM/9XM/2fM+PfIlPwFAT0E+TYA/DZQ+gUEp/dNXbDIdfhI3bQE+aYABCrQ9HSAGGKAALmAE +PMCNIA9L/80Qx3gBd4zQWeyE75zQQ/xdrKvokSx++ZSBsMPIvPAK50BLKdALHvxnVrxC+DzAmKg QtmTBTJ0SIuUPkPgSAsAKhgAQ0uUMOYg/2L0NP3GLgcsAIdxAFWUVfwyHJdRMJsRhiiOTBxzMj9r SB6TCAg0BDi0AIi0Pd+UPlNASSGgTYFUSdEmBQETNKNINMnRGheQbiByS0VFNd/xBtGKOVdRHofl r3xut67QN1cKOIfgPYvUBEYURJ10Q9uTSd9zTt/zAki0ABxgQt3TCpcTUZtTvp7TIaNzUAkVDauz Ewj0QG0VPhUyVs2zO0fhVn01P3NVV4VVE361WONzWJE1WZVFdVmZtVmd9VmhNVqldVqptVqt9Vqx NVu1dVu5tVu99VvBNVzFdVzJtVzN9VzRNV3VdV3ZtV3d9V3hNV7ldV7ptV4pJQgAADs= ------=_NextPart_000_0006_01C59D99.ABD642B0-- From owner-namedroppers@ops.ietf.org Thu Aug 11 01:05:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35G9-0004O6-HB for dnsext-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:05:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24423 for ; Thu, 11 Aug 2005 01:05:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E35AB-000FnU-Rn for namedroppers-data@psg.com; Thu, 11 Aug 2005 04:59:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E35AA-000FnC-Oz for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 04:59:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7B4xIq25751; Thu, 11 Aug 2005 07:59:18 +0300 Date: Thu, 11 Aug 2005 07:59:18 +0300 (EEST) From: Pekka Savola To: iesg@ietf.org cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Aug 2005, The IESG wrote: > The IESG has received a request from the DNS Extensions WG to consider the > following document: > > - 'Storing Certificates in the Domain Name System (DNS)' > as a Proposed Standard > > This document updates RFC 2538. The abstract says "This document obsolete (sic) RFC 2538." I assume that is correct, not the "updates" in the last call announcement. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 Aug 11 14:05:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3HQq-0006rF-3e for dnsext-archive@megatron.ietf.org; Thu, 11 Aug 2005 14:05:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17047 for ; Thu, 11 Aug 2005 14:05:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3HLQ-000OHG-E5 for namedroppers-data@psg.com; Thu, 11 Aug 2005 17:59:56 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E3HLN-000OGk-Gd for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 17:59:54 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by albireo.enyo.de with esmtp id 1E3HLK-0003Bh-Aq for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 19:59:50 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.52) id 1E3HLE-0004hj-2d for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 19:59:44 +0200 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: Migrating away from TXT records Date: Thu, 11 Aug 2005 19:59:44 +0200 Message-ID: <87irycqrqn.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Someone apparently told the SPF folks that when you migrate away from TXT records to a specifically-assigned record type, you have to perform a check that records contain identical data when both types are present. In other words, if there is a domain name for which both TXT records and new-type records are present, an implementation MUST check if both records contain the same data, and it MUST signal a error if this is not the case. Unfortunately, this is not a very good idea. As long as you only query your local resolver, it is *not* possible to obtain a consistent cut--which is necessary before you can perform such a consistency check. As a result, the check will fail sporadically, for example when the records are updated, even if the update to both sets happens in a single zone reload (or whatever means you use to publish DNS records). (It turns out that the SPF specification assumes in many places that DNS inconsistencies are always permanent and never temporary, but this peculiar approach to DNS probably doesn't concern this WG.) -- to unsubscribe send a message to namedroppers-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 Aug 11 15:30:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Il0-0000LJ-Qc for dnsext-archive@megatron.ietf.org; Thu, 11 Aug 2005 15:30:26 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22220 for ; Thu, 11 Aug 2005 15:30:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3IhF-0004qr-TN for namedroppers-data@psg.com; Thu, 11 Aug 2005 19:26:33 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1E3IhF-0004qd-2P for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 19:26:33 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j7BJQHLj008682 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 11 Aug 2005 12:26:18 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Date: Thu, 11 Aug 2005 12:26:19 -0700 To: iesg@ietf.org X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 10, 2005, at 11:33 AM, The IESG wrote: > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dnsext- > rfc2538bis-03.txt Sorry for the late participation in reviewing this draft. While dealing with issues related to MASS, it has become apparent there is only passing consideration given the impact user-keys may have when published using DNS. One suggestion just made on the MASS mailing list, that could actually be encompassed by the current DKIM draft, was to utilize a wildcard for a key record to permit manipulations of selectors as a means to revoke a key. This suggestion took the example to resolve to not only the user, but to each and every message sent by a system. While this would be easy to implement by the sender, it may introduce undesirable burdens to the DNS infrastructure. The performance consideration in this draft only concern that of transfer size for UDP or TCP. Although this is merely repeating that of a prior draft, in light in ongoing work, it seems prudent to offer additional advice regarding the effects from a large aggregate of actively employed keys at levels involved with email. This draft discusses the use of keys for email. However the scale of email can be enormous, where user-keys, such as those specified in this draft, could dramatically change the average DNS load carried per domain. It would be beneficial to include a general review as to the appropriate level of key use in DNS. ,--- |4. Performance Considerations | | Current Domain Name System (DNS) implementations are optimized for | small transfers, typically not more than 512 bytes including | overhead. While larger transfers will perform correctly and work is | underway to make larger transfers more efficient, it is still | advisable at this time to make every reasonable effort to minimize | the size of certificates stored within the DNS. Steps that can be | taken may include using the fewest possible optional or extensions | fields and using short field values for variable length fields that | must be included. | | The RDATA field in the DNS protocol may only hold data of size 65535 | octets (64kb) or less. This means that each CERT RR cannot contain | more than 64kb worth of payload, even if the corresponding | certificate or certificate revocation list is larger. This document | address this by defining "indirect" data types for each normal type. '--- -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 Thu Aug 11 16:22:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JZJ-0003vj-9L for dnsext-archive@megatron.ietf.org; Thu, 11 Aug 2005 16:22:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25531 for ; Thu, 11 Aug 2005 16:22:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3JWR-0008yI-Ov for namedroppers-data@psg.com; Thu, 11 Aug 2005 20:19:27 +0000 Received: from [81.228.11.98] (helo=pne-smtpout1-sn1.fre.skanova.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3JWO-0008y2-N9 for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 20:19:24 +0000 Received: from arport2v (62.20.229.55) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 42B813B0007DF00F; Thu, 11 Aug 2005 22:19:20 +0200 Message-ID: <01b701c59eb2$5b41e6a0$8217a8c0@arport2v> From: "Anders Rundgren" To: "Florian Weimer" , References: <87irycqrqn.fsf@mid.deneb.enyo.de> Subject: Re: Migrating away from TXT records Date: Thu, 11 Aug 2005 22:14:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Florian, The originating bad idea was to start juggling with two RR types, one well-known and one to be assigned. I.e. it is a "system error" forcing people to create a new type if the actual application does not gain by that. Such gains have AFAIK not been demonstrated. Probably the ill fate of "http://www.ietf.org/internet-drafts/draft-snell-dnsepd-02.txt" in part depended on the fact that the authors did invent not less than TWO new RR types without having them registered before the initial publication of the draft. OTOH, IANA requires a draft to register so maybe they just got caught in the DNS catch 22. Therefore I stick to TXT, and I'm proud of it! :-) (computers don't feel pain due to lack of esthetics) Anders ----- Original Message ----- From: "Florian Weimer" To: Sent: Thursday, August 11, 2005 19:59 Subject: Migrating away from TXT records Someone apparently told the SPF folks that when you migrate away from TXT records to a specifically-assigned record type, you have to perform a check that records contain identical data when both types are present. In other words, if there is a domain name for which both TXT records and new-type records are present, an implementation MUST check if both records contain the same data, and it MUST signal a error if this is not the case. Unfortunately, this is not a very good idea. As long as you only query your local resolver, it is *not* possible to obtain a consistent cut--which is necessary before you can perform such a consistency check. As a result, the check will fail sporadically, for example when the records are updated, even if the update to both sets happens in a single zone reload (or whatever means you use to publish DNS records). (It turns out that the SPF specification assumes in many places that DNS inconsistencies are always permanent and never temporary, but this peculiar approach to DNS probably doesn't concern this WG.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 11 17:59:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3L5I-0007Ak-Gy for dnsext-archive@megatron.ietf.org; Thu, 11 Aug 2005 17:59:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00471 for ; Thu, 11 Aug 2005 17:59:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3L0z-000FUh-9M for namedroppers-data@psg.com; Thu, 11 Aug 2005 21:55:05 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E3L0y-000FU5-Fw for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 21:55:04 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j7BLsw3g003124; Thu, 11 Aug 2005 14:54:58 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j7BLswi4003121; Thu, 11 Aug 2005 14:54:58 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 11 Aug 2005 14:54:58 -0700 (PDT) From: "william(at)elan.net" To: Florian Weimer cc: namedroppers@ops.ietf.org Subject: Re: Migrating away from TXT records In-Reply-To: <87irycqrqn.fsf@mid.deneb.enyo.de> Message-ID: References: <87irycqrqn.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Isn't it my understanding that caching server will carry data even for data types that it does not know (in fact caching server does not need to know about structure of most DNS RR)? If so I do not see anything wrong with checking to make certain that both SPF RR and TXT RR are the same. I note that there is an assumption being made that both SPF and TXT lookups will be done through same local dns resolver. On Thu, 11 Aug 2005, Florian Weimer wrote: > Someone apparently told the SPF folks that when you migrate away from > TXT records to a specifically-assigned record type, you have to > perform a check that records contain identical data when both types > are present. In other words, if there is a domain name for which both > TXT records and new-type records are present, an implementation MUST > check if both records contain the same data, and it MUST signal a > error if this is not the case. > > Unfortunately, this is not a very good idea. As long as you only > query your local resolver, it is *not* possible to obtain a consistent > cut--which is necessary before you can perform such a consistency > check. As a result, the check will fail sporadically, for example > when the records are updated, even if the update to both sets happens > in a single zone reload (or whatever means you use to publish DNS > records). > > (It turns out that the SPF specification assumes in many places that > DNS inconsistencies are always permanent and never temporary, but this > peculiar approach to DNS probably doesn't concern this WG.) > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- 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 Thu Aug 11 18:20:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3LPV-0005D0-D4 for dnsext-archive@megatron.ietf.org; Thu, 11 Aug 2005 18:20:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02635 for ; Thu, 11 Aug 2005 18:20:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3LMG-000HRx-3a for namedroppers-data@psg.com; Thu, 11 Aug 2005 22:17:04 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E3LMD-000HRW-CI for namedroppers@ops.ietf.org; Thu, 11 Aug 2005 22:17:01 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 11 Aug 2005 18:17:00 -0400 id 00578538.42FBCE5C.00006861 In-Reply-To: References: <87irycqrqn.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88862262-9B61-45CD-90DB-470F6C60066D@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Migrating away from TXT records Date: Thu, 11 Aug 2005 18:16:59 -0400 To: "william(at)elan.net" X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 11, 2005, at 5:54 PM, william(at)elan.net wrote: > > Isn't it my understanding that caching server will carry data even > for data types that it does not know (in fact caching server does > not need to know about structure of most DNS RR)? If so I do not see > anything wrong with checking to make certain that both SPF RR and > TXT RR are the same. I note that there is an assumption being made > that both SPF and TXT lookups will be done through same local dns > resolver. Imagine: 1. query for example.com TXT. 2. example.com TXT, NEWRR contents change. 3. app queries for example.com TXT, example.com NEWRR App will see TXT cached at time 1, NEWRR from time 3. Also imagine: 1. app queries for example.com TXT, ttl = 300, NEWRR ttl = 600 2. example.com TXT, NEWRR contents change. 3. 400 seconds later, app queries for example.com TXT, NEWRR. App will see changed TXT, cached NEWRR. -- 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 Aug 11 20:21:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NJ5-0004J6-Qx for dnsext-archive@megatron.ietf.org; Thu, 11 Aug 2005 20:21:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08375 for ; Thu, 11 Aug 2005 20:21:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3NEz-0000H0-DH for namedroppers-data@psg.com; Fri, 12 Aug 2005 00:17:41 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E3NEv-0000Ge-In for namedroppers@ops.ietf.org; Fri, 12 Aug 2005 00:17:37 +0000 Received: from drugs.dv.isc.org (localhost [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 D11DB67800 for ; Fri, 12 Aug 2005 00:17:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.3/8.13.1) with ESMTP id j7C0H9HN035374; Fri, 12 Aug 2005 10:17:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200508120017.j7C0H9HN035374@drugs.dv.isc.org> To: Florian Weimer Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Migrating away from TXT records In-reply-to: Your message of "Thu, 11 Aug 2005 19:59:44 +0200." <87irycqrqn.fsf@mid.deneb.enyo.de> Date: Fri, 12 Aug 2005 10:17:09 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Someone apparently told the SPF folks that when you migrate away from > TXT records to a specifically-assigned record type, you have to > perform a check that records contain identical data when both types > are present. In other words, if there is a domain name for which both > TXT records and new-type records are present, an implementation MUST > check if both records contain the same data, and it MUST signal a > error if this is not the case. > > Unfortunately, this is not a very good idea. As long as you only > query your local resolver, it is *not* possible to obtain a consistent > cut--which is necessary before you can perform such a consistency > check. As a result, the check will fail sporadically, for example > when the records are updated, even if the update to both sets happens > in a single zone reload (or whatever means you use to publish DNS > records). > > (It turns out that the SPF specification assumes in many places that > DNS inconsistencies are always permanent and never temporary, but this > peculiar approach to DNS probably doesn't concern this WG.) Why bother checking. Just use the new one and be done with it. The code point has been assigned. The vast majority of servers and clients will handle the new code point now even if the servers have to use TYPE99 initially. It's not like SPF is hard to hand encode. Note there are already patches for various servers around. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 12 03:03:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3TZP-0001D9-LU for dnsext-archive@megatron.ietf.org; Fri, 12 Aug 2005 03:03:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07137 for ; Fri, 12 Aug 2005 03:03:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3TSM-00026M-Ps for namedroppers-data@psg.com; Fri, 12 Aug 2005 06:55:54 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E3TSM-000260-1R for namedroppers@ops.ietf.org; Fri, 12 Aug 2005 06:55:54 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by albireo.enyo.de with esmtp id 1E3TSG-0000X4-Pl; Fri, 12 Aug 2005 08:55:48 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.52) id 1E3TSA-0006M9-0O; Fri, 12 Aug 2005 08:55:42 +0200 From: Florian Weimer To: "william(at)elan.net" Cc: namedroppers@ops.ietf.org Subject: Re: Migrating away from TXT records References: <87irycqrqn.fsf@mid.deneb.enyo.de> Date: Fri, 12 Aug 2005 08:55:41 +0200 In-Reply-To: (william elan net's message of "Thu, 11 Aug 2005 14:54:58 -0700 (PDT)") Message-ID: <87irybk5jm.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * william elan net: > Isn't it my understanding that caching server will carry data even > for data types that it does not know (in fact caching server does > not need to know about structure of most DNS RR)? If so I do not see > anything wrong with checking to make certain that both SPF RR and > TXT RR are the same. I note that there is an assumption being made that > both SPF and TXT lookups will be done through same local dns resolver. Are you aware that caching works per record type (and class) and domain name, not just per domain name? This means that the two cached versions expire at different times (or just one of them is cached in the first place). When a client which performs the consistency check comes along, only one of the record types might be updated, leading to a tempoary inconsistency after a zone update. Or do you think the damage done by this is negligible compared to the benefits? -- to unsubscribe send a message to namedroppers-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 Aug 12 03:14:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Tkn-0003KG-NR for dnsext-archive@megatron.ietf.org; Fri, 12 Aug 2005 03:14:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07514 for ; Fri, 12 Aug 2005 03:14:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3Tfx-0003Uu-N3 for namedroppers-data@psg.com; Fri, 12 Aug 2005 07:09:57 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E3Tfw-0003UT-0p for namedroppers@ops.ietf.org; Fri, 12 Aug 2005 07:09:56 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by albireo.enyo.de with esmtp id 1E3Tft-0000fd-BI; Fri, 12 Aug 2005 09:09:53 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.52) id 1E3Tfm-0006Oi-8J; Fri, 12 Aug 2005 09:09:46 +0200 From: Florian Weimer To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: Migrating away from TXT records References: <200508120017.j7C0H9HN035374@drugs.dv.isc.org> Date: Fri, 12 Aug 2005 09:09:46 +0200 In-Reply-To: <200508120017.j7C0H9HN035374@drugs.dv.isc.org> (Mark Andrews's message of "Fri, 12 Aug 2005 10:17:09 +1000") Message-ID: <87d5ojk4w5.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Mark Andrews: > Why bother checking. Just use the new one and be done with it. Yes, this is fine. I raised the issue on this mailing list because the SPF folks claim that they were forced to add the check after review by anonymous DNS experts during the IETF standardization process. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 12 04:10:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Ucp-0006CA-Cc for dnsext-archive@megatron.ietf.org; Fri, 12 Aug 2005 04:10:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09782 for ; Fri, 12 Aug 2005 04:10:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3UXz-0007UW-Oq for namedroppers-data@psg.com; Fri, 12 Aug 2005 08:05:47 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E3UXy-0007U6-Sq for namedroppers@ops.ietf.org; Fri, 12 Aug 2005 08:05:47 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j7C85UP6009103; Fri, 12 Aug 2005 01:05:30 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j7C85Ul5009100; Fri, 12 Aug 2005 01:05:30 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 12 Aug 2005 01:05:30 -0700 (PDT) From: "william(at)elan.net" To: Florian Weimer cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: Migrating away from TXT records In-Reply-To: <87d5ojk4w5.fsf@mid.deneb.enyo.de> Message-ID: References: <200508120017.j7C0H9HN035374@drugs.dv.isc.org> <87d5ojk4w5.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ok, I see where the problem is now. On Fri, 12 Aug 2005, Florian Weimer wrote: > * Mark Andrews: > >> Why bother checking. Just use the new one and be done with it. > > Yes, this is fine. > > I raised the issue on this mailing list because the SPF folks claim > that they were forced to add the check after review by anonymous DNS > experts during the IETF standardization process. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-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 Aug 14 20:54:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4TFB-0007r2-9l for dnsext-archive@megatron.ietf.org; Sun, 14 Aug 2005 20:54:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21477 for ; Sun, 14 Aug 2005 20:54:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4T5t-000OPy-6D for namedroppers-data@psg.com; Mon, 15 Aug 2005 00:44:49 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E4T5r-000OPi-91 for namedroppers@ops.ietf.org; Mon, 15 Aug 2005 00:44:47 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id CE216568AD for ; Sun, 14 Aug 2005 17:44:44 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.2.1.2.2.20050814194055.07204cb0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 14 Aug 2005 20:41:39 -0400 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: Issues with draft-ietf-dnsext-trustupdate-threshold-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At the DNSEXT meeting we were asked to comment on the various trust update drafts... DISCLAIMER: I'm the author of the other trust anchor update draft. That said, I believe the following to be a fairly objective description of problems with the named draft. This draft (along with my own) is currently expired, but we've been asked to resubmit them - see http://tools.ietf.org/wg/dnsext/agenda?item=agenda63.txt for pointers to the expired drafts. 1) "Time is nature's way of making sure everything doesn't happen at the same time." The timing model in the draft with respect to when anchors are valid is non-existent. Basically, the draft is written from the point of view of the data provider (server) and not the resolver. To understand why this is a problem, consider 1 trust point with N trust anchors and 1000 resolvers that all begin with the same perception of trust anchors at the trust point. Do any trust update action at the trust point, wait a random time and do another trust update action. First question: For any given resolver, what is the set of active (trusted) trust anchors for that trust point at any time T after the second update action. Answer: Indeterminate because the state of the trust anchor AT THE RESOLVER depends on the resolver seeing all the trust update activity and it might not if the first query to the trust point occurs after the second update action. Second question: What are the chances all 1000 will have the same state information at time T? Answer: approaches zero. There's an attempt to wave this off as not a problem (section 3.7) but any protocol description has to consider what actually reaches the resolver, and not just say to the operator "don't do that". In other words, if the resolver doesn't see a change because another happens due to the operator going off and doing two changes in a row without sufficient delay between them, the resolver is going to get out of sync with the trust point. (And people being who they are, this will happen either on purpose or by mistake) 2) The draft uses the term "locally configured minimum" to describe the number of trust anchors needed at a trust point to validate trust updates. This comes under the heading of a very bad idea. To explain, take the same 1000 set of resolvers from paragraph 1. Have 500 of them require 2 anchors and 500 require 3. Have the trust point owner sometimes use two anchors and sometimes three. Question: What are the chances that all 1000 will be able to keep in sync? Answer: Zero. The number of trust anchors needs to be a consistent number per trust point and ideally for the entire scheme (so you don't actually have to configure this at the resolver.) Its possible what the author meant the trust point owner would make the selection, but that's almost as bad because that value (MofN for the trust point) isn't encoded in the DNS and would need to be manually configured by EACH resolver owner. 3) Due to the draft's described data model, each trust point DNSKEY RRSet would have to be signed by every SEP DNSKEY in the RRSet. This tends to expand the RRSig RRSet substantially. 4) Unfortunately, since the RRSig RRSET isn't also signed, its possible to delete one or more of the RRSigs from an answer with some interesting and mostly undefined impacts on the resolver's view of the trust anchor set. E.g. you can REALLY cause some interesting problems by letting some resolvers see all the RRSIGs and some see reduced sets. 5) It's unclear if this changes the trust model of DNSSEC by requiring an AND of keys at a trust point rather than an OR. In other words before if you had at least one trust anchor that chained (via at least one key at each signature point) to the data, the data validated. If the draft requires multiple keys for trust update but single keys for trust chaining, there are some interesting interactions that may take place when you throw in multiple algorithms. At the current state of the draft, I can't say if any or all of these are fatal, but there's a lot more work to do to nail down the protocol interactions. Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 15 07:57:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4db4-0003aP-6k for dnsext-archive@megatron.ietf.org; Mon, 15 Aug 2005 07:57:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28023 for ; Mon, 15 Aug 2005 07:57:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4dVL-000JS5-Cc for namedroppers-data@psg.com; Mon, 15 Aug 2005 11:51:47 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E4dVJ-000JRO-4k for namedroppers@ops.ietf.org; Mon, 15 Aug 2005 11:51:45 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0199333C1A; Mon, 15 Aug 2005 12:51:39 +0100 (BST) Message-ID: <430081CB.7050208@algroup.co.uk> Date: Mon, 15 Aug 2005 12:51:39 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers-owner CC: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question References: <6.2.3.4.2.20050802113226.04cfa510@localhost> In-Reply-To: <6.2.3.4.2.20050802113226.04cfa510@localhost> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Namedroppers-owner wrote: > [ 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 real important question and there are multiple possible answers > IMHO I think it is going to come down to cost which solution to select. > > At 18:15 01/08/2005, Samuel Weiler wrote: > >> I don't see this addressed by our requirements doc, >> draft-ietf-dnsext-signed-nonexistence-requirements-01.txt (now >> expired). Please tell me if I missed something. >> >> -- must it be possible to smoothly roll between NSEC and NSEC3? >> >> Specifically I mean: >> >> -- During roll between NSEC and NSEC3 (and vice-versa), must a >> properly configured resolver that supports both NSEC and NSEC3 >> always see the zone as Secure (never Insecure)? > > > This is real hard, as for this to work the zone must use both NSEC > and NSEC3 at the same time in order to work and validator pics one > to follow at any given moment. Surely not? The server only ever has to use one, since the resolver supports both. So, this seems to me to be trivial - the server switches from an all-NSEC zone to an all-NSEC3 zone, and everything Just Works(tm). -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Aug 15 07:59:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4dcK-0003hd-Mv for dnsext-archive@megatron.ietf.org; Mon, 15 Aug 2005 07:59:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28092 for ; Mon, 15 Aug 2005 07:58:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4dZd-000JvD-2B for namedroppers-data@psg.com; Mon, 15 Aug 2005 11:56:13 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E4dZc-000Jun-10 for namedroppers@ops.ietf.org; Mon, 15 Aug 2005 11:56:12 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2F50F33C1A; Mon, 15 Aug 2005 12:56:10 +0100 (BST) Message-ID: <430082DB.7090901@algroup.co.uk> Date: Mon, 15 Aug 2005 12:56:11 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 signalling mechanism References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > On Sat, 23 Jul 2005, Samuel Weiler wrote: > > >> -- the lack of specification of a signaling mechanism for indicating >> that NSEC3, rather than NSEC, is in use. I think we agreed this >> could be deferred, but the selection is necessary for >> implementation to go forward. >> >> -- the lack of clarity re: which hash algorithms are >> required/mandatory and/or a way to signal which may be in use in >> a given zone, which may be needed to prevent a downgrade attack. >> (Or drop to a single algorithm, and remove the field.) > > > dnssec-trans-02 recommends a partial typecode roll, rolling the NSEC > and DS types as well as the DNSSEC-OK bit. As I recall the joy of > finding a new protocol bug every two months in late 2002 with DS, I > find myself longing for something else. > > I propose: > > We use the DS message digest number field for signaling BOTH: > 1) that NSEC3 is in use in the child zone, and > 2) which SINGLE hash algorithm is used by those NSEC3 RRs. > > This requires a new DS message digest assignment (in a Standards > Action registry), whether using SHA-1, as before, or something new. > It also depends on resolvers treating DS's with unknown digest > algorithms as they would DS's with unknown public key algorithms, > which is not described in 4035, but is described in bis-updates > section 3.1. I do not understand why it is necessary to signal that the child zone is using NSEC3. Also, if we introduce an interaction between parent and child in order to use NSEC3 it has impact on all sorts of other things and is, IMO, to be avoided. > We could also then remove the NSEC3 hash algorithm field along with > the need to have rules for handling unknown values in that field. > Simiplicity is a good thing. It also removes the need for a new IANA > registry. Having to link the parent's response to interpretation of the child's response does not strike me as a simplification. It also doesn't work for the root of any island of trust. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Aug 15 08:47:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4eMx-00021s-No for dnsext-archive@megatron.ietf.org; Mon, 15 Aug 2005 08:47:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00890 for ; Mon, 15 Aug 2005 08:47:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4eJX-000Nvs-5D for namedroppers-data@psg.com; Mon, 15 Aug 2005 12:43:39 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4eJU-000NvL-Dj for namedroppers@ops.ietf.org; Mon, 15 Aug 2005 12:43:36 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO021DE5; 15 Aug 2005 08:46:19 -0400 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 15 Aug 2005 08:46:15 -0400 Received: from connotech.com (209.71.204.114) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG021DE4; 15 Aug 2005 08:46:13 -0400 Message-ID: <43009546.6070304@connotech.com> Date: Mon, 15 Aug 2005 09:14:46 -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 CC: rschroe@sandia.gov, Donald.Eastlake@motorola.com Subject: About draft-ietf-dnsext-ecc-key-07.txt, absence of algorithm restriction in ECC public key encoding Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_SBL autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: A quick question/comment about the draft draft-ietf-dnsext-ecc-key-07.txt, "Elliptic Curve KEYs in the DNS". In this draft document, I didn't see any indication of public key algorithm to be used with a given public key (e.g. the same RSA public key value can be used with SHA-1 or MD5 for signatures, and a different DNSKEY RR encoding prevents an RSA-SHA-1 key to be diverted to RSA-MD5). This is somehow different from key usage, i.e. whether DNS zone signing allowed. For instance of algorithm restriction with ECC public keys, see the draft-ietf-pkix-ecc-pkalgs-01.txt Am I correct in reading the draft draft-ietf-dnsext-ecc-key-07.txt as omitting algorithm restrictions? If yes, I see a difficulty with algorithm change threat once the ECC crypto is applied to DNS. Thus, I would expect the ECC public key format to be reworked before applied to DNS. 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 Aug 16 10:31:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52Th-0000SC-NL for dnsext-archive@megatron.ietf.org; Tue, 16 Aug 2005 10:31:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15089 for ; Tue, 16 Aug 2005 10:31:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E52Mi-000MEB-8D for namedroppers-data@psg.com; Tue, 16 Aug 2005 14:24:32 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E52Mg-000MDl-5Y for namedroppers@ops.ietf.org; Tue, 16 Aug 2005 14:24:30 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C49D333C1A for ; Tue, 16 Aug 2005 15:24:24 +0100 (BST) Message-ID: <4301F71A.50800@algroup.co.uk> Date: Tue, 16 Aug 2005 15:24:26 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG Subject: Opt-in X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've been reviewing the security considersations of http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-07.txt. It seems to me that the statement: 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). This seems to me to be incorrect, since a denial of a domain must include a denial for the matching wildcard. Similarly, the wildcard being signed means that "insertion" isn't possible if there's a wildcard present, since all records would exist anyway. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 16 15:12:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56rO-000244-Bo for dnsext-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:12:30 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29786 for ; Tue, 16 Aug 2005 15:12:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E56nX-000JEP-Qk for namedroppers-data@psg.com; Tue, 16 Aug 2005 19:08:31 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E56nT-000JDl-Vy for namedroppers@ops.ietf.org; Tue, 16 Aug 2005 19:08:28 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 16 Aug 2005 15:08:26 -0400 id 005B803F.430239AA.000041B6 In-Reply-To: <4301F71A.50800@algroup.co.uk> References: <4301F71A.50800@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Opt-in Date: Tue, 16 Aug 2005 15:08:26 -0400 To: Ben Laurie X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 16, 2005, at 10:24 AM, Ben Laurie wrote: > I've been reviewing the security considersations of http:// > www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt- > in-07.txt. It seems to me that the statement: > > 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). > > This seems to me to be incorrect, since a denial of a domain must > include a denial for the matching wildcard. Similarly, the wildcard > being signed means that "insertion" isn't possible if there's a > wildcard present, since all records would exist anyway. What this is trying to say is that an attacker (presumably a MitM) can undetectably insert an unsigned delegation that blocks a wildcard expansion. And conversely, the attacker could undetectably replace a normal unsigned delegation with a wildcard expansion (if there was a wildcard present, that is). So, in one sense this paragraph is a little misleading because the attacker isn't "inserting" a wildcard expansion, the attacker is *replacing* an unsigned delegation with the wildcard expansion. Also note that section 4.1.3 of the draft relaxes the requirement to provide the denial for the matching wildcard in the rcode=3 (NameError) case. While the logic in that section is mine, I have to admit that I'm not entirely confident that its conclusion is the right one. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 16 15:49:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57RP-0007yR-Ti for dnsext-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:49:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01791 for ; Tue, 16 Aug 2005 15:49:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E57OH-000M6X-DS for namedroppers-data@psg.com; Tue, 16 Aug 2005 19:46:29 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E57OF-000M6G-L5 for namedroppers@ops.ietf.org; Tue, 16 Aug 2005 19:46:27 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 60EE323F for ; Tue, 16 Aug 2005 15:46:26 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A261141AB for ; Tue, 16 Aug 2005 15:46:25 -0400 (EDT) Date: Tue, 16 Aug 2005 15:46:25 -0400 From: Rob Austein To: DNSEXT WG Subject: Re: Opt-in In-Reply-To: References: <4301F71A.50800@algroup.co.uk> 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: <20050816194625.A261141AB@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 16 Aug 2005 15:08:26 -0400, David Blacka wrote: > > Also note that section 4.1.3 of the draft relaxes the requirement to > provide the denial for the matching wildcard in the rcode=3 > (NameError) case. While the logic in that section is mine, I have to > admit that I'm not entirely confident that its conclusion is the > right one. No doubt I'm missing something obvious, but could we solve the wildcard interaction problem simply by stating that the opt-foo bit can't apply to a range containing a wildcard? That is, can we just state that wildcards, if present, must be signed, and that an opt-foo NSEC3 means by definition that there is no wildcard in that range? I haven't yet made up my mind on the resurrection of opt-foo, but if we do keep it I'm pretty sure that I'd prefer the above approach to losing the "not covered by a wildcard" part of the Name Error proof. -- to unsubscribe send a message to namedroppers-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 Aug 16 15:52:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57Th-0008KJ-2X for dnsext-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:52:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01956 for ; Tue, 16 Aug 2005 15:52:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E57Rk-000MLr-T8 for namedroppers-data@psg.com; Tue, 16 Aug 2005 19:50:04 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E57Rj-000MKu-1w for namedroppers@ops.ietf.org; Tue, 16 Aug 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E57Rh-0007HM-TE; Tue, 16 Aug 2005 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-01.txt Message-Id: Date: Tue, 16 Aug 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Automated Updates of DNSSEC Trust Anchors Author(s) : M. StJohns Filename : draft-ietf-dnsext-trustupdate-timers-01.txt Pages : 13 Date : 2005-8-16 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, if adopted, 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-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-trustupdate-timers-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-trustupdate-timers-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-16130604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-trustupdate-timers-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-trustupdate-timers-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-16130604.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 16 16:21:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57w1-000326-7V for dnsext-archive@megatron.ietf.org; Tue, 16 Aug 2005 16:21:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09747 for ; Tue, 16 Aug 2005 16:21:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E57tF-000PI2-T8 for namedroppers-data@psg.com; Tue, 16 Aug 2005 20:18:29 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E57tD-000PHn-J9 for namedroppers@ops.ietf.org; Tue, 16 Aug 2005 20:18:27 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 16 Aug 2005 16:18:26 -0400 id 005B8058.43024A12.00005181 In-Reply-To: <20050816194625.A261141AB@thrintun.hactrn.net> References: <4301F71A.50800@algroup.co.uk> <20050816194625.A261141AB@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F075C27-CB1E-4A56-93CD-9FEDCBB6D351@verisignlabs.com> Cc: DNSEXT WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Opt-in Date: Tue, 16 Aug 2005 16:18:25 -0400 To: Rob Austein X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 16, 2005, at 3:46 PM, Rob Austein wrote: > At Tue, 16 Aug 2005 15:08:26 -0400, David Blacka wrote: > >> >> Also note that section 4.1.3 of the draft relaxes the requirement to >> provide the denial for the matching wildcard in the rcode=3 >> (NameError) case. While the logic in that section is mine, I have to >> admit that I'm not entirely confident that its conclusion is the >> right one. >> > > No doubt I'm missing something obvious, but could we solve the > wildcard interaction problem simply by stating that the opt-foo bit > can't apply to a range containing a wildcard? That is, can we just > state that wildcards, if present, must be signed, and that an opt-foo > NSEC3 means by definition that there is no wildcard in that range? It already says that. (Discounting wildcard NS records ;) > I haven't yet made up my mind on the resurrection of opt-foo, but if > we do keep it I'm pretty sure that I'd prefer the above approach to > losing the "not covered by a wildcard" part of the Name Error proof. This is not because the wildcard RR set is not signed or not in the NSEC{3} chain -- it is. This is because you cannot quite prove rcode=3 when the covering NSEC is opt-in, so why bother *also* proving that there is no wildcard (which, I repeat, you can do)? Maybe *I'm* missing something obvious, but what is this "wildcard interaction problem", really? And, honestly, section 4.1.3 could be changed to require that rcode=3 responses include the NSEC record that proves no wildcard exists without hurting anything. I'm just not sure that it buys you anything, so why should the validator have to do the work? OTOH, I think I can be easily convinced to make this change. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 16 17:15:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58mp-0004iH-6Z for dnsext-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:15:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12959 for ; Tue, 16 Aug 2005 17:15:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E58k4-0003nB-As for namedroppers-data@psg.com; Tue, 16 Aug 2005 21:13:04 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E58k0-0003mm-Bv for namedroppers@ops.ietf.org; Tue, 16 Aug 2005 21:13:02 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 16E3D243 for ; Tue, 16 Aug 2005 17:12:59 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B05C841AB for ; Tue, 16 Aug 2005 17:12:57 -0400 (EDT) Date: Tue, 16 Aug 2005 17:12:57 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Opt-in In-Reply-To: <0F075C27-CB1E-4A56-93CD-9FEDCBB6D351@verisignlabs.com> References: <4301F71A.50800@algroup.co.uk> <20050816194625.A261141AB@thrintun.hactrn.net> <0F075C27-CB1E-4A56-93CD-9FEDCBB6D351@verisignlabs.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: <20050816211257.B05C841AB@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 16 Aug 2005 16:18:25 -0400, David Blacka wrote: > On Aug 16, 2005, at 3:46 PM, Rob Austein wrote: > > > ... That is, can we just state that wildcards, if present, must be > > signed, and that an opt-foo NSEC3 means by definition that there > > is no wildcard in that range? > > It already says that. (Discounting wildcard NS records ;) 4.1.1 says SHOULD, not MUST. > This is not because the wildcard RR set is not signed or not in the > NSEC{3} chain -- it is. This is because you cannot quite prove > rcode=3 when the covering NSEC is opt-in, so why bother *also* > proving that there is no wildcard (which, I repeat, you can do)? > > Maybe *I'm* missing something obvious, but what is this "wildcard > interaction problem", really? It's a consistancy thing, I dunno how much it matters. As I think I understand it, the opt-foo model is signed records rather than signed zones. One way of looking at this is that it's the same model as DNSSECbis but certain portions of a zone are flagged as dropping out, leaving a signed subset of the zone. So a "no such name in zone" proof turns into a "no such signed name in zone" proof, which (to my mind, anyway) includes "no signed covering wildcard in zone." > And, honestly, section 4.1.3 could be changed to require that rcode=3 > responses include the NSEC record that proves no wildcard exists > without hurting anything. I'm just not sure that it buys you > anything, so why should the validator have to do the work? OTOH, I > think I can be easily convinced to make this change. I'm not sure it buys anything either, and will admit that there's a case to be made here either way. On the one hand, I think that including the NSEC/NSEC3 is more consistant (and DNSSEC in general is already umpty-three levels deep in baroque fixes to our previous cleverness, opt-foo brings it to umpty-four, so retaining what little consistancy remains in this house of cards seems good to me...); on the other hand, omitting the NSEC/NSEC3 saves some bandwidth. Dunno. In any case: upon further analysis (or, if you prefer, upon swapping in foggy memories), the answer to my original question is that my proposal above doesn't suffice, because it doesn't handle an unsigned positive answer that masks a signed wildcard. Only fix I see for that would be changing SHOULD in 4.1.1 to MUST. -- to unsubscribe send a message to namedroppers-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 Aug 16 20:02:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5BO7-0000ce-QU for dnsext-archive@megatron.ietf.org; Tue, 16 Aug 2005 20:02:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25520 for ; Tue, 16 Aug 2005 20:02:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5BIk-000Gg6-RO for namedroppers-data@psg.com; Tue, 16 Aug 2005 23:57:02 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5BIg-000GfU-Lf for namedroppers@ops.ietf.org; Tue, 16 Aug 2005 23:56:58 +0000 Received: from [192.168.1.10] ([::ffff:69.255.36.218]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Tue, 16 Aug 2005 19:56:57 -0400 id 005B808D.43027D49.00007365 Message-ID: <43027D48.4090705@verisignlabs.com> Date: Tue, 16 Aug 2005 19:56:56 -0400 From: David Blacka User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Austein CC: namedroppers@ops.ietf.org Subject: Re: Opt-in References: <4301F71A.50800@algroup.co.uk> <20050816194625.A261141AB@thrintun.hactrn.net> <0F075C27-CB1E-4A56-93CD-9FEDCBB6D351@verisignlabs.com> <20050816211257.B05C841AB@thrintun.hactrn.net> In-Reply-To: <20050816211257.B05C841AB@thrintun.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > At Tue, 16 Aug 2005 16:18:25 -0400, David Blacka wrote: > >>On Aug 16, 2005, at 3:46 PM, Rob Austein wrote: >> >> >>>... That is, can we just state that wildcards, if present, must be >>>signed, and that an opt-foo NSEC3 means by definition that there >>>is no wildcard in that range? >> >>It already says that. (Discounting wildcard NS records ;) > > > 4.1.1 says SHOULD, not MUST. 4.1.1 has some squishiness to it because it is talking about how the tools behave, which is an area that, at least at the time, folks were reluctant to say MUST. But signing the wildcard really is a MUST: see section 4.2.1. > >>This is not because the wildcard RR set is not signed or not in the >>NSEC{3} chain -- it is. This is because you cannot quite prove >>rcode=3 when the covering NSEC is opt-in, so why bother *also* >>proving that there is no wildcard (which, I repeat, you can do)? >> >>Maybe *I'm* missing something obvious, but what is this "wildcard >>interaction problem", really? > > > It's a consistancy thing, I dunno how much it matters. As I think I > understand it, the opt-foo model is signed records rather than signed > zones. One way of looking at this is that it's the same model as > DNSSECbis but certain portions of a zone are flagged as dropping out, > leaving a signed subset of the zone. So a "no such name in zone" > proof turns into a "no such signed name in zone" proof, which (to my > mind, anyway) includes "no signed covering wildcard in zone." And it does. > >>And, honestly, section 4.1.3 could be changed to require that rcode=3 >>responses include the NSEC record that proves no wildcard exists >>without hurting anything. I'm just not sure that it buys you >>anything, so why should the validator have to do the work? OTOH, I >>think I can be easily convinced to make this change. > > > I'm not sure it buys anything either, and will admit that there's a > case to be made here either way. On the one hand, I think that > including the NSEC/NSEC3 is more consistant (and DNSSEC in general is > already umpty-three levels deep in baroque fixes to our previous > cleverness, opt-foo brings it to umpty-four, so retaining what little > consistancy remains in this house of cards seems good to me...); on > the other hand, omitting the NSEC/NSEC3 saves some bandwidth. Dunno. I agree. When this language was added, there was some concern that the negative wildcard proof was "hard", so being able to avoid it was nice. Now we know better, so, I agree, it could go either way and be OK. > In any case: upon further analysis (or, if you prefer, upon swapping > in foggy memories), the answer to my original question is that my > proposal above doesn't suffice, because it doesn't handle an unsigned > positive answer that masks a signed wildcard. Only fix I see for that > would be changing SHOULD in 4.1.1 to MUST. After reading 4.2.1, do you still think 4.1.1's SHOULDs should change to MUSTs? -- 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 Aug 18 06:53:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5i1j-0005ip-UF for dnsext-archive@megatron.ietf.org; Thu, 18 Aug 2005 06:53:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25912 for ; Thu, 18 Aug 2005 06:53:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5hwV-000GEQ-1M for namedroppers-data@psg.com; Thu, 18 Aug 2005 10:48:15 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5hwT-000GE4-TO for namedroppers@ops.ietf.org; Thu, 18 Aug 2005 10:48:14 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 2D22F2DE74; Thu, 18 Aug 2005 12:48:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 0B2C72DE66; Thu, 18 Aug 2005 12:48:09 +0200 (CEST) Date: Thu, 18 Aug 2005 12:48:09 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Rob Austein cc: DNSEXT WG Subject: Re: Opt-in In-Reply-To: <20050816194625.A261141AB@thrintun.hactrn.net> Message-ID: References: <4301F71A.50800@algroup.co.uk> <20050816194625.A261141AB@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 16 Aug 2005, Rob Austein wrote: > At Tue, 16 Aug 2005 15:08:26 -0400, David Blacka wrote: > > > > Also note that section 4.1.3 of the draft relaxes the requirement to > > provide the denial for the matching wildcard in the rcode=3 > > (NameError) case. While the logic in that section is mine, I have to > > admit that I'm not entirely confident that its conclusion is the > > right one. > > No doubt I'm missing something obvious, but could we solve the > wildcard interaction problem simply by stating that the opt-foo bit > can't apply to a range containing a wildcard? That is, can we just > state that wildcards, if present, must be signed, and that an opt-foo > NSEC3 means by definition that there is no wildcard in that range? > > I haven't yet made up my mind on the resurrection of opt-foo, but if > we do keep it I'm pretty sure that I'd prefer the above approach to > losing the "not covered by a wildcard" part of the Name Error proof. IMHO the wildcard/opt-in interaction is as follows: Opt-in is basically an NSEC that covers an unsigned span where one or more unsigned delegations appear. A signed wildcard RRset is exactly that, a record with an ownername starting with an asterisk, signed entirely. It will never appear as such in an opt-in span. What a MITM is able to do wrt the unsigned span is to replace an existing unsigned delegation with a synthesised wildcard and vice versa. The synthesised wildcard is not signed after it was synthesised, the accompanying signature appearing there is the signature over the original wildcard. As to impact and remedy, lets keep in mind a similar attack with DNSSEC without opt-in: Since we assume a mitm and an unsigned delegation, a MITM is able to rewrite the unsigned delegation to a virtual server under its control, and answer the original query from there with whatever it desires (including that what would essentially be a synthesised wildcard in the previous scenario). Ofcourse, the MITM could also send an NXDOMAIN/NODATA back claiming the original queried name and/or type does not exist. Since this attack gives the MITM more freedom as to what to respond to the original requestor, i find the impact of opt-in/wildcard interaction benign. In short, with or without opt-in, since it is an unsigned delegation, all bets are off, regardless whether opt-in is used. The remedy is to have a secure delegation to a signed child. 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 Aug 18 08:45:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jmE-00005d-Lo for dnsext-archive@megatron.ietf.org; Thu, 18 Aug 2005 08:45:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01866 for ; Thu, 18 Aug 2005 08:45:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5jjA-0002gS-4m for namedroppers-data@psg.com; Thu, 18 Aug 2005 12:42:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5jj8-0002ft-UZ for namedroppers@ops.ietf.org; Thu, 18 Aug 2005 12:42:35 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7ICgOOH026062; Thu, 18 Aug 2005 08:42:27 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Thu, 18 Aug 2005 08:42:37 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: resurrecting wildcards and opt-in Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Referring back to: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html Since that post a WG draft on wildcard clarifications (and modifications) has progressed from an individual -00 to an all-but-completely-edited-post-wglc document. (Really, it is. I am waiting on one vacationing person to review section 4.2.1. They know who they are.) I mention this because we have a collectively higher consciousness about wild cards now. My hypothesis is that the crucial question is - in an opt-in zone, can any RRSet (signed or unsigned) cause ambiguity over the security of another signed RRSet in the same zone? I'll start with arguing over the question. The objective of DNSSEC is to make sure the client (resolver) can detect if an RRSet has been protected and has arrived safely. First it is important to tell if the RRSet has been protected - my that I mean the resolver can follow a chain of trust right to the RRSet. Second, if the resolver has an expectation that the RRSet is to be secure, the resolver can then inspect the security meta-data to verify the RRSet. Unprotected data, meaning data not signed via DNSSEC, cannot be verified within DNSSEC. (I'll leave it to the philosophers and sages to argue over other forms of verification.) Unprotected data does not prevent protected data from being verified. The upshot is that DNSSEC does not help unprotected data, and DNSSEC should "survive" unprotected data. The reason I mention this is the question of what happens with a signed wild card RRSet in a zone that allows for unsigned RRSets. It is trivial to present a properly signed wildcard synthesized RRSet without having access to the private key needed to generate the signature. An unsigned RRSet has no defense against that attack. A signed RRSet has a defense - the falsely synthesized RRSet has to be accompanied by other signed RRSets that do require access to the private key. It is true that opt-in opens the door to a falsely generated signed wildcard synthesis being used to spoof an unsigned RRSet in the same zone. But so far I don't see that as a problem given that the unsigned RRSet is no worse off than today. Complicating the matter, it is possible that the closest encloser of a query name be unsigned (assuming the query name does not exist in the modified sense of RFC 1034). In this case, a signed wildcard synthesis may be presented maliciously instead of a return code of name error or NXDOMAIN (provided the wild card domain name otherwise "covers" the query name. I think this is an interesting case. If there is no synthesis to apply to a query name that does not exist, then there is a signed NSEC record to return. With synthesis, there are no name errors. So what happens with an unsigned RRSet prevents the application of synthesis? Maybe this is a problem. A resolver might see an unsigned NXDOMAIN - which would be the proper answer if there was an unsigned closest encloser between a signed wild card and query name. Without an attack, how does a server indicate that there is an unsigned closest encloser? I'll stop there. Here's a zone illustrating the problem: $origin example. @ IN SOA RRSIG SOA ... NS ns0.tld. ; so I don't need A / AAAA records NS ns1.tld. RRSIG NS ... DNSKEY #1 DNSKEY #2 RRSIG DNSKEY ... #1 ... RRSIG DNSKEY ... #2 ... NSEC * ... RRSIG NSEC ... * TXT "This zone has a wildcard" RRSIG TXT ... NSEC alpha ... RRSIG NSEC ... alpha A 127.0.0.1 RRSIG A ... NSEC crouton ... bacon-bits AAAA ::0 ; an unsigned entry crouton AAAA ::1 RRSIG AAAA NSEC example. RRSIG NSEC ; What is the answer to this query? QNAME = i.want.my.bacon-bits.example. QCLASS = IN QTYPE = RP DO flag on...CD on... Do I have to put the bacon-bits AAAA RRSet in the answer to explain this to the resolver? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-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 Aug 18 10:46:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lef-0004iW-5s for dnsext-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:46:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09673 for ; Thu, 18 Aug 2005 10:46:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5laj-000Fh2-36 for namedroppers-data@psg.com; Thu, 18 Aug 2005 14:42:01 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5lah-000FgS-Rk for namedroppers@ops.ietf.org; Thu, 18 Aug 2005 14:42:00 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7IEfp82026511; Thu, 18 Aug 2005 10:41:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Thu, 18 Aug 2005 10:42:03 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: draft-ietf-dnsext-dnssec-opt-in-07.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Referencing: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-07.txt I would have to say that once again I bristle with special case rules like "only delegations" can be in unsigned spans. Before I say it is ultimately justified and needed, the reason I bristle is the brush up with DNAME. However, I don't think the problems with * DNAMEs in caches apply to this. # 4.1.3 Wildcards and Opt-In # # The intent of the standard DNSSEC negative wildcard proof requirement # is to prevent malicious users from undetectably removing valid # wildcard responses. In order for this cryptographic proof to work, # the resolver must be able to prove: # # 1. The exact qname does not exist. This is done by the "normal" # NSEC record. # 2. No applicable wildcard exists. This is done by returning a NSEC # record proving that the wildcard does not exist (this is the # negative wildcard proof). # # However, if the NSEC record covering the exact qname is an Opt-In # NSEC record, the resolver will not be able to prove the first part of # this equation, as the qname might exist as an insecure delegation. # Thus, since the total proof cannot be completed, the negative # wildcard proof NSEC record is not useful. # I think that some of this section can be cleaned or tightened up by saying that if a closest encloser is unsigned, then it must be a delegation point. Hence, a unsigned RRSet can not be the reason for failing to synthesize from a (signed) wildcard. I.e., you don't have the (RFC 1034) section 4.3.2, step 3, part c to worry about here because you'd be in part b. On another point, denying the existence of a name in an unsigned span ought to follow the rules for denying existence without DNSSEC (ie, no denial of wildcards), denying the existence of a name in a signed span does follow the DNSSEC rules (ie, including the wildcard denial). # 4.2.1 Delegations Only # # As stated in the "Server Considerations" section above, this # specification restricts the namespace covered by Opt-In tagged NSEC # records to insecure delegations only. Thus, resolvers MUST reject as # invalid any records that fall within an Opt-In NSEC record's span # that are not NS records or corresponding glue records. Does this mean that an API reacts as if rcode=SERVFAIL is returned? # 4.2.3 NSEC Record Caching # # Caching resolvers MUST be able to retrieve the appropriate covering # Opt-In NSEC record when returning referrals that need them. This # requirement differs from standard DNSSEC in that the covering NSEC # will not have the same owner name as the delegation. Some # implementations may have to use new methods for finding these NSEC # records. This ought to reference NCACHE (2308?). I don't think we want to make caches search for records (internall), rather that caches keep negative answers cached separately from positive answers. # 8. Security Considerations I think the object here is to answer the question: Can any RRSet (signed or unsigned) cause ambiguity over the security of another signed RRSet in the same zone? # Appendix A. Implementing Opt-In using "Views" Considering "Views" are not defined anywhere, this could be a landmine of a section. Edward-Lewis-Computer:~ edlewis$ -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-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 Aug 18 10:48:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lhF-0005TP-F9 for dnsext-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:48:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09903 for ; Thu, 18 Aug 2005 10:48:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5leu-000G7y-F1 for namedroppers-data@psg.com; Thu, 18 Aug 2005 14:46:20 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5ler-000G7T-HV for namedroppers@ops.ietf.org; Thu, 18 Aug 2005 14:46:17 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2DE1433C1D; Thu, 18 Aug 2005 15:46:15 +0100 (BST) Message-ID: <43049F3A.4000200@algroup.co.uk> Date: Thu, 18 Aug 2005 15:46:18 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Blacka CC: DNSEXT WG Subject: Re: Opt-in References: <4301F71A.50800@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Blacka wrote: > > On Aug 16, 2005, at 10:24 AM, Ben Laurie wrote: > >> I've been reviewing the security considersations of http:// >> www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt- in-07.txt. >> It seems to me that the statement: >> >> 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). >> >> This seems to me to be incorrect, since a denial of a domain must >> include a denial for the matching wildcard. Similarly, the wildcard >> being signed means that "insertion" isn't possible if there's a >> wildcard present, since all records would exist anyway. > > > What this is trying to say is that an attacker (presumably a MitM) can > undetectably insert an unsigned delegation that blocks a wildcard > expansion. And conversely, the attacker could undetectably replace a > normal unsigned delegation with a wildcard expansion (if there was a > wildcard present, that is). Ah, I see. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Thu Aug 18 11:11:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5m3Z-0003gx-2O for dnsext-archive@megatron.ietf.org; Thu, 18 Aug 2005 11:11:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11628 for ; Thu, 18 Aug 2005 11:11:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5m0R-000JGC-0m for namedroppers-data@psg.com; Thu, 18 Aug 2005 15:08:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5m0O-000JFV-N2 for namedroppers@ops.ietf.org; Thu, 18 Aug 2005 15:08:33 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7IF8PMw026642; Thu, 18 Aug 2005 11:08:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 18 Aug 2005 11:08:38 -0400 To: Edward Lewis From: Edward Lewis Subject: Re: resurrecting wildcards and opt-in Cc: namedroppers@ops.ietf.org, ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:42 -0400 8/18/05, Edward Lewis wrote: >What is the answer to this query? > >QNAME = i.want.my.bacon-bits.example. >QCLASS = IN >QTYPE = RP > >DO flag on...CD on... > >Do I have to put the bacon-bits AAAA RRSet in the answer to explain this >to the resolver? It's been pointed out that only delegations can be in unsigned spans. So this won't happen. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-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 Aug 18 12:50:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nai-0000rH-KZ for dnsext-archive@megatron.ietf.org; Thu, 18 Aug 2005 12:50:08 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17257 for ; Thu, 18 Aug 2005 12:50:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5nWl-0003Wp-ME for namedroppers-data@psg.com; Thu, 18 Aug 2005 16:46:03 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5nWa-0003Vg-GN for namedroppers@ops.ietf.org; Thu, 18 Aug 2005 16:45:52 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 18 Aug 2005 12:45:51 -0400 id 005BC085.4304BB3F.0000265D In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C023AA9-9306-4747-9D31-D2F9E9505A3E@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: draft-ietf-dnsext-dnssec-opt-in-07.txt Date: Thu, 18 Aug 2005 12:45:50 -0400 To: Edward Lewis X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 18, 2005, at 10:42 AM, Edward Lewis wrote: > Referencing: http://www.ietf.org/internet-drafts/draft-ietf-dnsext- > dnssec-opt-in-07.txt > > I would have to say that once again I bristle with special case > rules like > "only delegations" can be in unsigned spans. Before I say it is > ultimately > justified and needed, the reason I bristle is the brush up with DNAME. > > However, I don't think the problems with * DNAMEs in caches apply > to this. The intent of this draft was to publish, as experimental, the previous work on Opt-In, which ended up being delegation only for both practical and, um, moral, reasons. If there was actual interest (and I doubt there is) we could certainly try to cast a non-delegation-only version of opt-in as a different experiment. But I think that it would be a bit of work to redo the analysis. > # 4.1.3 Wildcards and Opt-In > # > # The intent of the standard DNSSEC negative wildcard proof > requirement > # is to prevent malicious users from undetectably removing valid > # wildcard responses. In order for this cryptographic proof to > work, > # the resolver must be able to prove: > # > # 1. The exact qname does not exist. This is done by the "normal" > # NSEC record. > # 2. No applicable wildcard exists. This is done by returning > a NSEC > # record proving that the wildcard does not exist (this is the > # negative wildcard proof). > # > # However, if the NSEC record covering the exact qname is an Opt-In > # NSEC record, the resolver will not be able to prove the first > part of > # this equation, as the qname might exist as an insecure > delegation. > # Thus, since the total proof cannot be completed, the negative > # wildcard proof NSEC record is not useful. > # > > I think that some of this section can be cleaned or tightened up by > saying that if a closest encloser is unsigned, then it must be a > delegation > point. Hence, a unsigned RRSet can not be the reason for failing to > synthesize from a (signed) wildcard. I.e., you don't have the (RFC > 1034) > section 4.3.2, step 3, part c to worry about here because you'd be > in part b. I believe you, but you need to show me. That is, I personally cannot see how to turn this comment into tighter text. > On another point, denying the existence of a name in an unsigned span > ought to follow the rules for denying existence without DNSSEC (ie, no > denial of wildcards), denying the existence of a name in a signed span > does follow the DNSSEC rules (ie, including the wildcard denial) Does it not already say this, in effect? Note that this document isn't directly addressing what happens in a signed span, as that doesn't change from 4035 DNSSEC. > # 4.2.1 Delegations Only > # > # As stated in the "Server Considerations" section above, this > # specification restricts the namespace covered by Opt-In tagged > NSEC > # records to insecure delegations only. Thus, resolvers MUST > reject as > # invalid any records that fall within an Opt-In NSEC record's span > # that are not NS records or corresponding glue records. > > Does this mean that an API reacts as if rcode=SERVFAIL is returned? This draft (and 4033-4035 for that matter) describe the protocol, not the API. It is attempting to say, in as neutral a way as I could think of, that non-delegation records are not allowed. I always imagine that the situation would be treated exactly the same as a validation failure, but how the API actually handles this is up to the API. > # 4.2.3 NSEC Record Caching > # > # Caching resolvers MUST be able to retrieve the appropriate > covering > # Opt-In NSEC record when returning referrals that need them. This > # requirement differs from standard DNSSEC in that the covering > NSEC > # will not have the same owner name as the delegation. Some > # implementations may have to use new methods for finding these > NSEC > # records. > > This ought to reference NCACHE (2308?). I don't think we want to make > caches search for records (internall), rather that caches keep > negative > answers cached separately from positive answers. This section is talking about returning cached referrals, not negative answers. Are you saying that it should talk about returning negative answers as well? Note the "advice" was intentionally quite vague as to what caches actually need to do differently. This was all based on the point that normally a cache has a very easy way to find the NSEC that accompanies a referral to an unsigned subzone: it just looks for NSEC records named the same as NS rrset. Opt-In makes this not work. > # 8. Security Considerations > > I think the object here is to answer the question: > > Can any RRSet (signed or unsigned) cause ambiguity over the security > of another signed RRSet in the same zone? I thought the purpose of this section was to accurately describe how opt-in changes the security of your zone when compared to 4035. Which I thought it did. And I also thought that it answered your question. > # Appendix A. Implementing Opt-In using "Views" > > Considering "Views" are not defined anywhere, this could be a > landmine of > a section. Heh, that is why the term is quoted. And I thought the section actually defined what it meant by the term, albeit briefly. Maybe not well enough. -- 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 Aug 18 13:04:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5noA-0004j3-7x for dnsext-archive@megatron.ietf.org; Thu, 18 Aug 2005 13:04:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17900 for ; Thu, 18 Aug 2005 13:03:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5nlX-0005Wx-Jz for namedroppers-data@psg.com; Thu, 18 Aug 2005 17:01:19 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5nlV-0005Wc-S3 for namedroppers@ops.ietf.org; Thu, 18 Aug 2005 17:01:18 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 8B5F3413 for ; Thu, 18 Aug 2005 13:01:16 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E1F0F41AB for ; Thu, 18 Aug 2005 13:01:15 -0400 (EDT) Date: Thu, 18 Aug 2005 13:01:15 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Opt-in In-Reply-To: <43027D48.4090705@verisignlabs.com> References: <4301F71A.50800@algroup.co.uk> <20050816194625.A261141AB@thrintun.hactrn.net> <0F075C27-CB1E-4A56-93CD-9FEDCBB6D351@verisignlabs.com> <20050816211257.B05C841AB@thrintun.hactrn.net> <43027D48.4090705@verisignlabs.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: <20050818170115.E1F0F41AB@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 16 Aug 2005 19:56:56 -0400, David Blacka wrote: > Rob Austein wrote: > > > > 4.1.1 says SHOULD, not MUST. > > 4.1.1 has some squishiness to it because it is talking about how the > tools behave, which is an area that, at least at the time, folks were > reluctant to say MUST. > > But signing the wildcard really is a MUST: see section 4.2.1. > ... > After reading 4.2.1, do you still think 4.1.1's SHOULDs should change to > MUSTs? I think it would be advisable to change them to MUST, yes. Current spec inverts the robustness principle: sender is permitted to signal semantics that receiver is not allowed to accept. -- to unsubscribe send a message to namedroppers-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 Aug 20 10:24:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6UGR-0004ji-0e for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 10:24:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23372 for ; Sat, 20 Aug 2005 10:24:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6U8a-000Er2-HC for namedroppers-data@psg.com; Sat, 20 Aug 2005 14:15:56 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6U8Y-000Eqo-RB for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 14:15:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j7KEEgKN010297; Sat, 20 Aug 2005 14:14:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j7KEEchg010296; Sat, 20 Aug 2005 14:14:38 GMT Date: Sat, 20 Aug 2005 14:14:33 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question Message-ID: <20050820141433.GA10207@vacation.karoshi.com.> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430081CB.7050208@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >>-- During roll between NSEC and NSEC3 (and vice-versa), must a > >> properly configured resolver that supports both NSEC and NSEC3 > >> always see the zone as Secure (never Insecure)? > > > > > >This is real hard, as for this to work the zone must use both NSEC > >and NSEC3 at the same time in order to work and validator pics one > >to follow at any given moment. > > Surely not? The server only ever has to use one, since the resolver > supports both. So, this seems to me to be trivial - the server switches > from an all-NSEC zone to an all-NSEC3 zone, and everything Just Works(tm). er... how do you -KNOW- all the resolvers that will touch these servers support "both" NSEC and NSEC3? by several educated estimates, there are perhaps 1 or 2 orders of magnitude more resolvers out there than servers... and we have emperical evidence that getting server code upgraded is a real PITA and takes years/decades. --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 Aug 20 10:29:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ULn-0006bV-Sw for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 10:29:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23554 for ; Sat, 20 Aug 2005 10:29:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6UD7-000FQr-Uc for namedroppers-data@psg.com; Sat, 20 Aug 2005 14:20:37 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6UD5-000FQD-3Q for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 14:20:35 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 175B133C1F; Sat, 20 Aug 2005 15:20:33 +0100 (BST) Message-ID: <43073C30.8060904@algroup.co.uk> Date: Sat, 20 Aug 2005 15:20:32 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> In-Reply-To: <20050820141433.GA10207@vacation.karoshi.com.> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: >>>>-- During roll between NSEC and NSEC3 (and vice-versa), must a >>>> properly configured resolver that supports both NSEC and NSEC3 >>>> always see the zone as Secure (never Insecure)? >>> >>> >>>This is real hard, as for this to work the zone must use both NSEC >>>and NSEC3 at the same time in order to work and validator pics one >>>to follow at any given moment. >> >>Surely not? The server only ever has to use one, since the resolver >>supports both. So, this seems to me to be trivial - the server switches >>from an all-NSEC zone to an all-NSEC3 zone, and everything Just Works(tm). > > > er... how do you -KNOW- all the resolvers that will touch these > servers support "both" NSEC and NSEC3? > > by several educated estimates, there are perhaps 1 or 2 orders of > magnitude more resolvers out there than servers... and we have > emperical evidence that getting server code upgraded is a real PITA > and takes years/decades. I don't, but that wasn't the question. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 20 10:30:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6UMF-0006nC-Cv for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 10:30:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23563 for ; Sat, 20 Aug 2005 10:30:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6UJC-000GBw-M0 for namedroppers-data@psg.com; Sat, 20 Aug 2005 14:26:54 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6UJC-000GBk-5w for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 14:26:54 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j7KEPoKN010375; Sat, 20 Aug 2005 14:25:50 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j7KEPoFw010374; Sat, 20 Aug 2005 14:25:50 GMT Date: Sat, 20 Aug 2005 14:25:50 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: bmanning@vacation.karoshi.com, Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question Message-ID: <20050820142550.GB10207@vacation.karoshi.com.> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43073C30.8060904@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Aug 20, 2005 at 03:20:32PM +0100, Ben Laurie wrote: > bmanning@vacation.karoshi.com wrote: > >>>>-- During roll between NSEC and NSEC3 (and vice-versa), must a > >>>> properly configured resolver that supports both NSEC and NSEC3 > >>>> always see the zone as Secure (never Insecure)? > >>> > >>> > >>>This is real hard, as for this to work the zone must use both NSEC > >>>and NSEC3 at the same time in order to work and validator pics one > >>>to follow at any given moment. > >> > >>Surely not? The server only ever has to use one, since the resolver > >>supports both. So, this seems to me to be trivial - the server switches > >>from an all-NSEC zone to an all-NSEC3 zone, and everything Just Works(tm). > > > > > > er... how do you -KNOW- all the resolvers that will touch these > > servers support "both" NSEC and NSEC3? > > > > by several educated estimates, there are perhaps 1 or 2 orders of > > magnitude more resolvers out there than servers... and we have > > emperical evidence that getting server code upgraded is a real PITA > > and takes years/decades. > > I don't, but that wasn't the question. > true, but there was that assertion in you last statement above... "...The server only ever has to use one, since the resolver supports both..." which tickled my response. --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 Aug 20 10:35:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6UR3-0007bU-Oe for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 10:35:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23836 for ; Sat, 20 Aug 2005 10:34:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6UOv-000H58-W3 for namedroppers-data@psg.com; Sat, 20 Aug 2005 14:32:49 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6UOv-000H4f-41 for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 14:32:49 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 33B5F33C25; Sat, 20 Aug 2005 15:32:47 +0100 (BST) Message-ID: <43073F0E.5020709@algroup.co.uk> Date: Sat, 20 Aug 2005 15:32:46 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> In-Reply-To: <20050820142550.GB10207@vacation.karoshi.com.> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: > On Sat, Aug 20, 2005 at 03:20:32PM +0100, Ben Laurie wrote: > >>bmanning@vacation.karoshi.com wrote: >> >>>>>>-- During roll between NSEC and NSEC3 (and vice-versa), must a >>>>>>properly configured resolver that supports both NSEC and NSEC3 >>>>>>always see the zone as Secure (never Insecure)? >>>>> >>>>> >>>>>This is real hard, as for this to work the zone must use both NSEC >>>>>and NSEC3 at the same time in order to work and validator pics one >>>>>to follow at any given moment. >>>> >>>>Surely not? The server only ever has to use one, since the resolver >>>>supports both. So, this seems to me to be trivial - the server switches >>> >>>>from an all-NSEC zone to an all-NSEC3 zone, and everything Just Works(tm). >>> >>> >>> er... how do you -KNOW- all the resolvers that will touch these >>> servers support "both" NSEC and NSEC3? >>> >>> by several educated estimates, there are perhaps 1 or 2 orders of >>> magnitude more resolvers out there than servers... and we have >>> emperical evidence that getting server code upgraded is a real PITA >>> and takes years/decades. >> >>I don't, but that wasn't the question. >> > > > true, but there was that assertion in you last statement above... > "...The server only ever has to use one, since the resolver > supports both..." which tickled my response. That was the question asked. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 20 11:09:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Uxx-0004kD-Lw for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 11:09:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25328 for ; Sat, 20 Aug 2005 11:08:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6Utf-000M5g-TT for namedroppers-data@psg.com; Sat, 20 Aug 2005 15:04:35 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6Ute-000M5N-Bs for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 15:04:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j7KF3SKN010496; Sat, 20 Aug 2005 15:03:28 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j7KF3SoN010495; Sat, 20 Aug 2005 15:03:28 GMT Date: Sat, 20 Aug 2005 15:03:28 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: bmanning@vacation.karoshi.com, Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question Message-ID: <20050820150328.GC10207@vacation.karoshi.com.> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43073F0E.5020709@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Aug 20, 2005 at 03:32:46PM +0100, Ben Laurie wrote: > bmanning@vacation.karoshi.com wrote: > >On Sat, Aug 20, 2005 at 03:20:32PM +0100, Ben Laurie wrote: > > > >>bmanning@vacation.karoshi.com wrote: > >> > >>>>>>-- During roll between NSEC and NSEC3 (and vice-versa), must a > >>>>>>properly configured resolver that supports both NSEC and NSEC3 > >>>>>>always see the zone as Secure (never Insecure)? > >>>>> > >>>>> > >>>>>This is real hard, as for this to work the zone must use both NSEC > >>>>>and NSEC3 at the same time in order to work and validator pics one > >>>>>to follow at any given moment. > >>>> > >>>>Surely not? The server only ever has to use one, since the resolver > >>>>supports both. So, this seems to me to be trivial - the server switches > >>> > >>>>from an all-NSEC zone to an all-NSEC3 zone, and everything Just > >>>>Works(tm). > >>> > >>> > >>> er... how do you -KNOW- all the resolvers that will touch these > >>> servers support "both" NSEC and NSEC3? > >>> > >>> by several educated estimates, there are perhaps 1 or 2 orders of > >>> magnitude more resolvers out there than servers... and we have > >>> emperical evidence that getting server code upgraded is a real PITA > >>> and takes years/decades. > >> > >>I don't, but that wasn't the question. > >> > > > > > > true, but there was that assertion in you last statement above... > > "...The server only ever has to use one, since the resolver > > supports both..." which tickled my response. > > That was the question asked. thats not a question. thats an assertion based on a premise w/o factual basis. the assertion "the server only ever has to use one" is based on the premise "the resolver supports both" ... and you give no indication as to WHY you believe "the resolver" will have such capabilities. What was the question again? --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 Aug 20 12:06:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Vrm-0006MK-GW for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 12:06:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27526 for ; Sat, 20 Aug 2005 12:06:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6Vob-0004M2-T6 for namedroppers-data@psg.com; Sat, 20 Aug 2005 16:03:25 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6Vob-0004IF-0o for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 16:03:25 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 6D44DC2DA7; Sat, 20 Aug 2005 17:03:23 +0100 (BST) Date: Sat, 20 Aug 2005 17:03:22 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bmanning@vacation.karoshi.com, Ben Laurie Cc: bmanning@vacation.karoshi.com, Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3 requirements question Message-ID: In-Reply-To: <20050820150328.GC10207@vacation.karoshi.com.> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben / Bill, You guys are talking straight past each-other. The original question was: > -- During roll between NSEC and NSEC3 (and vice-versa), must a > properly configured resolver that **** supports both NSEC and NSEC3 *** > always see the zone as Secure (never Insecure)? So based on the original question, Ben answered (in effect that it only ever has to use one). I think Bill's (now) asking a different question - which is what happens if the resolver does not support both NSEC and NSEC3. And I think the answer to it is as follows: If the resolver supports NSEC, but does not support NSEC3, that: * a zone that is rolling from NSEC (only) to NSEC3 (only) will in the end appear insecure at the end of the roll anyway, so who cares what happens in the middle * a zone that is rolling from NSEC (only) to NSEC3 by addition of NSEC3 records, and intends to retain NSEC records indefinitely, will ignore the NSEC3 records anyway, and thus appear secure. But why would one want to do that? If the RESOLVER supports NSEC3, but does not support NSEC, that would appear to be a banned condition, as NSEC support should be a mandatory requirement of an NSEC3 resolver, at least until some future flag day. But the answer is surely that the zone appears secure (as it did before) until the NSEC3 records disappear. 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 Aug 20 13:19:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6X07-0002Ku-Kk for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 13:19:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00332 for ; Sat, 20 Aug 2005 13:19:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6Wvx-000Erq-L5 for namedroppers-data@psg.com; Sat, 20 Aug 2005 17:15:05 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6Wvv-000Eqj-NZ for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 17:15:04 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 06E9333C21; Sat, 20 Aug 2005 18:15:02 +0100 (BST) Message-ID: <43076515.2080707@algroup.co.uk> Date: Sat, 20 Aug 2005 18:15:01 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> In-Reply-To: <20050820150328.GC10207@vacation.karoshi.com.> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: > On Sat, Aug 20, 2005 at 03:32:46PM +0100, Ben Laurie wrote: > >>bmanning@vacation.karoshi.com wrote: >> >>>On Sat, Aug 20, 2005 at 03:20:32PM +0100, Ben Laurie wrote: >>> >>> >>>>bmanning@vacation.karoshi.com wrote: >>>> >>>> >>>>>>>>-- During roll between NSEC and NSEC3 (and vice-versa), must a >>>>>>>>properly configured resolver that supports both NSEC and NSEC3 >>>>>>>>always see the zone as Secure (never Insecure)? >>>>>>> >>>>>>> >>>>>>>This is real hard, as for this to work the zone must use both NSEC >>>>>>>and NSEC3 at the same time in order to work and validator pics one >>>>>>>to follow at any given moment. >>>>>> >>>>>>Surely not? The server only ever has to use one, since the resolver >>>>>>supports both. So, this seems to me to be trivial - the server switches >>>>> >>>>>>from an all-NSEC zone to an all-NSEC3 zone, and everything Just >>>>> >>>>>>Works(tm). >>>>> >>>>> >>>>> er... how do you -KNOW- all the resolvers that will touch these >>>>> servers support "both" NSEC and NSEC3? >>>>> >>>>> by several educated estimates, there are perhaps 1 or 2 orders of >>>>> magnitude more resolvers out there than servers... and we have >>>>> emperical evidence that getting server code upgraded is a real PITA >>>>> and takes years/decades. >>>> >>>>I don't, but that wasn't the question. >>>> >>> >>> >>> true, but there was that assertion in you last statement above... >>> "...The server only ever has to use one, since the resolver >>> supports both..." which tickled my response. >> >>That was the question asked. > > > thats not a question. thats an assertion based on a premise w/o > factual basis. the assertion "the server only ever has to use one" > is based on the premise "the resolver supports both" ... and > you give no indication as to WHY you believe "the resolver" will > have such capabilities. What was the question again? Since scrolling up seems to be a problem, I'll quote it here at the bottom: "During roll between NSEC and NSEC3 (and vice-versa), must a properly configured resolver that supports both NSEC and NSEC3 always see the zone as Secure (never Insecure)?" Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 20 13:21:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6X2Y-0003SO-0d for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 13:21:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00433 for ; Sat, 20 Aug 2005 13:21:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6X0J-000FWA-8E for namedroppers-data@psg.com; Sat, 20 Aug 2005 17:19:35 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6X0H-000FVs-Lz for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 17:19:33 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j7KHIKKN010871; Sat, 20 Aug 2005 17:18:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j7KHIKXU010870; Sat, 20 Aug 2005 17:18:20 GMT Date: Sat, 20 Aug 2005 17:18:20 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: bmanning@vacation.karoshi.com, Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question Message-ID: <20050820171820.GA10557@vacation.karoshi.com.> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> <43076515.2080707@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43076515.2080707@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > "During roll between NSEC and NSEC3 (and vice-versa), must a properly > configured resolver that supports both NSEC and NSEC3 always see the > zone as Secure (never Insecure)?" > > Ben. ah... i see. i was talking about something else then. --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 Aug 20 13:27:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6X8R-0004yv-Hl for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 13:27:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00580 for ; Sat, 20 Aug 2005 13:27:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6X6G-000GSr-UL for namedroppers-data@psg.com; Sat, 20 Aug 2005 17:25:44 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6X6G-000GSc-1n for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 17:25:44 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A01E433C21; Sat, 20 Aug 2005 18:25:42 +0100 (BST) Message-ID: <43076796.5070200@algroup.co.uk> Date: Sat, 20 Aug 2005 18:25:42 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: bmanning@vacation.karoshi.com, Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > Ben / Bill, > > You guys are talking straight past each-other. > > The original question was: > >> -- During roll between NSEC and NSEC3 (and vice-versa), must a >> properly configured resolver that **** supports both NSEC and NSEC3 *** >> always see the zone as Secure (never Insecure)? > > > So based on the original question, Ben answered (in effect that it > only ever has to use one). > > I think Bill's (now) asking a different question - which is what happens > if the resolver does not support both NSEC and NSEC3. Bill may want to ask that question, but the question he asked was: "how do you -KNOW- all the resolvers that will touch these servers support "both" NSEC and NSEC3?" and my answer is that it was assumed in the question I was answering. > And I think the answer to it is as follows: > > If the resolver supports NSEC, but does not support NSEC3, that: > * a zone that is rolling from NSEC (only) to NSEC3 (only) will in the > end appear insecure at the end of the roll anyway, so who cares what > happens in the middle > * a zone that is rolling from NSEC (only) to NSEC3 by addition of NSEC3 > records, and intends to retain NSEC records indefinitely, will ignore > the NSEC3 records anyway, and thus appear secure. But why would one > want to do that? > > If the RESOLVER supports NSEC3, but does not support NSEC, that would > appear to be a banned condition, as NSEC support should be a mandatory > requirement of an NSEC3 resolver, at least until some future flag day. > But the answer is surely that the zone appears secure (as it did > before) until the NSEC3 records disappear. In this case it goes from being insecure to secure, surely? Since the resolver did not understand the NSEC version of the zone. However, clearly, we would not standardise such foolishness. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 20 13:44:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6XOk-0006jD-Gh for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 13:44:50 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00994 for ; Sat, 20 Aug 2005 13:44:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6XMK-000IpF-D9 for namedroppers-data@psg.com; Sat, 20 Aug 2005 17:42:20 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6XMI-000Ip0-Nr for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 17:42:18 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A291EC2DA7; Sat, 20 Aug 2005 18:42:17 +0100 (BST) Date: Sat, 20 Aug 2005 18:42:16 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: bmanning@vacation.karoshi.com, Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3 requirements question Message-ID: In-Reply-To: <43076796.5070200@algroup.co.uk> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> <43076796.5070200@algroup.co.uk> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 20 August 2005 18:25 +0100 Ben Laurie wrote: >> If the RESOLVER supports NSEC3, but does not support NSEC, that would >> appear to be a banned condition, as NSEC support should be a mandatory >> requirement of an NSEC3 resolver, at least until some future flag day. >> But the answer is surely that the zone appears secure (as it did >> before) until the NSEC3 records disappear. > > In this case it goes from being insecure to secure, surely? Since the > resolver did not understand the NSEC version of the zone. urm, yes. 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 Aug 20 13:59:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Xcf-00014q-UE for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 13:59:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01327 for ; Sat, 20 Aug 2005 13:59:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6XaZ-000LCq-Gb for namedroppers-data@psg.com; Sat, 20 Aug 2005 17:57:03 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6XaX-000LCL-OF for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 17:57:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j7KHtuKN010963; Sat, 20 Aug 2005 17:55:56 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j7KHttah010962; Sat, 20 Aug 2005 17:55:55 GMT Date: Sat, 20 Aug 2005 17:55:55 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: Alex Bligh , bmanning@vacation.karoshi.com, Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question Message-ID: <20050820175555.GB10557@vacation.karoshi.com.> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> <43076796.5070200@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43076796.5070200@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >I think Bill's (now) asking a different question - which is what happens > >if the resolver does not support both NSEC and NSEC3. > > Bill may want to ask that question, but the question he asked was: "how > do you -KNOW- all the resolvers that will touch these servers support > "both" NSEC and NSEC3?" and my answer is that it was assumed in the > question I was answering. two questions there ... > >And I think the answer to it is as follows: > > > >If the resolver supports NSEC, but does not support NSEC3, that: > >* a zone that is rolling from NSEC (only) to NSEC3 (only) will in the > > end appear insecure at the end of the roll anyway, so who cares what > > happens in the middle > >* a zone that is rolling from NSEC (only) to NSEC3 by addition of NSEC3 > > records, and intends to retain NSEC records indefinitely, will ignore > > the NSEC3 records anyway, and thus appear secure. But why would one > > want to do that? > > > >If the RESOLVER supports NSEC3, but does not support NSEC, that would > >appear to be a banned condition, as NSEC support should be a mandatory > >requirement of an NSEC3 resolver, at least until some future flag day. > >But the answer is surely that the zone appears secure (as it did > >before) until the NSEC3 records disappear. > > In this case it goes from being insecure to secure, surely? Since the > resolver did not understand the NSEC version of the zone. > > However, clearly, we would not standardise such foolishness. good answer. seems to point out that "secure" state of a zone is (almost) exclusively defined by the capabilities of the quering resolver... why should NSEC3 only be a banned condition? --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 Aug 20 14:13:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Xqn-0003OY-1h for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 14:13:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01745 for ; Sat, 20 Aug 2005 14:13:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6XoG-000Nk2-C0 for namedroppers-data@psg.com; Sat, 20 Aug 2005 18:11:12 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6XoE-000Njh-C8 for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 18:11:10 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0D2AE33C1D; Sat, 20 Aug 2005 19:11:06 +0100 (BST) Message-ID: <43077239.9070901@algroup.co.uk> Date: Sat, 20 Aug 2005 19:11:05 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Alex Bligh , Namedroppers-owner , Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> <43076796.5070200@algroup.co.uk> <20050820175555.GB10557@vacation.karoshi.com.> In-Reply-To: <20050820175555.GB10557@vacation.karoshi.com.> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: >>>I think Bill's (now) asking a different question - which is what happens >>>if the resolver does not support both NSEC and NSEC3. >> >>Bill may want to ask that question, but the question he asked was: "how >>do you -KNOW- all the resolvers that will touch these servers support >>"both" NSEC and NSEC3?" and my answer is that it was assumed in the >>question I was answering. > > > two questions there ... > > >>>And I think the answer to it is as follows: >>> >>>If the resolver supports NSEC, but does not support NSEC3, that: >>>* a zone that is rolling from NSEC (only) to NSEC3 (only) will in the >>>end appear insecure at the end of the roll anyway, so who cares what >>>happens in the middle >>>* a zone that is rolling from NSEC (only) to NSEC3 by addition of NSEC3 >>>records, and intends to retain NSEC records indefinitely, will ignore >>>the NSEC3 records anyway, and thus appear secure. But why would one >>>want to do that? >>> >>>If the RESOLVER supports NSEC3, but does not support NSEC, that would >>>appear to be a banned condition, as NSEC support should be a mandatory >>>requirement of an NSEC3 resolver, at least until some future flag day. >>>But the answer is surely that the zone appears secure (as it did >>>before) until the NSEC3 records disappear. >> >>In this case it goes from being insecure to secure, surely? Since the >>resolver did not understand the NSEC version of the zone. >> >>However, clearly, we would not standardise such foolishness. > > > good answer. seems to point out that "secure" state > of a zone is (almost) exclusively defined by the capabilities > of the quering resolver... > > why should NSEC3 only be a banned condition? It shouldn't - what should be banned is resolvers that don't understand NSEC. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 20 15:24:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Yx4-0005y4-Dq for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 15:24:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06082 for ; Sat, 20 Aug 2005 15:24:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6Ysy-00081S-T5 for namedroppers-data@psg.com; Sat, 20 Aug 2005 19:20:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6Ysx-00081B-BI for namedroppers@ops.ietf.org; Sat, 20 Aug 2005 19:20:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A1EB513921 for ; Sat, 20 Aug 2005 19:20:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question In-Reply-To: Your message of "Sat, 20 Aug 2005 18:25:42 +0100." <43076796.5070200@algroup.co.uk> References: <6.2.3.4.2.20050802113226.04cfa510@localhost> <430081CB.7050208@algroup.co.uk> <20050820141433.GA10207@vacation.karoshi.com.> <43073C30.8060904@algroup.co.uk> <20050820142550.GB10207@vacation.karoshi.com.> <43073F0E.5020709@algroup.co.uk> <20050820150328.GC10207@vacation.karoshi.com.> <43076796.5070200@algroup.co.uk> Date: Sat, 20 Aug 2005 19:20:06 +0000 Message-Id: <20050820192006.A1EB513921@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # However, clearly, we would not standardise such foolishness. ben, you now owe me one new keyboard. --paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From RobertaIngram@alon.co.uk Sat Aug 20 18:21:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6biC-00018t-MO for dnsext-archive@megatron.ietf.org; Sat, 20 Aug 2005 18:21:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12683 for ; Sat, 20 Aug 2005 18:21:09 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6cIQ-0007pc-Kg for dnsext-archive@ietf.org; Sat, 20 Aug 2005 18:58:39 -0400 Received: from s010600055dfc7f37.sc.shawcable.net ([24.79.143.215]) by mx2.foretec.com with smtp (Exim 4.24) id 1E6bi0-0000tX-2d for dnsext-archive@ietf.org; Sat, 20 Aug 2005 18:21:00 -0400 Received: from ZGs@localhost by mWS.int (8.11.6/8.11.6); Sat, 20 Aug 2005 20:50:36 -0300 Message-ID: From: "Antonio Stewart" Reply-To: "Antonio Stewart" To: dnsext-archive@ietf.org Subject: OEM Adobe, Windows software @ wholesale price$ Date: Sat, 20 Aug 2005 19:46:36 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: RobertaIngram@alon.co.uk Content-Type: multipart/mixed; boundary="--452826867724487091" X-Spam-Score: 1.4 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 rWy ----452826867724487091 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable U
= Opt-in Email Special Offer   =  unsubscribe me
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: qtKhlO0Vi
 

Sales Rank: #1
System requirements  |  Other Versions
= Date Coupon Expires: August 31st, 2005
<= b>Average Customer Review:3D"5 Based on 17077 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2= V 9.0
Adob= e

Choose:
 

List Price:$599.00
Price:$69.99
You Save:$529.01 (90%)



<= b>Availability: Available for INSTANT download!
Coupon Code: NWRqz
 

Sales Rank: #2 System re= quirements  |  Other Vers= ions
Date Coupon Expires: August = 31st, 2005
Average Customer Review: Based on 19372 reviews. Write a = review.

Microsoft Windows XP Professional o= r Longhorn Edition
Microsoft

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>
Choose:
 
List Price:$279.00
Price:$49.99
You = Save:$229.01 (85%)

<= a href=3Dhttp://hotoemsoft.net/?U>

Availability: Available for INSTANT download!=
Coupon Code: TzaQu1B
 

Sales Rank: #3
System requirements  |  Other Versions
Date Co= upon Expires: August 31st, 2005
Avera= ge Customer Review:3D"5 Based on 18775 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
 
=
List Pr= ice:$499.00
Pric= e:$69.99
You Save:$429.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: JoNgL3Id
 

Sales Ra= nk: #4 System requirements  |  Other Versions
Date Coupon Expires:= August 31st, 2005
Average Customer R= eview:3D"5 Based on 184439 reviews. Write a review.

----452826867724487091-- From owner-namedroppers@ops.ietf.org Sun Aug 21 18:18:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6y9K-0007td-PK for dnsext-archive@megatron.ietf.org; Sun, 21 Aug 2005 18:18:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22583 for ; Sun, 21 Aug 2005 18:18:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6y3c-000GGy-Ko for namedroppers-data@psg.com; Sun, 21 Aug 2005 22:12:48 +0000 Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6y3a-000GGj-J5 for namedroppers@ops.ietf.org; Sun, 21 Aug 2005 22:12:46 +0000 Received: from localhost.localdomain (rfb.rfburst.com [66.119.143.249]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j7LMCZac026783; Sun, 21 Aug 2005 16:12:36 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id j7LMBhAd026967; Sun, 21 Aug 2005 16:11:43 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id j7LMBhTU026963; Sun, 21 Aug 2005 16:11:43 -0600 Date: Sun, 21 Aug 2005 16:11:43 -0600 Message-Id: <200508212211.j7LMBhTU026963@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" Reply-To: "The Purple Streak, Hilarie Orman" To: thierry.moreau@connotech.com Cc: namedroppers@ops.ietf.org, Donald.Eastlake@motorola.com In-reply-to: Yourmessage <43009546.6070304@connotech.com> Subject: Re: About draft-ietf-dnsext-ecc-key-07.txt, absence of algorithm restrictionin ECC public key encoding X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk draft-ietf-dnsext-ecc-key-07.txt, "Elliptic Curve KEYs in the DNS" discusses the representation of ECC keys, not the algorithms for using the keys. PKIX chose to define both in one document. Hilarie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From GabrielleEvans@adultsonlytraffic.com Mon Aug 22 07:57:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Avt-0000XK-9b for dnsext-archive@megatron.ietf.org; Mon, 22 Aug 2005 07:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08614 for ; Mon, 22 Aug 2005 07:57:39 -0400 (EDT) Received: from [211.36.156.187] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7BWQ-00065p-QO for dnsext-archive@ietf.org; Mon, 22 Aug 2005 08:35:28 -0400 Received: from 8Und@localhost by IomN.int (8.11.6/8.11.6); Mon, 22 Aug 2005 05:47:48 -0400 Message-ID: From: "Rocco Mckee" Reply-To: "Rocco Mckee" To: dnsext-archive@ietf.org, theron.napier@ietf.org Subject: 80 % Discount on All Adobe, Windows Titles Date: Mon, 22 Aug 2005 02:43:48 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GabrielleEvans@adultsonlytraffic.com Content-Type: multipart/mixed; boundary="--zX19qGRdTJO4FVageuhL" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Coj ----zX19qGRdTJO4FVageuhL Content-Type: text/html; Content-Transfer-Encoding: quoted-printable c
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

9= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 A= dobe Photoshop 9.0
 3 Windows XP Pro
 4 A= dobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Nort= on Antivirus 2005
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  See more by this manufacturer<= /b>
   Microsoft
=    Symantec
   Adobe
  Customers also bought
   these othe= r items...

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 <= a href=3Dhttp://socheapsoft.net/?b>

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (86= %)



Availability:= Available for INSTANT download!
Coupon Code: EzZn38W
 = ;

Sales Rank: #1
System requirements&n= bsp; |  Other Versions=
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based on= 19654 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

= Choose:
 
<= /td>

<= tr><= /table>



Availability: Available for INSTA= NT download!
Coupon Code: mDGdcN3Bx
 

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D"5 Based on 126751 reviews. <= a href=3Dhttp://socheapsoft.net/?u>Write a review.

<= hr noShade SIZE=3D1>
List Price:$599.00
Price:$69.99
You Save:$529.01 (90%)

Microsoft Windows XP Professional or Longhorn Edition
Microsoft

Choose:
&= nbsp;

List Price:$279.00
Price:$49.99
You Save:$229.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: BTC= B4M9
 

Sales Rank: #3
System requ= irements  |  Other Versi= ons
Date Coupon Expires: August 3= 1st, 2005
Average Customer Review: Based on 1137 reviews. Write a r= eview.

Adobe Acrobat Professional V 7.0 Adobe

Choose:<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 width=3D164>
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)



Availability= : Available for INSTANT download!
Coupon Code: EhEEd
&n= bsp;

Sales Rank: #4
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005 Average Customer Review:3D"5 Based= on 11587 reviews. Write a review.=

----zX19qGRdTJO4FVageuhL-- From owner-namedroppers@ops.ietf.org Tue Aug 23 14:29:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dWd-0002r1-OB for dnsext-archive@megatron.ietf.org; Tue, 23 Aug 2005 14:29:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21249 for ; Tue, 23 Aug 2005 14:29:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7dPQ-000CSe-4V for namedroppers-data@psg.com; Tue, 23 Aug 2005 18:22:04 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7dPP-000CSO-8z for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 18:22:03 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j7NIHpKj013271 for ; Tue, 23 Aug 2005 14:17:51 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAACPaW6z; Tue, 23 Aug 05 14:17:48 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j7NIJcAk010391; Tue, 23 Aug 2005 14:19:42 -0400 (EDT) Date: Tue, 23 Aug 2005 14:19:38 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: David Blacka cc: Rob Austein , DNSEXT WG Subject: Re: Opt-in In-Reply-To: <0F075C27-CB1E-4A56-93CD-9FEDCBB6D351@verisignlabs.com> Message-ID: References: <4301F71A.50800@algroup.co.uk> <20050816194625.A261141AB@thrintun.hactrn.net> <0F075C27-CB1E-4A56-93CD-9FEDCBB6D351@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 16 Aug 2005, David Blacka wrote: > > No doubt I'm missing something obvious, but could we solve the > > wildcard interaction problem simply by stating that the opt-foo bit > > can't apply to a range containing a wildcard? That is, can we just > > state that wildcards, if present, must be signed, and that an opt-foo > > NSEC3 means by definition that there is no wildcard in that range? > > It already says that. (Discounting wildcard NS records ;) I'm confused by this, and I'm worried that David and Rob are talking around each other here. It sounded to me like Rob was saying: "there can be no wildcard expansions within an opt'ed-out span" -- basically, wildcards don't work in opt'ed out spans. My understanding of the current spec is that wildcard RR's, because they're not delegations (or, at least, we hope they're not delegations) must be signed. And are applicable everywhere, no matter the opt-foo state of the span or zone. But the draft changes the proof logic since names can be spoofed in/out of an opt'ed-out span. Perhaps I'm just confused, but I think I'd be less confused by talking about what resolvers/validators do, rather than what zone content is allowed. "If you get an unsigned wildcard...." -- 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 Aug 23 14:33:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7da2-0003gX-ME for dnsext-archive@megatron.ietf.org; Tue, 23 Aug 2005 14:33:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21447 for ; Tue, 23 Aug 2005 14:33:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7dWY-000CuS-5X for namedroppers-data@psg.com; Tue, 23 Aug 2005 18:29:26 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7dWX-000CuE-Fx for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 18:29:25 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j7NIPDhD014011 for ; Tue, 23 Aug 2005 14:25:13 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVJaiwB; Tue, 23 Aug 05 14:25:10 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j7NIR8I8010586 for ; Tue, 23 Aug 2005 14:27:08 -0400 (EDT) Date: Tue, 23 Aug 2005 14:27:08 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 1 Aug 2005, Samuel Weiler wrote: > -- must it be possible to smoothly roll between NSEC and NSEC3? > > Specifically I mean: > > -- During roll between NSEC and NSEC3 (and vice-versa), must a > properly configured resolver that supports both NSEC and NSEC3 > always see the zone as Secure (never Insecure)? > > -- Or is it okay to require that the roll between NSEC and NSEC3 go > through an Insecure state? In the three weeks since I posed the above requirements question, I've read (only) two answers, from Alex and Olafur, and they seem to disagree. In the interest of simplifying the work of testing NSEC3, hence getting NSEC3 out the door faster, I propose that the default answer should be consistent with Olafur's: no smooth roll is required -- it's acceptable to have to roll thorugh Insecure to switch between NSEC and NSEC3 (and vice-versa). Accordingly, any NSEC3 testing efforts don't need to look for problems with rolling between NSEC and NSEC3 -- they merely need look for problems rolling from unsigned to NSEC3 (and vice-versa). Absent a more overwhelming statement of "yes, this is a requirement" in the next week or two (which will have left this question on the table for a month, including a physical IETF meeting), I suggest that the requirements doc editors document smooth rollover as a non-requirement. -- 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 Aug 23 14:52:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dt7-0007ij-P9 for dnsext-archive@megatron.ietf.org; Tue, 23 Aug 2005 14:52:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23098 for ; Tue, 23 Aug 2005 14:52:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7doS-000EHi-J5 for namedroppers-data@psg.com; Tue, 23 Aug 2005 18:47:56 +0000 Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7doP-000EHN-Un for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 18:47:54 +0000 Received: from localhost.localdomain (rfb.rfburst.com [66.119.143.249]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j7NIljac022367; Tue, 23 Aug 2005 12:47:46 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id j7NIkkAd017449; Tue, 23 Aug 2005 12:46:46 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id j7NIkkWJ017445; Tue, 23 Aug 2005 12:46:46 -0600 Date: Tue, 23 Aug 2005 12:46:46 -0600 Message-Id: <200508231846.j7NIkkWJ017445@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" Reply-To: "The Purple Streak, Hilarie Orman" To: Ed.Lewis@neustar.biz Cc: namedroppers@ops.ietf.org In-reply-to: Yourmessage Subject: Re: resurrecting wildcards and opt-in X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The discussion has been interesting. It sounds like we need "An Elementary Introduction to the Theory of DNS and DNSSEC". Is there some hope of a simple and verfiable set of rules for the requestor and responder from which one could prove that (a) there is a unique, correct reply to any query (b) a correct signed reply will be accepted by a correctly functioning requestor (c) no signed reply can be undetectably subsituted for the correct signed reply (d) no unsigned reply can be undetectably substituted for the correct signed reply (d) no signed reply can be undetectably subsituted for a correct unsigned reply ? How does one go about proving (a)? Can DNS be modeled as a set of sets with a lattice structure (to accommodate wildcards)? Does the proof need to assume that messages can be inserted but not deleted from the channel? Or can one assume complete channel control by the attacker? Hilarie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 23 15:54:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eqe-00045s-Bi for dnsext-archive@megatron.ietf.org; Tue, 23 Aug 2005 15:54:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27184 for ; Tue, 23 Aug 2005 15:54:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7emb-000JB6-Rm for namedroppers-data@psg.com; Tue, 23 Aug 2005 19:50:05 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7emZ-000J9q-VR for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 19:50:04 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E7emX-00033n-St; Tue, 23 Aug 2005 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-2929bis-01.txt Message-Id: Date: Tue, 23 Aug 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-2929bis-01.txt Pages : 16 Date : 2005-8-23 Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, RR types, operation codes, error codes, RR header bits, and AFSDB subtypes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-2929bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-2929bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-23135821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-2929bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-2929bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-23135821.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 23 20:00:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7igh-00062o-FC for dnsext-archive@megatron.ietf.org; Tue, 23 Aug 2005 20:00:15 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20739 for ; Tue, 23 Aug 2005 20:00:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7iZq-000AKo-Bo for namedroppers-data@psg.com; Tue, 23 Aug 2005 23:53:10 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7iZp-000AKY-FW for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 23:53:09 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E7iZn-0009qm-Tb for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 19:53:08 -0400 Received: by internaut.com (Postfix, from userid 1000) id 2AC7360DC6; Tue, 23 Aug 2005 16:53:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 1E8CA60DC2 for ; Tue, 23 Aug 2005 16:53:07 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 23 Aug 2005 16:53:07 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR issue 95: Negative Caching Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 95 (submitted in IETF last call) is enclosed below. The proposed resolution is as follows: In Section 2.9, change: "Responders SHOULD insert an SOA record into the authority section of a negative response, to facilitate negative caching as specified in [RFC2308]. The owner name of this SOA record MUST be equal to the query name." To: "Responders SHOULD insert an SOA record into the authority section of a negative response, to facilitate negative caching as specified in [RFC2308]. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. The owner name of the SOA record (MNAME) MUST be set to the query name. The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored by senders. Negative responses without SOA records SHOULD NOT be cached." ------------------------------------------------------------------------ Issue 95: Negative Caching Submitter: Yi Zhao Submitter email address: yizhao@microsoft.com Date first submitted: August 11, 2005 Reference: Document: LLMNR-42 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Which errors are negatively cached in LLMNR? What determines how long they are cached for? What are the recommended values in the fields for the SOA RR included in negative responses? [BA] LLMNR-42 Section 2.9 says: " Responders SHOULD insert an SOA record into the authority section of a negative response, to facilitate negative caching as specified in [RFC2308]. The owner name of this SOA record MUST be equal to the query name." According to RFC 2308, Section 2: " The most common negative responses indicate that a particular RRset does not exist in the DNS. The first sections of this document deal with this case. Other negative responses can indicate failures of a nameserver, those are dealt with in section 7 (Other Negative Responses)." [RFC2308] Section 2.1, describes RCODE=3 (NXDOMAIN) errors. Section 2.2 describes NODATA errors (RCODE=0 and no RRs in the answer section). Section 7.1 describes Server failure (optional) and 7.2 describes Dead/Unreachable server (optional) errors. LLMNR-42, Section 2.1.1 states: " Since LLMNR responders only respond to LLMNR queries for names for which they are authoritative, LLMNR responders MUST NOT respond with an RCODE of 3; instead, they should not respond at all." I don't recommend attempting to negatively cache Server failure or Dead/Unreachable server errors in LLMNR. Since an LLMNR response with RCODE=3 is not permitted, the primary error to be negatively cached in LLMNR is NODATA (RCODE=0 and no RRs in the answer section). Such a response can be received if an LLMNR responder is authoritative for a name but the queried RR does not exist. For example, a responder as an A RR, but no AAAA RR, and the query is for the AAAA RR. Note that a conflict can be detected from an LLMNR response, even if no data is present, because a response indicates that the responder believes it is authoritative for the name. [RFC2308] Section 3 states: Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. The TTL SIG record associated with the SOA record should also be trimmed in line with the SOA's TTL. This logic for determining the TTL in negative caching is also used in LLMNR. SOA The primary use of SOA in LLMNR is for negative caching. Without returning the SOA in a NODATA error, negative caching is not possible. [RFC2308] Section 5: Negative responses without SOA records SHOULD NOT be cached as there is no way to prevent the negative responses looping forever between a pair of servers even with a short TTL. My advice is to include SOA RR in an LLMNR response so as to allow negative caching and set the MINIMUM field and the TTL to the same value as the default TTL for LLMNR responses. Suggestion for fields in the SOA RR: MNAME: This is the LLMNR Responder's name (same as the query) RNAME: Irrelevant to LLMNR. SERIAL: Set to YYYYMMDDXXXXXXX where YYYY = year, MM = month, DD = day, XXXXXXX = a counter. REFRESH: Irrelevant to LLMNR (but can be set to same value as MINIMUM) RETRY: Irrelevant to LLMNR (but can be set to same value as MINIMUM) EXPIRE: Set to a larger value than the default TTL (e.g. one week). MINIMUM: Set to the same value as the default TTL for LLMNR responses. -- to unsubscribe send a message to namedroppers-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 Aug 23 20:00:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ign-00063d-ED for dnsext-archive@megatron.ietf.org; Tue, 23 Aug 2005 20:00:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20745 for ; Tue, 23 Aug 2005 20:00:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7icA-000Aa7-GV for namedroppers-data@psg.com; Tue, 23 Aug 2005 23:55:34 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7ic9-000AZs-NU for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 23:55:33 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E7ic8-000AIc-K7 for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 19:55:32 -0400 Received: by internaut.com (Postfix, from userid 1000) id CB38660DC6; Tue, 23 Aug 2005 16:55:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id BEDC960DC2 for ; Tue, 23 Aug 2005 16:55:31 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 23 Aug 2005 16:55:31 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 96: LLMNR Usage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 96 is enclosed below. The proposed resolution is as follows: In section 2, change: " An LLMNR sender may send a request for any name. However, by default, LLMNR requests SHOULD be sent only when one of the following conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this implies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. A dual stack host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to use of LLMNR." To: "An LLMNR sender MAY send a request for any name. By default, LLMNR requests SHOULD NOT be sent unless one of the following conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism. A dual stack host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to sending LLMNR queries. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this implies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. Where a single call to the resolver generates DNS queries for A and AAAA RRs, an implementation MAY choose not to send LLMNR queries if any of the DNS queries is successful. An LLMNR query SHOULD only be sent for the originally requested name; the DNS searchlist is not used to form additional LLMNR queries." --------------------------------------------------------------------------- Issue 96: LLMNR Usage Submitter: Yi Zhao Submitter email address: yizhao@microsoft.com Date first submitted: August 11, 2005 Reference: Document: LLMNR-42 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: In the case that a DNS query fails to produce an answer as described in Section 2, does LLMNR use the searchlist to compose its own set of queries or does it just send a query for the originally requested name? Is it always the case that an LLMNR query should be sent when a DNS query returns rcode 0 and no RRs in the answer section or rcode 3? For example, if separate IPv4 and IPv6 DNS queries are sent for the same name, then very frequently an A RR will be present, but a AAAA RR will not be (RCODE=0, no RRs in the answer section). Do we have to send an LLMNR query in this situation? What if RRs are returned in the authority or additional sections? [BA] Section 2 of LLMNR-42 states: [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. A dual stack host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to use of LLMNR. As a result, LLMNR will only be used once DNS has exhausted the searchlist. Since the DNS searchlist does not apply to LLMNR, LLMNR should only send a query for the originally requested name; the searchlist is not used to form additional LLMNR queries. When are LLMNR queries sent? LLMNR-42 Section 2 states: An LLMNR sender may send a request for any name. However, by default, LLMNR requests SHOULD be sent only when one of the following conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this implies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. A dual stack host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to use of LLMNR. The implication here is that either condition [1] or [2] needs to be met to send an LLMNR query. However, this does not imply that an LLMNR query SHOULD be sent if either condition applies. In the case where the intent is to obtain an A or AAAA RR, but not necessarily both, it is not necessary to send an LLMNR query if either the A or AAAA RR query succeeds. -- to unsubscribe send a message to namedroppers-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 Aug 23 20:02:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iiP-0006ST-7a for dnsext-archive@megatron.ietf.org; Tue, 23 Aug 2005 20:02:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20860 for ; Tue, 23 Aug 2005 20:01:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7if5-000AsZ-SR for namedroppers-data@psg.com; Tue, 23 Aug 2005 23:58:35 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7if4-000AsF-V8 for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 23:58:35 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E7if3-000AzE-KJ for namedroppers@ops.ietf.org; Tue, 23 Aug 2005 19:58:33 -0400 Received: by internaut.com (Postfix, from userid 1000) id E9D0860DC6; Tue, 23 Aug 2005 16:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id D7EE360DC2 for ; Tue, 23 Aug 2005 16:58:32 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 23 Aug 2005 16:58:32 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 97: Merging Responses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 97 (submitted in IETF last call) is enclosed below. The proposed resolution is as follows: Change Section 2.2 to the following: "2.2. Sender Behavior A sender MAY send an LLMNR query for any legal resource record type (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. As described in Section 2.4, a sender MAY also send a unicast query. Sections 2 and 3 describe the circumstances in which LLMNR queries may be sent. The sender MUST anticipate receiving no replies to some LLMNR queries, in the event that no responders are available within the link-scope. If no response is received, a resolver treats it as a response that the name does not exist (RCODE=3 is returned). When multiple valid LLMNR responses are received with the 'C' bit set, they SHOULD be concatenated and treated in the same manner that multiple RRs received from the same DNS server would be. However, responses with the 'C' bit set SHOULD NOT be concatenated with responses with the 'C' bit clear; instead, only the responses with the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are received along with error response(s), then the error responses are silently discarded. If error responses are received from both DNS and LLMNR, then the lowest RCODE value should be returned. For example, if either DNS or LLMNR receives a response with RCODE=0, then this should returned to the caller. Since the responder may order the RRs in the response so as to indicate preference, the sender SHOULD preserve ordering in the response to the querying application." In Section 2.3, change: "[g] If a responder is authoritative for a name, it SHOULD respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has." To: "[g] If a responder is authoritative for a name, it MUST respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has." In Section 2.7, change: "If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Queries with the 'C' bit set MUST be sent over multicast UDP and MUST NOT be retransmitted. Responses to queries with the 'C' bit set are not taken into account within retransmission timeout computations. An LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response has been received, or if it is necessary to collect all potential responses, such as if a uniqueness verification query is being made. Otherwise an LLMNR sender SHOULD consider a multicast query answered after the first response is received, if that response has the 'C' bit clear. However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. Since it is possible for a response with the 'C' bit clear to be followed by a response with the 'C' bit set, an LLMNR sender SHOULD be prepared to process additional responses for the purposes of conflict detection and LLMNR_TIMEOUT estimation, even after it has considered a query answered." To: "If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Queries with the 'C' bit set MUST be sent over multicast UDP and MUST NOT be retransmitted. Since queries with the 'C' bit set are not expected to elicit a response, these queries do not affect retransmission timeout computations. An LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response has been received, or if it is necessary to collect all potential responses, such as if a uniqueness verification query is being made. Otherwise an LLMNR sender SHOULD consider a multicast query answered after the first response is received, if that response has the 'C' bit clear. However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. Since it is possible for a response with the 'C' bit clear to be followed by a response with the 'C' bit set, an LLMNR sender SHOULD be prepared to process additional responses for the purposes of conflict detection and LLMNR_TIMEOUT estimation, even after it has considered a query answered." ----------------------------------------------------------------------- Issue 97: Merging Responses Submitter: Yi Zhao Submitter email address: yizhao@microsoft.com Date first submitted: August 11, 2005 Reference: Document: LLMNR-42 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: When both DNS and LLMNR fail to return an answer, what error should be returned? Does the error returned by DNS always take precedence? How are multiple responses combined if some responses have the 'C' bit set and others do not? What if one or more responses contain errors or RRs in the authority or additional sections? [BA] Merging of Multiple Responses If one response has an error (RCODE = 0 and no answer RRs), but the other responses contain answers, the error should be discarded. It is possible for a sender to receive multiple responses to a query, some with the 'C' bit set, and some without the 'C' bit set. In this case I'd suggest that only responses with the 'C' bit set should be returned, since if there is a conflict between responders who believe their responses are UNIQUE, and responders who don't, then the UNIQUE responder will need to stop using the name. As a result, merging only the non-unique responses produces the most stable result. Which error is returned? I think that the error returned is determined by the first authoritative name server found. For example, if DNS returns RCODE=3 and no RRs in the answer section, and LLMNR returns RCODE=0 and no answers in the RR section, then the implication is that the LLMNR responder is authoritative for the name. Therefore I think the error should be RCODE=0 not RCODE=3. If no answer is received from LLMNR, then I think the DNS error should take precedence (RCODE=3). This despite the statement in LLMNR-42 Section 2.2: The sender MUST anticipate receiving no replies to some LLMNR queries, in the event that no responders are available within the link-scope or in the event no positive non-null responses exist for the transmitted query. If no positive response is received, a resolver treats it as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). The problem with this paragraph is that the lack of a response is NOT treated the same as RCODE=0 and an empty anwer section in conflict detection, nor in the merging of DNS and LLMNR errors. Receiving any response indicates that a responder exists that is authoritative for the name, whereas receiving no response does not imply this. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 24 05:20:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7rR0-0004gE-56 for dnsext-archive@megatron.ietf.org; Wed, 24 Aug 2005 05:20:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08843 for ; Wed, 24 Aug 2005 05:20:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7rMj-000O1z-6g for namedroppers-data@psg.com; Wed, 24 Aug 2005 09:16:13 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7rMg-000O1S-BU for namedroppers@ops.ietf.org; Wed, 24 Aug 2005 09:16:10 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C72C2C2DA9; Wed, 24 Aug 2005 10:16:08 +0100 (BST) Date: Wed, 24 Aug 2005 10:16:08 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3 requirements question Message-ID: <8AEB201826C37EC1E97F570A@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 23 August 2005 14:27 -0400 Samuel Weiler wrote: > In the three weeks since I posed the above requirements question, I've > read (only) two answers, from Alex and Olafur, and they seem to > disagree. I don't feel that strongly about it & I am happy to go with your suggestion. 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 Wed Aug 24 11:02:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wmA-0006zI-UU for dnsext-archive@megatron.ietf.org; Wed, 24 Aug 2005 11:02:50 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26513 for ; Wed, 24 Aug 2005 11:02:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7whz-000MOC-MW for namedroppers-data@psg.com; Wed, 24 Aug 2005 14:58:31 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7why-000MNv-Nh for namedroppers@ops.ietf.org; Wed, 24 Aug 2005 14:58:30 +0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j7OF8jiR025314 for ; Wed, 24 Aug 2005 08:08:45 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j7OF5BKE017509 for ; Wed, 24 Aug 2005 10:05:12 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Aug 2005 10:58:27 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810A8382AE@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-01.txt Date: Wed, 24 Aug 2005 10:58:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I believe this version incorporates all the changes that were discussed and seemed to met approval at the DNSEXT WG meeting in Paris. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, August 23, 2005 3:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-2929bis-01.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-01.txt Pages : 16 Date : 2005-8-23 Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, RR types, operation codes, error codes, RR header bits, and AFSDB subtypes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-2929bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-2929bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From dapo_thomson03@yahoo.com Wed Aug 24 14:07:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zf9-0006g5-FI for dnsext-archive@megatron.ietf.org; Wed, 24 Aug 2005 14:07:47 -0400 Received: from web31201.mail.mud.yahoo.com (web31201.mail.mud.yahoo.com [68.142.200.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09249 for ; Wed, 24 Aug 2005 14:07:46 -0400 (EDT) Received: (qmail 36567 invoked by uid 60001); 24 Aug 2005 18:07:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UBv3G0fwUpri3lme+nvjqcxul0qZWZeqoWFppHyruX9YL4wBTFfONWqOV90EPHOcLc3J11CUT4SacBSQ2Sl+LMQw9e4HbKOAk+1xz8chvTeyeyEtx3926AFNzJf8rFzjHppNczL5OTAgxwKufEgCpRE+OZJJ1q9G9d7v0O3sRmQ= ; Message-ID: <20050824180715.36565.qmail@web31201.mail.mud.yahoo.com> Received: from [193.220.188.189] by web31201.mail.mud.yahoo.com via HTTP; Wed, 24 Aug 2005 11:07:15 PDT Date: Wed, 24 Aug 2005 11:07:15 -0700 (PDT) From: dapo thomson Subject: HELLO To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1463279748-1124906835=:34625" Content-Transfer-Encoding: 8bit --0-1463279748-1124906835=:34625 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit FROM MISS DAPO THOMSON . ABIDJAN-IVORY COAST. GREETINGS, 00225(08477160) I WRITE TO INTIMATE YOU OF A MATTER THAT REQUIRES AN URGENT ATTENTION,WITH REGARD TO YOUR REPOSED PERSONALITY AS A RELIABLE, TRUSTWORTHY AND GOD FEARING PERSON. I MUST NOT FAIL TO INTRODUCE MYSELF TO YOU, I AM MISS DAPO THOMSON A CITIZEN OF SIERRA-LEONE, THE DAUGHTER OF THE LATE MR LAURENT THOMSON, MY FATHER WAS A GOLD AND COACO MERCHANT, BASED IN ABIDJAN (IVORY COAST) HE WAS POISONED TO DEATH BY HIS BUSINESS ASSOCIATES ON ONE OF THEIR BUSINESS TRIPS BUT BEFORE THE DEATH OF MY FATHER IN A PRIVATE HOSPITAL HERE IN ABIDJAN, HE SECRETLY CALLED ME ON HIS BEDSIDE AND TOLD ME THAT HE HAS A SUM OF USD$ 18 MILLION, DEPOSITED IN ONE TRUK BOX KEPT INTO A PRIVATE SECURITY AND STORAGE COMPANY HERE IN ABIDJAN. THAT HE USED MY NAME AS HIS ONLY DAUGHTER FOR THE BENEFICIARY IN DEPOSITING OF THE FUND HE ALSO EXPLAINED TO ME THAT IT WAS BECAUSE OF THIS WEALTH THAT HE WAS POISONED BY HIS BUSINESS ASSOCIATES, THAT I SHOULD SEEK FOR A FOREIGN PARTNER IN A COUNTRY OF MY CHOICE WHERE I WILL TRANSFER THIS MONEY AND USE IT FOR INVESTMENT PURPOSE. I AM HUMBLY SEEKING YOUR ASSISTANCE IN THE FOLLOWING WAYS. YOU WILL SERVE AS THE GUARDIAN OF THIS MONEY SINCE I AM A GIRL OF 24 YEARS, YOU WILL PROVIDE OR LOOK FOR A LUCRATIVE VENTURE WHERE THIS MONEY CAN BE INVESTED ON, TOGETHER WITH YOU.I HAVE AGREED TO INVEST MY MONEY VIABLE IN ANY OVERSEA COUNTRY THROUGH YOUR ASSISTANCE AND DIRECTIVES BEFORE PROCEEDING WE WILL GET TO BE MORE FAMILIAR AND ALSO GO INTO AN UNDERSTANDING WORKING AGREEMENT BECAUSE OUR LIFES AND FUTURE NOW DEPENDS ON THIS VERY MONEY. ME AND MY YOUNGER BROTHER HAVE AGREED TO GIVE YOU 20% OF THE TOTAL SUM OF ((USD18MILLION)) FOR YOUR ASSISTANCE TO US.WHILE THE REST OF THE MONEY WILL BE USED FOR THE INVESTMENT TOGETHER WITH YOU. I SINCERELY WISH TO INTRODUCE AND MAKE YOU MY BUSINESS PARTNER AND ADVISORY CONSULTANT OF MY PROPOSED INVESTMENT IN YOUR COUNTRY. SO IF YOU CAN BE ABLE TO ASSIST ME ,PLEASE DO URGENTLY REPLY ME SO THAT I WILL LINK YOU FOR FURTHER DETAILS,AND DONT FORGET TO GIVE ME YOUR PRIVATE TELEPHONE AND FAX NUMBERS WHILE REPLYING THIS LETTER. THANKS AND GOD BLESS YOU . N.B I AM HEAR WITH MY YOUNGER BROTHER MARK THOMSON. YOURS SINCERELY , MISS DAPO THOMSON. PLEASE FORSECURITY REASON, TRY AND REACH ME THROUGH MY PRIVATE EMAIL: dapothoms@yahoo.ie __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------- Start your day with Yahoo! - make it your home page --0-1463279748-1124906835=:34625 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
FROM MISS DAPO THOMSON .
ABIDJAN-IVORY COAST.
GREETINGS,
00225(08477160)
I WRITE TO INTIMATE YOU OF A MATTER THAT REQUIRES AN URGENT ATTENTION,WITH REGARD TO YOUR REPOSED PERSONALITY AS A RELIABLE, TRUSTWORTHY AND GOD FEARING PERSON.
 
I MUST NOT FAIL TO INTRODUCE MYSELF TO YOU, I AM MISS DAPO THOMSON A CITIZEN OF SIERRA-LEONE, THE DAUGHTER OF THE LATE MR LAURENT THOMSON, MY FATHER WAS A GOLD AND COACO  MERCHANT, BASED IN ABIDJAN (IVORY COAST) HE WAS POISONED TO DEATH BY HIS BUSINESS ASSOCIATES ON ONE OF THEIR BUSINESS TRIPS BUT BEFORE THE DEATH OF MY FATHER IN A PRIVATE HOSPITAL HERE IN ABIDJAN, HE SECRETLY CALLED ME ON HIS BEDSIDE AND TOLD ME THAT HE HAS A SUM OF USD$ 18 MILLION, DEPOSITED IN ONE TRUK BOX KEPT INTO A  PRIVATE SECURITY AND STORAGE COMPANY HERE IN ABIDJAN.
 
THAT HE USED MY NAME AS HIS ONLY DAUGHTER FOR THE BENEFICIARY IN DEPOSITING OF THE FUND HE ALSO EXPLAINED TO ME THAT IT WAS BECAUSE OF THIS WEALTH THAT HE WAS POISONED BY HIS BUSINESS ASSOCIATES, THAT I SHOULD SEEK FOR A FOREIGN PARTNER IN A COUNTRY OF MY CHOICE WHERE I WILL TRANSFER THIS MONEY AND USE IT FOR INVESTMENT PURPOSE.
I AM HUMBLY SEEKING YOUR ASSISTANCE IN THE FOLLOWING WAYS. YOU WILL SERVE AS THE GUARDIAN OF THIS MONEY SINCE I AM A GIRL OF 24 YEARS, YOU WILL PROVIDE OR LOOK FOR A LUCRATIVE VENTURE WHERE THIS MONEY CAN BE INVESTED ON, TOGETHER WITH YOU.I HAVE AGREED TO INVEST MY MONEY VIABLE IN ANY OVERSEA COUNTRY THROUGH YOUR ASSISTANCE AND DIRECTIVES BEFORE PROCEEDING WE WILL GET TO BE MORE FAMILIAR AND ALSO GO INTO AN UNDERSTANDING WORKING AGREEMENT BECAUSE OUR LIFES AND FUTURE NOW DEPENDS ON THIS VERY MONEY.
 
ME AND MY YOUNGER BROTHER HAVE AGREED TO GIVE YOU 20% OF THE TOTAL SUM OF ((USD18MILLION)) FOR YOUR ASSISTANCE TO US.WHILE THE REST OF THE MONEY WILL BE USED FOR THE INVESTMENT TOGETHER WITH YOU. I SINCERELY WISH TO INTRODUCE AND MAKE YOU MY BUSINESS PARTNER AND ADVISORY CONSULTANT OF MY PROPOSED INVESTMENT IN YOUR COUNTRY.
SO IF YOU CAN BE ABLE TO ASSIST ME ,PLEASE DO URGENTLY REPLY ME SO THAT I WILL LINK YOU FOR FURTHER DETAILS,AND DONT FORGET TO GIVE ME YOUR PRIVATE TELEPHONE AND FAX NUMBERS WHILE REPLYING THIS LETTER.
THANKS AND GOD BLESS YOU .
 
N.B I AM HEAR WITH MY YOUNGER  BROTHER MARK THOMSON.
YOURS SINCERELY ,
MISS DAPO THOMSON.
PLEASE FORSECURITY REASON, TRY AND REACH ME THROUGH MY PRIVATE EMAIL: dapothoms@yahoo.ie

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Start your day with Yahoo! - make it your home page --0-1463279748-1124906835=:34625-- From owner-namedroppers@ops.ietf.org Thu Aug 25 12:23:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KVs-0006Hz-7o for dnsext-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:23:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27438 for ; Thu, 25 Aug 2005 12:23:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8KPu-0000xL-2O for namedroppers-data@psg.com; Thu, 25 Aug 2005 16:17:26 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8KPo-0000wU-Vo for namedroppers@ops.ietf.org; Thu, 25 Aug 2005 16:17:22 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5B5A233C1D; Thu, 25 Aug 2005 17:17:08 +0100 (BST) Message-ID: <430DEF07.3040105@algroup.co.uk> Date: Thu, 25 Aug 2005 17:17:11 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 requirements question References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > On Mon, 1 Aug 2005, Samuel Weiler wrote: > > >>-- must it be possible to smoothly roll between NSEC and NSEC3? >> >>Specifically I mean: >> >>-- During roll between NSEC and NSEC3 (and vice-versa), must a >> properly configured resolver that supports both NSEC and NSEC3 >> always see the zone as Secure (never Insecure)? >> >>-- Or is it okay to require that the roll between NSEC and NSEC3 go >> through an Insecure state? > > > In the three weeks since I posed the above requirements question, I've > read (only) two answers, from Alex and Olafur, and they seem to > disagree. > > In the interest of simplifying the work of testing NSEC3, hence > getting NSEC3 out the door faster, I propose that the default answer > should be consistent with Olafur's: no smooth roll is required -- it's > acceptable to have to roll thorugh Insecure to switch between NSEC and > NSEC3 (and vice-versa). Accordingly, any NSEC3 testing efforts don't > need to look for problems with rolling between NSEC and NSEC3 -- they > merely need look for problems rolling from unsigned to NSEC3 (and > vice-versa). > > Absent a more overwhelming statement of "yes, this is a requirement" > in the next week or two (which will have left this question on the > table for a month, including a physical IETF meeting), I suggest that > the requirements doc editors document smooth rollover as a > non-requirement. I still claim it isn't an issue, but I'm also totally happy with it being a non-requirement. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Thu Aug 25 22:34:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8U3R-0007G8-IE for dnsext-archive@megatron.ietf.org; Thu, 25 Aug 2005 22:34:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08862 for ; Thu, 25 Aug 2005 22:34:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Tyh-000MXG-Td for namedroppers-data@psg.com; Fri, 26 Aug 2005 02:29:59 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8Tyg-000MX1-DY for namedroppers@ops.ietf.org; Fri, 26 Aug 2005 02:29:59 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7Q2TjUY003140; Thu, 25 Aug 2005 22:29:55 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Thu, 25 Aug 2005 22:29:55 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: opt-in and wild card discussion Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In reference to http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01162.html: >The discussion has been interesting. It sounds like we need "An >Elementary Introduction to the Theory of DNS and DNSSEC". Is there >some hope of a simple and verfiable set of rules for the requestor and >responder from which one could prove that > >(a) there is a unique, correct reply to any query >(b) a correct signed reply will be accepted by a correctly functioning > requestor >(c) no signed reply can be undetectably subsituted for > the correct signed reply >(d) no unsigned reply can be undetectably substituted for the > correct signed reply >(d) no signed reply can be undetectably subsituted for a correct >unsigned reply > > ? > >How does one go about proving (a)? Can DNS be modeled as a set of >sets with a lattice structure (to accommodate wildcards)? > >Does the proof need to assume that messages can be inserted but not >deleted from the channel? Or can one assume complete channel control >by the attacker? I suppose the answer to the first question is yes. That is, there is hope. I recall a conversation amongst those of us working in close quarters in the early days (close quarters meaning, in office, hence nothing in email) on the purpose of DNSSEC. One opinion was that DNSSEC was meant solely to say that what goes into the master server comes out of the resolver - no changes, no deviations. The contrasting opinion of the day was that the resolver would return the data it received along with some measure of surety of the data so that the application could act accordingly. Of those two opinions, a consensus was and has never been achieved, at least explicitly. I think that it is unfortunate, because settling this would have gone a long way to defining the "finish line." A third opinion was floated and discarded, that DNSSEC assured the accuracy of the data. If the administrator of the DNS mistyped the IP address in an address record, DNSSEC would not fix this. So, for (a), there is no "correctness" principle in DNSSEC, in the sense of data correctness. Uniqueness is not an accurate adjective to apply to a DNS answer, much less an DNSSEC answer. DNS strives for coherency, meaning that if you ask any source in the distributed database you should get the same answer. When you combine caching and the lack of a time element (recall that in protocols pre-NTP we avoided time like the plaque), coherent answers aren't guaranteed to be unique in that coherency is meant "at a point in time" and "not for all time." DNSSEC did not set out to fix that design point in DNS. Although DNSSEC adds the notion of (absolute) time, it is still falls short of being a versioning time stamp of data. E.g., we have never bothered to hammer out the semantics of an RRSet signed for Monday and Wednesday in two different signatures, and the same set with a different value signed for Tuesday. So, for the other half of (a), DNSSEC does not guarantee uniqueness. Moving on to (b), there is no guarantee that a correct signed reply will be accepted by a correctly functioning requestor. DNS in very much wedded to UDP and all that unreliable datagram transports entail. There is no session or higher layer contract between client and server in the protocol. (For reference, see RFC 3090, which discusses the state of a zone in the eyes of DNSSEC. Although it is quite dated with respect to the DS record and type code roll, the concepts hold up.) In my view, DNSSEC is all about the resolver building trust in an answer. The role of the zone is to provide enough data to allow the resolver to do this. A correctly functioning resolver is, at all times, permitted to "follow local policy." This could entail, for example, trusting a public key distributed be a so-called "alternate root" administration, not trusting any public key, trusting a "look-aside" key (meaning a key owned by a domain that is not a parent of the target data). All that a zone administrator (represented by a server) can do is meet the conventionally known standards of securing a zone (as in 3090) while also minding the policies of the "resolvers of interest." A zone can expect no more - for example, DNSSEC does not defend against a flood of unwanted traffic preventing the server from hearing earnest queries. All a zone owner can expect to achieve is offering ancillary data to allow the resolver to make its own judgement. So - if a local policy is to trust the public key of a so-called "alternate root", data signed by a zone conforming to the "non-alternate" root will be rejected by the resolver. Hence, the answer to (b) is no. For (c) and (d), we have to drop the premise of "correct." But the other parts of the questions I'll address. (c) Can a signed answer be substituted for an unsigned answer. Let's assume that, having a comprehensive view, an RRSet is supposed to be unsigned. Also, let's assume that a conventional root is in use and it is signed. In this case, at some point there ought to be a delegation point that can prove there is no DS RRSet. (This is why I believe, much to the chagrin of Mike St. Johns that authenticated denial is a must have feature of DNSSEC.) In this case, a resolver can retrieve the chain of DS RRSets, NSEC RRSets, and keys, needed to see that the desired data is outside of the island of security. Keep in mind that the RRSet may still be (validly) signed, but the signature is useless to the resolver, and DNSSEC is all about the resolver. (d) Similar to (c), a resolver ought to see a sequence of DS RRSets to the desired data. Assuming no cryptographic algorithm problems, the resolver ought to build up an expectation of seeing security data (RRSIG). One of the first rules in security is that the environment ought to meet expectations. (Is the second (d) the same as (c)?) Now, for the after-questions. DNS is to be modeled (but not necessarily implemented) as a graph-theory tree on a two dimensional plane, with data sets orthogonal to the plane of the tree. (My math terminology has gotten rusty over the years.) Domain name are "paths" or "routes" from the root of the tree to some location in the data space. (This is fairly explicitly said in RFC 1034.) The look up algorithm in the infamous 4.3.2 of 1034 makes it clear that looking for a name is done first by travelling the tree "down" to the end of the domain name's indicated path. (Because there is an absolute start, there is no distinguishing between a route or address.) Once the right address in the tree is determined (that includes CNAME, DNAME, and wildcard synthesis), the types are consulted. "Types" exist in another dimension, if you will. As far as message passing amongst protocol elements, it is considered to be untrustworthy. DNSSEC, as defined in RFC 403x makes no guarantee of message security, just DNS(SEC) element to DNS(SEC) element security. Message security is addressed (in one fashion) by TSIG and SIG(0). Whether or not the latter concepts are part of DNSSEC is open to debate - albeit an academic debate. I think the biggest technical obstacle to DNSSEC, speaking in hindsight, is that DNS seems to promise a clear line of authority over records (the zone concept), but the promise is not met by the message structure (lack of authority for all the names in a CNAME chain), not met by the delegation mechanics (authority for the NS existence is by parent, contents by child), and not by the operational agreements of the DNS. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-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 Aug 26 16:02:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8kPb-0004tp-EG for dnsext-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:02:51 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14118 for ; Fri, 26 Aug 2005 16:02:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8kKE-000Ly3-69 for namedroppers-data@psg.com; Fri, 26 Aug 2005 19:57:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8kKC-000Lxf-Tv for namedroppers@ops.ietf.org; Fri, 26 Aug 2005 19:57:17 +0000 Received: from [10.31.32.172] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7QJv7Ja002331; Fri, 26 Aug 2005 15:57:08 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200508261616.j7QGGafO000827@localhost.localdomain> References: <200508261616.j7QGGafO000827@localhost.localdomain> Date: Fri, 26 Aug 2005 15:51:24 -0400 To: "Hilarie Orman" From: Edward Lewis Subject: Re: opt-in and wild card discussion Cc: Ed.Lewis@neustar.biz, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:16 -0600 8/26/05, Hilarie Orman wrote: >Thanks for your answers. I think they are slightly larger than my >questions, though. The context is simply between two entities, a >requestor and a responder (not a requestor and a distributed >database), and when I saw "accept" I mean "if received, will be >accepted as a corect". And "the second (d)", which should be (e), >differs from the previous (d) by two characters ("un"). >And by "accept" I mean "can establish a chain of trust". I'll quibble with the term "correct" and substitute "authentic." In the sense that the administrator could have made a typographic error. I suspect this isn't the detail you refer to, but I have a knee-jerk reaction to the word "correct" in the context of DNSSEC. Overall, the answer is no. In the pure theoretic sense, there is no covenant between requestor and responder. A requestor's right to a local policy prevents any guarantee. In practice, there will probably be a covenant provided by the producer of the software in use - e.g., "burning in" a trusted key for the (a) root zone. (I leave this open to cover cases in which DNS implementations are used in spaces not associated with the Internet.) >Your discussion of the tree of records gets at the heart of the >matter (btw, "2-D tree" is redundant). This model may be OK >for DNS-nonSEC, but there are several more rules for DNSSEC. >It's the formalization of those rules and the modified lookup >rules that I'm hoping to nail down. Ironically, I did twinge when I decided to add "2-D" as an adjective of the tree. I meant that in the sense that I envision the tree as being drawn on a flat piece of paper, with the RRSet's sticking up like little flags. I suppose what you are referring to is the authorization model, which originally was to be more flexible (RFC 2065). RFC 3008 was the first documentation resulting from our frustration with a flexible authorization model, RFC's 4034, et.al., encode a rule that the signer field has to be the zone name. There was a DARPA research effort to examine a more flexible authorization model, I don't know what results it produced. The running assumption today is that the authorization space is isomorphic to the data (zone) space. There are proposals to "break" this, but for the better part of the last decade no one has spent considerable time studying an "alternate authorization" model. Certainly, no one has been successful in deriving one that is both easily understood and more flexible than what we do now. >I'll restate the questions with clarifications: > >(a) for any responsder, there is a unique, correct reply to any query >(b) a correct signed reply will be accepted by a correctly functioning > requestor that receives the reply >(c) no incorrect signed reply can be undetectably subsituted for > the correct signed reply >(d) no unsigned reply can be undetectably substituted for the > correct signed reply >(e) no signed reply can be undetectably subsituted for the correct > unsigned reply > >For the time being, I'll assume a stable world, so that the keys and >chains of trust are stable. If they are changing, then the everything >is predicated on "assuming the requestor obtains data establishing >a chain of trust wrt to the base query". > >All answers should be qualified wrt > >NSEC/NSEC3/(NSEC and/or NSEC3)/opt-in/DLV/bogus message insertion/message >deletion/ > >of course. I'll take (a). The answer is no. For one, there is no reason that resolvers will have a common notion of the trusted root zone, hence a common set of trusted keys. Secondly, even if all resolvers believe in one root zone, it is possible that two caches each have different answers to a query. Case 2a, the "QTYPE=any" query. Case 2b, because of caching, it is possible that one cache has one version of an answer and another another. Both may validate under the rules of DNSSEC. For (b,c,d,e), if I may qualify the question to say "For a particular resolver with a trusted key set enabled", and I define "correct" as "succeeding in validation with the resolver's trusted key set," the answers are yes. DNSSEC is all about the resolver's perspective. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-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 Aug 27 00:03:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ruu-0001pB-U0 for dnsext-archive@megatron.ietf.org; Sat, 27 Aug 2005 00:03:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10985 for ; Sat, 27 Aug 2005 00:03:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8rq7-0003V8-Cg for namedroppers-data@psg.com; Sat, 27 Aug 2005 03:58:43 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8rq5-0003Uc-Dh for namedroppers@ops.ietf.org; Sat, 27 Aug 2005 03:58:41 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7R3wShR004763; Fri, 26 Aug 2005 23:58:30 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200508262059.j7QKxK1T012825@localhost.localdomain> References: <200508262059.j7QKxK1T012825@localhost.localdomain> Date: Fri, 26 Aug 2005 23:57:05 -0400 To: "Hilarie Orman" From: Edward Lewis Subject: Re: opt-in and wild card discussion Cc: Ed.Lewis@neustar.biz, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:59 -0600 8/26/05, Hilarie Orman wrote: >My questions really are smaller than your answers. Okay... >> (a) for any responder, there is a unique, correct reply to any query > >This isn't a question about whether or not a resolver will accept >the response as authentic or consistent with local policy, it is >about describing the correct behavior of the server. As far as the server is concerned, RFC 3090 documents that. The RFC is pre-DS RR and uses the old RR types. But if you pull out the parts that refer to the RR types, the concepts still hold, I think. But, DNSSEC is still in the eye of the resolver. The server-side can only hope to configure itself "correctly." That's what RFC 3090 means by globally and locally secured. >For the other questions, "accept" only means that a chain of trust can >be established. Maybe "validate" comes closer. A resolver that >accepts and uses provably bogus answers isn't the kind of resolver >that I'm asking about --- it doesn't "validate" wrt to a model. As >far as I know there are only two models under consideration for the >resolver: from-trusted-root, and from-trusted-nonroot. Yes - "a" chain of trust can be established. But be careful, an answer might arrive with a RRSIG is immaterial. Such an answer is to be considered unsigned. Immaterial means that the resolver doesn't have a trusted key that would lead to the RRSIG. >Caching is irrelevant here, because if there is no question, then one >can hardly complain that the answer is wrong. I figured that if you want a true model of DNS(SEC), you need to be aware of caching. Caching has proven to be tricky. >I'm looking for minimal set of formal rules that will assist a >mechanistic answer to the questions. If the rules exist, then it >should be possible to answer many questions about both the security of >DNSSEC wrt to attacks and its perceived complexity. Perhaps these >rules exist in the compendium of all RFC's pertaining to DNS - but >how about something smaller than my head? It would be interesting to see someone spend the time to do that... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From espinoza@yahoo.com Sat Aug 27 19:56:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9AWt-0003IC-Nj for dnsext-archive@megatron.ietf.org; Sat, 27 Aug 2005 19:56:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06811 for ; Sat, 27 Aug 2005 19:56:05 -0400 (EDT) Received: from 71-33-205-149.hlrn.qwest.net ([71.33.205.149] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E9AXt-0006YO-HB for dnsext-archive@ietf.org; Sat, 27 Aug 2005 19:57:11 -0400 Date: Sat, 27 Aug 2005 17:55:00 +0100 From: "Fink" To: Subject: Penis Growth Extreme Message-ID: <000801c5ab20$ac4dcc10$0700a8c0@wkuhddwi> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C5AB42.305894B0" 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.4 (++++) X-Scan-Signature: e06437eb72f6703f11713d345be8298a This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C5AB42.305894B0" ------=_NextPart_001_0005_01C5AB42.305894B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
 
Penis Enlargement = Pills=20 !!!
 
3D""=20
 
 
------=_NextPart_001_0005_01C5AB42.305894B0-- ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: image/jpeg; name="penis.jpg" Content-Transfer-Encoding: base64 Content-ID: <000301c5ab20$a94483b0$0700a8c0@sanya> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAqoAAAYbgAAQxf/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAOkBdgMBIgACEQEDEQH/ xADcAAACAwEBAQAAAAAAAAAAAAAABAEDBQIGBwEBAAMBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIC AQIGAgICAwEAAAABAgMEAAUREgYhExAgMDEUFUEyIhZCI0AzJDQRAAIBAgQEAwMGCQcLAgcAAAEC AwARITESBEFRIhNhcTKBkRQQodFCIzQgMLHBUjOT0wVicoKS0iSU8OGissJDU2Nzw+NAg/GzRGR0 FTUSAAIBAwEHAwMDAwUAAAAAAAABESExAkEQMFFhcYGRobES4SIy8MFSIGLSQNHxQnL/2gAMAwEA AhEDEQAAAPoAAABEwC7CNLTVFfJt21lv9ON0xOkExMSBBMATAERPInXcjEKr2cY6oXVt8/QxsZUd fHs098YbMkcIcvoU68dQwbLRtGOGwee0TQMTo2THDYAAAImAQfSyvUk0rwdPParXTnp9Zej1c9sR MWJ5ETAAHEulrKqzVTbUjNrYqpNK+itW69rfFLss43pZqoXWZWOXGu3Dy2htloyKd0MB3SDENsMg 1wmJgoMzJPUHlqT2lPn9OJ7qVjzOmllNCN93muezi0GfPxtTe4wqKX26MevPTThO3LVthCZrqU5r XRhCTkaYJTXbz9XnrOGOffZ9F57YvnaVWxFryL3Vl1MTtmAAAAAAAQAUWHZVaFF9MSsu/n8G8JP8 8e3Vs8+jz03dcWjNynqeXqy+bKLRZzRKOmqe4nT7yNeLWdrsd/nK1FuWyBQ3z9TWt5zYnPUuybZz b1PM2b19JPmuejL055HbNMiQAAA89m+yDxOn6MPHR7IPH7OvTE5im6jz6Ixo8+dqp21V1UuytTF3 aKO0hS2Yg6cvVnF3Sc01a5qm3X1arHNLN6Us8V3oo+k1S920mwrbdHXGztnB1u6rPak93Nffn8mr KVZomUGqJg4AAARMBTdTE8qtqY6V98XcOhEzMKZmx5/WfR8k9OaSW0nx7oovpV14ZqIm9HktDuU3 M1jLHrUmnWqWaYavyorLPGMYWmp6Xvjzr2n32c2FxtSZtO52eet0mBAvB8AAAiYCm6mJhJ3Oy07U za8buwp3J9Gnqs6LOVNo3Uqr4Ya7VHJ3Raq1rjXfHRRh2W3oafS9q2aFd+ct9Uzz0tTvz7XtYrO/ FZrnjoxOqOR2y3LJtruHTfCQAIzDUjywepoxtGJ6w9HH59q+Ipw2ur17a2w7HM6JruX6vS845vXV zWc7LRqxVuttTGZSmqWxlaWkXccWZS8wjflVyUuKVsoW6123G86r0+HePIRpT2HPkXjd5wKT1XXi mj1R5QPWJN+TPRJ5Cp6R3ynohooqrOcj2vy9FTiWhhu3dzXWuhX0Z0wEvQ52l0etOu1qGqe627sV VidnO1UorlP11aQxpZbGU6NyMVxfz6OLaXOZ+ltXTuy0vR4/R8+LtmPYizIU3hBIQSFeB6IPPc+j Dz9fpA83qvq1ny1d1PH1cPKP5au12RSt8dGNZ896Dz+jYuxlLTtq5N0X0ncW+aaObPETX3Fk3YvR 5mmhQtFZY6Xcsfczp9Dk0LMtbSm+eRemNuPHMHrzy1B7CfJeqLCAkAAAiYBVpKs+fXtT4+q3QyNP LTU57XjO9fO4i23i9qScYSui/a1sVutDMJ57o4HLEukOCoO9q6+2NrSZ28rcplobuzlJjePMxMen PJ3npTzbBuBIAGNVdYKsz2IdDBS3XVW2Uwiz5/bjbGFsJ0lb12cusTaPM9P4ldNDRznoFvTNCvV8 WrzVfWV8dURermWa21rZn0+Dk6LRzJJFN9kxlMaHExnRqgh06BMSABCbgeJc9UHkKfZ9Hlth+us+ Z73fN8nTmadGzE2Z+qlQ11lNxbPydnLu7do1Ki1y/bHLnTm8ZZp1QzKtSvn2xWmmKzEvno8iEvAg PyIZHprZjylXsiY856MkAAAAAImDzXHSJTqrrh6Xyvs4lOjTS59ereLYmih+kwYerw2UydamLGtV ra5KXMWdGCcOloRh7ms5/OjxS6Hb3QuNTtmnLQKjYKLalMxl9vdzGR29aXsU3EgAAESEc9hBIVc3 UxIvfXleu7i6sxPHe1K8vYMNcNp8peJk3wJmLCYmYiJKzBIQdRMEABMkEhF1N0xITaIJCJAAAAP/ 2gAIAQIAAQUA+MjBR7vrGey/N6ZY5Kohxo+Q3HCv/kPozD/rBPNZ/TOPkPwP3Y8D3zhbkhyMRuw+ gRyJRwyngrMOA6nHlQY05wTPgsHlJFbCvIlHAxSOX9MgP+H0Dl1MDesQRoxH1BUK3Zc9MPrn9TG/ ZZfUDnjocctzX5+icsf0YlcryMcc85MgK+mc8Z35z+EkZckbAQF9eZTy1IcH6Byb+jp2f14V+c4y dAmcHG5BQcgBhnLE+vZ7BBEkhyqSW+gcm9VAAwsBjqpAdsl6uoH+RC4rNnJxGILORnL4nbKwPX6B xzyzMeW54DYHIzsucLyU9VBJA4xgcYMc9tsCEZEhRPoN9vUKx9HcnOQhRuUJ4wN6c8YeVZP8sZDn tOcETDIYCzj6L/15/wATxwR6k9jCDyycnrwOGwKcA4x17DpiQs2RxhFH0X/ryOP+RHqIlxEKtIjZ w2dTnU51OdDkMBYqiqMH0X/q3Azjkj1IQdF9Q/OBWOEPhDnCSM5wDgc/AfRbJowMVMf0diwAbhWP ORqRnAxjxj+mIeWzn4D6JywB7a40RIH2+2RpiAAFRnUYyqcWJAfTPTPTB9E5Lx0Tj4Tezi+zz6cD j4HjBxnpz8R83//aAAgBAwABBQD4qOcC+jDhvmPPFbhWkdcWQcjOP8T9GP8Asv3sIeeeRnOc/Ek8 D7KOSYVwLxnUcsOD9AHgqTh4dGjIPDDEidsWEYYUxoBw8ZUdiGiPJ4Jx+efXJPv9AZEfRSQXLdi3 OBiV6tnBHw45ySPq8IIPHq7DnJft9AZH9wMYcYo4yJyCCDnUnPbw+hkjVjEvGcEsQCP5nH/X9Bcj /sT8APTnI5PTnkLxwx4JKnAFGHjqVXOgJsBQv0Bkf3/kKTiEhimICD90Xk4wXOBjKCCPUgZGoJsE dvoDAOAijjsudQcaMHArYC4HcgegznnAQAWzsCQVAkbs30B9x6sB6hF4wNi8NhUkmPkJwQ/phdCC 4JTgZNKOp+iv345bk4PQfwPXAOTxIMb3DgJGFvgCBjyhQzlifor9+Dz/AB/x68ZwAFdSAwGe4udl OcrnOSShcLEnD9FfupJH2Bzse3pyOMYgZyDgK4OMPAB+/HwP0RkUnONJgPoACeP8uPRs5weuLj/1 4zj4H6IyI8Mx9Q4wfcZI3o3OcnPXOzYXbj1z1z1w/RGJzy33yL3cf3ePk9cHPyH5v//aAAgBAQAB BQD539GJIw/5FJlEvx/jBn8+nw++emE4epEsZilmdJlnZlS1J7Ly29iM1dsWLsUk1N4bCzL3PWBm Wd2GVZAVxP6/+BNMUmfs0Pu9MlYda83dBnPx++cZ9sIOcc5wPhI3VWVpEIJWYcze1HYjk1O4levR XUDr2EEn4sishhcBgSWEAKvxkm7owWk8t1orDySmp/2bWmY+S6wZa8rr16trb1aklnyalGP9l1yt H5Jr5a3zfxa6rOHDliSsTd8pTmF0cOBx8P45Oc565ycJPwYhVkHONJxkwIaYtHO5hGe7C2WUKoJL pVXSYa6KWVfwrAFepLIv4c64tK2RNoK9m1Z8Pk9qbxmnMsPj9SCVfFaSRzeK0JcuaeG3M/jFCSV/ GaTmPx+pHB89xeUZeWlUJIGMEs8PfK9tkZJAw7Z98JOc+vxZ1IkYDG/o465YBVLyEpFKrosokm6/ l7GSxrap/F1+xTUmWpt1VciT/wCkDmSFu0a/14Hw4GcfDgZwM4GcD4zXK8EqXK8k9i5BWw3K4s91 ImT3FRi2WYHljnLca+TvHaqL2hsvCYrqPgfkO5GSW4YlfbQ423scNtbjn8y7ymwvQldpA+Axu1r/ ANcnHaeMxNUKe5WcQqzs7QWHgacI8DjtiIUmU8PUXqif0+nvtZYuzt43tBB/re1a2PFdv7dLxyzH amrbcySVNtE4i2hyzS2QHt7BGg/Zzo1PZODrdjwtbeLktfZ4te/2syXo4xdWFV2VMt+ZXZAqdkTi McxOtxbETHkn0yZBXsRqhsOrxyRwmNdcO+tpyvPSfstk9fyIm4sL/X6nAzgZwM4GEf5W05RiqBer rZpuhpVyFkRowOTinjLalJ71+WCRdfs5UbW3VI11rrJr7xHe7XWptbUSQ36thHgkUQSiVOcuMPe5 k/Y7ZoLVtKYVNVZWUUCIa/cGfgDJX6W0/r9LnFt12RXEiRTwzZ/OH+x9cUenHBkIWWJihDs78Mpm assd2wJZCLfssskrCtMc9uaM92jKX5kIs1py8cytTngtQxj25/Tm6e1kuEWmhJknEba610vVbxXE 2Xa3+1k5u7U95PJp43/2e0q1/IrySf7nP7Wr2U1x/l8slsRwPR8oVIdPvopdVU20N6vqd3BcTWeQ tHJrvJC0i70y9PIMcbxJ/b3hYDec8bzrR99EPpl6z7kkOuhjqOjK1qs0oZ4XUyRRiUQzk1JM/FlG RLZGV3MU2wnSGeSdy6N2Z68v4dWQMsqIkWqjfmElI6RLx+vO2cKatWq0H6rWe0+voyAarWBI4IYm +UqpzgZwM4GcDOBgAxgOfTLSd5owjIVQlR2aRDHN6ZRbm/wCdl7ccMdebtY18UmeqkhSTFWVZXr8 Kjsl9HrQxRS7OzflWOXXqtiW5tXmNWogm2CyrFWMYjH/AFRRRezEQSNpw9qttaESnf6gAb3WOIfI NZI03kWtjL7Sithd3q2jbfa9WHkOtM42dM1fnb+xHpOR+TDxiDAOiyIGUSiJqLql7k4yB1s1+8QZ g01aGwmwrLVrQ043SOusD219qC9zctO1avF+HLem21b8GpVrB2SqpFimjtHr6/P4Ncn9bDyddX4l qRPIvjwmtDwxBUk8bRxF4lHG0Xh4Sa343DZ2aeKotM+JA5N4y07LqQus+dvvk/rZjUM4/wASSeT6 5NB7qP7lO6rq6qScZQVMSWYplkglvTyT0oGlaHpKcsVIga9hqsiVrOys39iKYlnnmypECzqscWtr ixYhSKQL1VW68WHENeNPSOaKNYbtWZfyIDn7Oj+QuxpvZa5UVBLGxG2oG2bEAxNtQki+dvuMsP1c GKrBNuIVb9tK4XYzdxsZuu0lWazBJNElS7DYYehjm6mRy0U3/wCWOwIqxm6AwTyNXrsE2U1ikvty ZFRlZqtGaKaaO3YspSnhjjp2s/DsdvxbXN+OxzUpzyy2fH7H7Gh4zs2gTxm7HXreK7KKCPxa6lOD xyzDY8Z1Vmvi+H3w8fjGxD19D7VP52++TSr2msvdmkkgporW3VpbcYF6ucb8c5r5jHCvIngMU4Zw ctf4PIVStUitsFhWJhWuyTyDYV1lkvW5xWts8dbYiFzsjZhjvxqBuUdF3QwfvWLPu0SQ7d818W5L 7bebOjcbfbZa8/ke1hi/e7WnBHu9vBE222K6Fd9ed18i3Mqrttha3PA+g3PNiQrFsZO5LJVhgQQh 9pPO35+zjJ2taTHq1J4xcmrzVdrVV7c8diVZ7CmGSK9BfrtWhidAldVkePrFHuWeOhWjPFGj7yWJ izR1IoTWgV8rxsVTjkDk3JPckYAtrY+kIp1jY6Ic6rhRDhCDLFaCzFVpVakQCEdV57D5NztJddGv l1iQ2PK5w1XyKWS5JsaMbX5+SgDyp/32VD7CetSeSA0JSJaA5k1TII5Jacc1ulddqtYj8a0Atynr 6rSNPNUepxVl2rxtJs+uxa7ZqQSWDktu7HBFNaihhGxdmtXpD+Tss9/ZFpdhsI1Fi8MSa+zJb2qJ av7ZdlFf8olrz7XySMPs9+YqSbO+1ebcQbbbbjYw7Wnc31VTc8giWtHaGi54z9vrQh2uvBvHR7ZH seOkHXa98TXUEmZUBtysTI4Su/MOtqQAE7SeV4bkhfgnGrxMNlR9qV6lWWuulUqulZcr60qUqwoz QRFluyQ2+6iw8rwTND+NLMFZfd9ycOUhrxCMAAFnREkcu4PJowh5cX+vAySKKVAABwPg1Km1jgZw PhIqvHHX1oppQ11KhXqUDUTU652j3mqaEbnXEWtrr0F/YUi1t4fw7nJnnYpFXVa9Yp3Ak7Z2LLto jLWrKs9evQnFeazcgK7CIhbtSMPsYwqmaeS3CURmWxFNyKSTWA4FlDC9w41u3hu2VEt63Mxs2cWa 3zXt3IY/2N3NptdnBeXa+TjXW93ujDRlmmqfNIgdJPGpZKK+JwZX8V9lT4tE2DxVjXbxLvlmrW9q 3HETeAJiQybOSMvYsHqFA9pgO3YFgVYL2r3agBjd4gWo6+wW0NbqukroYatSorKLKzT1y1kcVooL BWCZERJIlE1ruSSxbEjJynVZfhxigdeFzheIp4ZiLddps5+XgfDgZwM4Hwsge1b4Mc4b8qivFyNO 1ydD269nI5yPgL7Y5uCYTibbV4Pw9hLjpsomj2W4RF22zbF2V58e1dbDZ2zBYtoZOm04I2ZzpslA GzGH9ripsyYae6Yezvs9vf57e/y7U3Ul9aPkXCU9sfH4dJu4o30m2hjr6zdizDqt8YZqG96Rhgn0 LA7RXFCl/W9E3XYVyVtSAM0ZLTz2IK6jY0wYrMMqWz/9FzkQ8AY47Y1ZGwwzJnuNyknGe4CFkHPu YJOc5JPtgmFGlaCkkZPwODFA6/DgZwM4GcDOAPpXZDFXtlrSi201us/W/DJxac8M1gVq5vQVGG4s rJHNFZyztKk8sl/XtXOwoYdhr8/M1pH5mv5exrmUya8FrtJMXYanBsdUMO11YwbigchuUJXj2eni T9vqeP2+qz9xqc/carP2+qy95NHUtS+Wt2l8kuES+WW2WTzBeZfKJPxqnkXvbT4z+R1YLcXldSaJ fJYC1fe1rFA+S+5bj8qqSlPJ6ckuzPWrUjPtBI0eqzSWZUb2JJTNDviWajqkQy0l4u1nqS2WCTwy SDXxuZE5IwRNwBIoSVlzupLJEc/GibGoVmEkVOHI27vWrpFD0XOqZ1TOqYUTOiZY1dC29fxrVwyH R6tpJPH9YTT8foV4m02taOPVa+O18V8fqtfTQa1FXSasldNSip0PGa9eSDRamu3+v6otf1kHt06U aS3wVqxqyQWh7qQ9mqbDq+1gIAmIJvRdgwaKKoAIqih6yIQwT0IHPX16chq6MJKIcNrCQ9SrBlNQ 4HHHHycn4KQBhZQeBnHw4+TgZtUlk1qR7nW1bMm+WnPY8hSOBdzFJVbdpNK98vsonp2Gk9xIomyf 20mZAkW0DpbiP+DkBZ5r7CxLOX1s1pW1s+xEQk2YPv7Uj3dpgk2+e7txhm2+PZ2uPPt2DLd7VX2Y Hvbs5727Oe9uznvbvDNu+fyN3nv7vNou9h2Rsb0Uem0E2os7d9n8/Azgc8DCwHwJAxvvPVr2Y54T Tnj1u6azrtf+OJwGi2UDTUad7hJbHaNyTllO0muZIa+pgYVwuKg6iNc4UYV5LxkYRkqtx7PrAhIH Gc8AAYAM45z1OcDFA65wPpb/AGG6rTWLW/Slsa28sRCTefny2d7csSWLTN+HJMZIEitJx2UAqwJy Nur26MlKRXVsmljrx92Z3eKvTrXdVBDHtNX2/carP2+p4/barP2+rx9rqiP2WsI/Y6zn9hrci2Ws D/t9Vn7jU5+41WDcaoZ+41OfuNTn7jU5L5HDHfXyr3K0/krxOPKngpL5UzWKNtLtT5t/Nu47sF3f TWK37mVUfyGUX9luq8a8lPTLnpZjB+HXLdKOzE1k1XngoyGzq1fAkdZ9TrHz2yFSNQQiHOqYUQ50 Tj2wMIQYU7ERdQkYA6Lx0TOinOq51XAq50XH1WvmspodUmHUUDZl8d1MyDTa1XrV4q0PzcYkccY4 GcDJa1eZm++WUU5GicKo4+EsUMyzaBOx0lpsraatAQnA6jAAM+2ff48Z1zrgAzjABh5Jz1zjOPgv 9fhwPrN98s/+sfYfb+M/4/y39R9jhwY2L8f4/nBn/JcTP+fx/lf6/R//2gAIAQICBj8A2y9ie4aX ElnAXET87pxpU+6vsPB7jrXZeRNDXOLdhNaqdzA8Xlio9xZLJCWTRcuilSqZ/kRYR0nZE8vJTjBH 8ZW6WfkoJReZH8XA8m9tRNeBMyHQ50frHsQlJl213Vk668xTjjXkJ5JYrOiElqSqQV8loeyvQWHM g5kcHHglSZKZot0v/SP7Vw6kfxt1EsqZYv0OpP8A1ZDhlGTJOvAirEp6jhkSzKeC3SXMlIqSrk3U SRUSZUcNckROLK/GtimWPU/PEn5YDbacvTdPgiPJPualChSo3wPqSfU0XQ08kL4ix5bquv7jf8si tdBpN2J4ENkWIVZ0GlxF1Kx5PqW9SWlCvun0J5r2MVy9yOI2ZJ2f/H7jyeS8lMse5fBdCPlj5L4+ Srx8kJ4ruUeJ8Vun0GuH+xi/7R9S1SicfWSPiz8ci2RZln4LMrKSIxUbt9BNai6wJPifJvsKuq8M mdEyjFsqvUuJcN7MxL/Uk8HInpNR4stjdELFOiHRFViUSJaTI+OO+fLZKUyQ/qcEfNzLJrs1NSUn vsptt++J5XNe523/AP/aAAgBAwIGPwDbTY1uFOo1izkMa3SHAsluI4UGtC3xGmMjcySkRBaGW8Ex Q+5wUaP8djfM6x77EV4HXdQ9Cg2VqJJVHqSyg09dRruYr9XOB3/Y7GL3XYuyg29CuooiujJmUVI5 N+DLLRIbg5C5w/IzDvuux12OOD9ChBKmmxqLr4kJW1NBtLoKgqKpjG6bK7J0GrNONjgoJQ5u2WyQ 2poiqypoWyJ+LoQtN0uLJfbmNTbgaMrRlV4HNBaIvIlxKnUhbG90nw/YS/jj7kRsqpPtaJhk5Uiz E+KqPWlC9EXJ1ITq90hrk/czfM9dj6FmuxOPyPuWTPxyj2PxZ+ORTF9y2RL3SJ/VzNcMmLmalHdR 3LlMkVa8lGi5dEJpslvdohj6SU0T9Sha+PqPlkyyLI4H5ehNyd7bSpHKCgmhVdhttr7i7Lsuy7Py e+6rZDJXlWKXPji7e/8ARdESt8tv2THOxWO3+g//2gAIAQEBBj8A/DNudXB4+Xvq179VKmFmBNz5 1zq9c/lx+TD5OXym/HOtKmx9SPbK3CmK9NhZ+V6OgkG1/dUJHV0dKcCxJxwrWHU/yQtLGyhS6usi jIi1KikuiZqAA4A5c6MsZXUR1EnhXTa1vWxsvs508chYl7PH0kKByBNAjljwB8CKZf0Tx5H5B5f+ hYD0qNR5nGixwYi9vLGr8DjSyIMEYg+RoN5C/sq3D8DlWP4POjiCTew8qZierh4URgAWsVHBgON6 ZG/RAUEcaVLhZ4iVXUekryNdMV8AdSsLY0Ztywk3ZuERSbC/MigzC7WzNWGMUmBBt03/ADGhMpUh R6ySbEUJFwZbXGdxyxoEDUc75+dqV81a6knDEfINkxYzAqrhVLKpf06iMr0s8xIBGpjGruijWY1J bSMyOVBJjaVmYBIwznSj9vUekcaeFTKzxu0fTGxDSJiyDDMCo2V2ZJFVjIFYookOldZ+rcjjTSGM ybgB2EKajZUft6mYqNOI5VFHLrMky6wiKzkLgCx0jAC+dTLFqeaNZGRWBRZDD+sVHIxtTI5YNGGE hClkDovcdA4FiQKm3SmTRAiyuCjBu2/pcC2K/iEcj1XU+VWHI/PSscRbSQOFTQi1yA3DGijggHEA 539talOBzFCrfJasav8AN8nL5L3sOJrW9wBfEZ0AMTwxNDSMZBnxDDKhn1iw8xV3sGBwIvf5qujM 2NsBf+sWoO7PGzN0qpGtscPUCKv35b8MUt/8qikm53EZGBBMXzER00R3swsbWtFYi+BxjNaz/EJl XE2+xGf/ALVApvtxoBKg2i/dUwO+nBjNx+qy5/qqBH8Q3GIvlD+6qLdzzTNJHpNiVsWT63p6b8dN hS7PZzlNsyqjs569Kyd7LTjicMvbSq8sulWd2UEEMXbWcCptYnAjGu6jSau++5xIPXKuhhllakiW WYRKEV0utpBG5kXV03zPC1WEs0bFXjd1K3dJH7pVrqR6uVRzmWWKSJdF4m0akuG0sfNeFO7vKQRL 20uNMZ3H6wrhfHxvUv2koSYuxjBFhJInaZx03vp9lSwK8mibbptXuRfQgKhhhnj+ILfosDSFRkdJ UcudFM1N2PhSO3VzvWtBgcVNaXBDG/lnVwcbXArCsavVqzrGr10m+PCscSR50QwxJyPjxpWxLE+V 6VsLqdXPIUzxnrU6gOYtQewvxB51a3St8sqKAXVLKmrDhixoiYDViBqvqOOYC5Uz7V9LKDdHy9t8 qO1dmUSjSt+YxwvWpyWbM48eRNTFGYxkKdF+kHjagFyZGBvypMeAFDy/GRQyyBZJyREp+tpFzUu3 SQGWEKZV/R1jp99J35AncZY1v9ZmNlAobXuDvlS+i+OkGxNDHPLEU6c70ptjYg+YoP8AWTEHnQuM GwJ5EGvh3JDLil+I5VrQaWAOHA+VBZL3GRtwoC46rZf56uMqAvYnEY0S7BRmbkC3hR7UbyAYFgtl /rHCiywqoGVyW+ZL1pEwWwN9Mf03oFZ8bEnBR+WruqyA5A9BPkaA3CNt2JsGtdT7aEkbhwPSym49 9G50kD33o+QHzUZEH2RN3C5qbZ+VNZrgnhW8nOLRDEW4tRdiSzYknHOlePAqcRj1A8xW138Q69u6 Fif0W4HyoW+sAy8qAJwIN87kqf8APS3bqvoYeBJpkJuVY28qHl+M2c8UMc6bcyF4ZTpDa10rwbjU kYaN2dIEcazdu2HDYsrDDULXBqGaYpNp+FPedyWiMAtIq3BvqOPCpow0aTPC8R3Ac65i0qy3fpvi otxrYvOqmDbvM7xO/cALqunSAir6he1qZo98iRkkqhhB0jlfXRX45LHruIB7R66Vfj0scQvw4w/0 6JO8VlY2NoBgf69KU3YwxDdkYEf0q1nfIGGBUwC/+vRvvktx/u6/26Onegty+HXl/PrSu6YWzU7c W/1zV9xvlQ8SYFuL+Tmhp3gdgMGaBffi1dybdhodQUuIAxUnn14UJG3Y3QawREQRkfyjiaVdZCvn IQQl/bRmEirFiq3N7kZ4VjbHFlGFgRhlRswdbegm3z5UHhbtsvqj4EZ5ZEUUZQko9QBwNj9Wjx+Q OqkrINIA4EGt3DcfbrGTf+V03oxuLOt1IPhRmkPWFOlOX840Ymw1wOx8SDcGtu69OqPFseHC1Qlb PqurE3uFONxqNBbXNy1/yUyHiAR+Sh5fj8vkJ4m9CS1yhv8A0TnV2wXAH20zWvE+DAc61INStjb6 auRcHPUBetIHSThfOi2iWMj69r/TQ6ifM86KtciwItfiKWPbKGdl6hYsxubWtX6iRQ2LEnSp/osR QLhADgbyIpIHtrSe265j7ROk+81jty4/SSxHuWnBaRNYCtcEGy+eNaZkE8ekhScDq8WpYnB7oHpA ICk8jQZfWvoY/WA4edBsm+sPH5IVPiffXSLGSAKB43q0I0lLpLLbBnBr7eYOCLBF+mkiYW7R0kfp IcBTRH/cuR89RgA6gGJJFsKv9bK/hULcGBX5qHl+MkkWVCkJKysGBCFfUG5WoOhDK2IINwR504ik WTtsUfSQdLDNTbiPlPnVuedPGVuUbTlw4GrLkw6l8qRTchibAciONH9HLxqRwRpXBRnkc6uz6SBl zppJHC2sNZwueFAkSXYALt0wkfxkf6i/PRMOna4dKRLdjbPVI2N6KyFpG43ZiRceNEaFtcjUcT5V 1IbY4cKs2qMm3pa3zVpEhZAPrdQ/qtRWWAK36cV1b3GhuNpKZFXhazLbmpo2Lm2LBrAhq/kyDL+U K8KjXDpU6j+j5Vut0ucUYAPJlFzb2mrv1Bhf89aBDNIBbFFBHztTMu13BW2KqgJxPi1Ssdju21uS bItuX6dGRNlugEXSFCKBjz66P9w3duWhf7dQH4LdAq4JvGMR/Xrf221of4fHG7B2IkYyrqVdIBtY 50kcm2RZ3dhdpAsYVU7pLHEqfA1Kdwkckb7xNvFob0Iya7+nGviBtV7ap3ZR3DqC95oOnpxyrcQ7 iJYpts4RtDFlOpQ4sSBwP4WxWAy/abuNHWFijuhDXW4Zc/OjoMzB4GiVRKNUcnd1ozanH1MLgmt7 2EkiM0m5kLCUBJBIpEVl1+rVxsKjbcibQEGt2lBj09tF0aOq7a744eZrdtt0kgebc7iVJe4OyUdC I7oGbHVY+moFJ3CL3Nv8QGnuxCh++wIkPSbjAe6oQ0k/ZVZFVUlAdX7t0LsWxBSw+t5Uwjk2wS/R qRy1vEhgL1+s2n9ST+1RJk2upyAxCSez61au5tNYFvRJz/nUTr2o080k+bqq/c2mPJJB/tU6bhoj Irf7oMBbx1Emg5vY2F6LKmso3bgQ8ZOLHyoxOdcsp+1c5sTxv4UEk1dF+23EkUdxEPtAPtEbAsfp rU11tcWvx41dXDNgbC/PjR6eViKJuAgyuaBUgm3DhV26SPRc9V6RtAUzsVYW6dS+HjUTlyAxwsLl T5caWSHuAZnXYBrcAuNPO4GB/wArCpobY9ks1stbkG3DhSgjEXx41ck6+I+mm3Dr+scBLYkhTj89 FQRizNc+dSOxu2ojVzA51YC1uI51GSb4Eiu4YkLbhFEzFReQAWGvnXY+Ei7WrX29C6dVrarWzqQS beNhLp7l1B1afTq52rtjaRBNOjToW2m+q2WV8ado0VGkN3IABYgWx/CxA+XL8A+fyMnEqDeg+RIz 8qOoYjjzvWm+C4k+IrWDeNz1jlfjWJuL3xxqEyEYCSTH9Ik0Bw4VdgdTN0ED0sT6sKb41iJPqDIM KaVIjHuQdRGYa9dsoY5FsSrYWv8Alrqy4nnXcEYGAC4/ParKrXyw6rgDlnTSIuhRmXzP81c6ggPV KArSMeDsdXzZUJcoISFux9TDlQ7vRGtlW3C/GgqW+Hj6mlyDMOV+FNBsm7cLm0kpHU5HLlRIcgcQ c6BEo0JfNswOQ50kkQARIlEYGeth/kaER1dwrbAYajnicKWMHC2LeNEWtY586CEagiYedQbV51Wc qo0Hmw6b8r1Ix3SaYhdzfIBtFxz6sKtHuFZjq0rkSVF9ONsajiadUnlCkRkgkFxqVdQwxqII5lMs 6beyZhpL6WOq3SbZ022adVmRlV14gsC6j2qDTyruFKR2DZ3Or02GZvwtnX61e0Yu93dQtYNotp9W eGVaBJePsifvjFLM3bC89Vxyo7wTKYFOkvyN9Om2d78PxB86tQHHSPy1JGbEKwCnlfGlBFzzqw/y xoh8jhhXbkYcLNzB/PSB8w8kItjjqJw99Z2AHvpkbFTgfpoLKcB6GGaWyamjnwkAurf8S3K9ESDU bWVgbEYcD4UkkUj9xSoOqxDK2HCtUiCR3xJLMtr30jSPKjp0xlum6Xvf201/049Oo9R6hXY+s73b mqjOjt0TBekE4WNvVzvQSMyvCGAeTuOfO2pqjjhMiLMSAO9LdVGYtqtjXSzhVGPW4/2qxMlz/wA2 T+1QRO5qayqO45z82qGMPNZOqT7aUYAWW3VzrUWmIBxAnlxY+n69E6pyBw+Im/t1qLThb/8AHm/e U7XlFzZT3pSbDzeoN6s7RhVjLKBaRtItYyAjUDx1XqbaLOBG40owiXWB3e71Pe7cuVEd+2rc/FX0 jinb01q+IJOvbP6R/wDSro5/WpJG3RftzxzglAGbtF2Adr4nrzqTfGYosqgTQqPW4VolfUcrK1NB 3Y7kIqMIVGEeHUfUWPMMPChq3bMyw9kMRc6hIJ1OJvYEZcuNdybddyTtRoS0Y0l45DLqKrYWN7W+ en2YaO7v3GPZXt3DB7drlhzv4/iD5n5M8NIFvbUpt9bG3O1W9t+XhRtY2yFW9pPjXJsweVEPmkvc 1NxVhifmq4y48atzxJFG9gQLqaEcoWVb25FT4HhRSGbVFGOoyjV1H6qleVTBghCFTeO/FhbBhSuh VegEkg545VjMbG46BjbzxoSF3Y6gFDMSS/IeRp2WPuSN+se5LYDAAUDP9jAMWPFv5K18FsAE0YM4 x0/yV5nxoCeVpNJw1G4F+VAAEAgleGI50rh8frLY3H9LKhM1wkZ6TnZuZ8qa4PXmcrKMqGkcgByF EZhsaZjYNz5k8KVfU/01HE7qJNIshOJ8hSsj2Ml9CtdWOm4PS2PCh9opx05/WHCjtxMvcVO6f0dG rTfVlmKfbLMpmjUSSLcdKHImhI0yBDfSxYWNs8aChlLMNQAOY50dkJlO4CdwpwC6tHqy9XCj9ouB 0+oerlUk6TqY4ZBDI9+kSEhQt/NvxB8/kd+IsLczQaYgMcW5k+FaVsLZXBY4cwLD56AHcGrL0gey w/PWnuOBkMQ3v1ChkQMbONJ961FLYq3aYOp5qRYfOaR0BeFhiOTU4RwHQgFL2IHlRY4ADO9Oyg6Z WJXlgaANwdTEnmWPGplHFL/1Tela2uZ+iGM5Eg5nwFBmOuUgKFHqc+XKu88rJLlHGoQqL8buGx8a 1jcyCQ5WWIi4PjHSLFu5PiJAda6YulD5JnX61754hfoqMmYhHGZVMP8ARoB9y6AcQI7X8CUtXw8O 4dtRsXKR6QL5nSldmDdygPewCxenmfs8zVvjpscMFhOWf+6qx301+HTD+6o/32cqMjph/dUkZ3sr D1NdYcLZZR0B8XIMcwsR/wC3T/xB2G5jPacFywkQwgg6UjsrFv8AIV/DpGKxNAweRSxDr9o7n0jH UrDOkRTtxLtp0lQgMO8seoXlbgTq5e+grPEX7aoVDNYkTPMRq03A0tnUsBeHuyQJGZcSdUTlwpNr lWXA1FudyIpIo33Esm2QFtIlVQixgqL+nwqXcbsMqhWg2Yk/WLDqZgX8eqnGuAKsIiRhe8jLMJg0 nThcCxxNGWX4aQybiaV4pNToqTaMRgt2XT4Vutoxj7M+6XcIVX6okSXQy/0bfiD5/I07AlVYiNP0 iPrUWuQt8LHE41aQG54LibHmaV4tuApGBY4keIvRLwqRjcjw9tWkQqbZg8PbUcgkDJqswtY9Qtem jjYhQx1I3Uo/OKklePUjqDrS5ZTfjxrTFuWe1tURa1/DHGgqdDR5R2GI8KKabK7Fl8zwqZmP+7YZ XzytWqOJdRWwlfGy/wAlDhjzNE3Mk7YGQ4nTfLkKHw/ZsQNIkDhgOJNqdv7r2tuOr9ZmOVPKxi1u xY+rAUDaHSRa/XagoO2suFmEmVRQ6tvoLaSvXbzorCu1RQbkjuanPJjRI+F7kvH7TCgqna2H/Uon +64nD9ZTOTtQoz/WV3H+G1Ocj3MqLx/CXA49zjSbSNolkG2Sbt6SxlkZ9BRLkHGp57oiLvvhNRTC GPVjK2OPKtuxKdWsahGbzaZNCsilgLFccGv4Wr+IPLJqnTdSBVkQgJGqao8L4BrYc6n3TOHbcy7f SrqQm3imQNq/m36fOo94xiM7yLG0yq3bVC+nuaW0nAeypty0vc+GTcIvZBKuI3jVZCtyL2Y0SjRD tbeSdmVCyuYpTHYdQwYVBFLKIUTdNH8KgIZoxGWWRsbkHytWX4g+Zo6cGayr5mu2h0qo0qRjhfE+ 2g+AkbBVtzp95vMZbXUNkq+XOrbaN5CMibqD7sfeRVn25TixDE/OdQpu/FdsASy8D7/y0zbV9JsT 2zYgjkMcKJAMkcyh2RRccmNWZXUk5LYnOhJGhUj1E4EmltIcM1bG3kaAmT1XAkH1T9NGEtrMzqIy L3KDqJYVaORQEATFs9Isauh1c3tZReiIAWOkkucLm1RRE2aSQ67cdOBrFbFr9X5q14hUvjbA2HiR Xw+1Us9xqOQFNI7B5T63GWfpj+mu64tpvpvhp8vGmmfFibDwHhVjibceVKw5cON6EIGC9TnjerkU WtYscB4UN4Yx8QE7Yk46L6tNeke6hgMMsKxUG+eFYgW435CjDMoZM7DAjkRbKjFt4wikktxLE5li cSTWQtblV7C/O1Z4ZfgbcwxrLJuJhCA7FQuoE3NgeVQiLaAlkMspZwqgCQxEBmsPq3xqWPs6EvuY 45Ee7h9sNeIZLYjzqPbSRqsblUEhe5ZmW/1V03/kmx40yvuYlYHFS6gg3440NDAqouCMQWYdPzUG J6V58hT7lzeOL9Wv1dQ5+FB2I7SEhAMjb6zUDHpVDhdr9Q5qBSjoawwaxU+zOiJY7KPrOoYH2ofy 13duSjHG/D30sjfrImZTbHUHxH5aQzKqMvqYAqx55Vfb7vQLZSDVl4rQvNDpJtqsxw8qaGOTuvID qduo+xRRnk1KFUKoNrotr9RbC5ooHclQSCuFmPM8aBOzeRT+rPdjF1prbJlJBIJmj9tLKdkyLt2L Oe4hwvj40LbXViCD3EGfGgI9kUc2BbvJY3oB9kRqxJ7qAyNyruybEm2AAmjAUUEXYHSPV9tHkK// AJ5sf+dHRY/w9sMLCaP56P8AcCHbBfto6+4G5zPeSgBsiScP10dBV/hjYCw+2jraxiOSLbPEpKon dBmZwGR2GACrxuPbW56pE3KRSSMhiGlHjk6UiOnq1JfnUkkurbxJBNuQxQW0sFEUZJHrQnEUzQvM +27yBNw0WmQoYtTYCI4auOipNv8AxCeZYG2yA2jWMM0mtWN2W4Iw9tJs9cz7ZX0LaIaO2FsNTMo8 9WvP6tCCKZkibcwwRoqBkdHF5NTFT1X8a2O2jjnWLQBIWjJXq13PoJuptmR5UivJO6yQwSyydkF4 2eTTKqBU4LwINbsuZ7nfLJHIUPe7ffjbuBNP6Nz6fZV74UZTu4u2raS2tbBiPTnnS33MfWvcUaxi gx155YGoBNuYpYop1ZAHUq0ljpQ53uDlW3LvtSEw2pOjDSdPR7RV220TXLNcoM5BZz/S40Nwm2jW ZcBIEAYWGnPypiVGFzlRfVa4LC3DgPmqRybG2kGludMkgsviXOn8lQx2shA1tl0LiffRj2UJZFPr bBbeFCLcRhdWAYYgk1Y5Xw91FiNDH6y4X9lXw0TLyv1JxtztSyq2mTJtJIAPG4N61RSauJ1AHA/z SDSsLMMrlSPyuKDdC3+sLC4+etWBci6mx025gc/Gg1lfEXJxzpdtubPA1tLWsyewV2XBVOpQcbHV bjU0EourE6lNtJHh50uOrayn7KTivHQ3lUaLibqL+3hSRH0RLqsARY+mtAv3GOo2+rfnVz1Na5I5 VbNrGw8L1qY2AzPOi5430jkKNqBNrJifP5B5fI0ciB0fBlYXBHiKsBYDIVl8i7loEO4X0ylRrHkf wHVjZWBBOVhatS/xGJjs5E7b9vABFZRrAOp8CTe9q3W12+9SaV9m23VWst3KyT6tV7Ws/u41HPN/ EY13Mb7bSFQlFeJCEUpe7agTiM6i2ifxOMSwa1kYJZjaQyuoYtwvk1+dGRd0pVSq343b09OZ1VEf iUIn/VWyOOnH21LGd1CsqggqZFBB5G5olNxCwsoazoeHnS9sj7Ug6lOrVW1g1agpVj/RwA99WIsW ULe+RfF/yUqgZjEZZ07DpI6qC3swAPzVa3IXppI11PAdYA+tb1L7RU22MYkTSJYif5XqsaB2kp0r h25MR5BqK7iDTfDUCbDxXMUAynhlw91AXci9+oHOrRR6icSWwH9WgFJaRzgeN+dKDcuV6rc7Y5UY pASVFklA4HnU6sBrjCvfhdDnUMi7czRqdWoMi43OHURwqSRtnJaQ9PXFgBn9fOhbYylBgT3Ir/69 WGwlUWII7kI/26u2xlxzYyQ3P+nQPwT6B6R3Iv7dWOyf9pF/brHYyEnICSL+3Vv/ANbMTmW1w5/t K/8A5k/9eH95WyjgR40kCdxGXUvW2hl1KGFwMcx7aMoeSSeSJpLGJegxzBOkaRmlzjUku3lIhE8g VhGQ7RqiFQhZCuZOefA1DLMCsjoGdSuggnmtzb3/AIbIcmBU+2vg33pZVYCENEulY1UoFYZtnzoK 8zGLsCFkAAJk7fZ7t8fqYWqAHcLq28sUoKRKmpYVKAMcyTfMmpQ8zFZtxLuHAFsJ0MbJnwvnRifc B3CxRxsYxpVIQQuBN72Y9QIPKtrq3jyfDAAiQa72fu3W56Tw44VKTDGWxN9IvfnVxGg1Ph0jLLOo EUabAAAcKcW1LEEJI8Tq/wBqo1wIZsAP5Nsa0nH/AONOMsLX86wOOnE0o4qMeWFE3wuKhIa6CaWA jLoILL7qCpiAxuBhTF9IFvS2furCNbjjGdJ+atCSSX5NZrfnoF5Wa/AWX6aOhQG4uTcj21bUA6j7 M+PjTRbmN0kBPXHgbj8tNCmr7ayKGwbTmb2rTqW1rKoF8PM00G8we3TKciPbxoBpcMTp51aMtp5n BfpNBmNzzOFqtQLHC9d2QWY+lTw+UXHKshhWVN2pFk7bFJNJB0sM1NsjR26yqZ1GoxBhrA56c/w8 vwpbmw0tjSi+TYYm4Fr1tgwub4+QFb1b4dC2vidI/wA1bdbWC6mN88/81DDE1GmS6rkeAo24m3sF NqyuRRCWC4+WAq8LIGG4ZgZASMuAUippVk23SRcaJPrG2HXRleTbtKLklkkPuOuh+pU8GRZBl5PW gS7d7cHV7589dfaGJR4RSN+SSivf2484Jbf69XE8DYWusEow/r0oHwzKvF43/PIb00pk2xc3uSj4 eA66/WbawH/Dk/t11SbVvONz/wBysDtFvyjcf7dfrdthyjk/t1bube+WMcl8P6dYvtrnnHJ/boO0 m1XkDHIf+5X6/a/spP3lfeNr+yf95X3ja/spP3lbWWJy0LoibjQxjjjMbiQsEJudY6a3moSjUyFY 0lFmKs19JZr202JHTfwobc6l3hYMwWU6ygfUVDljYlcPV7akKRzxxvuJ5O0kqiRhIEEbM+u2Fjz8 q3B2yyK8u4hkmIkBeWIKO4EYkC+ryoFnmWOPaOsDSzarbku2jWFwJ0nkahRzuQWlg+K1TCxVb90p pa4B88eVRxxCZ1RpVQCbBV7l01HWrenjqNv0aXWeoAavP8TKOYYWpo9QL3DFbcDW3Bxwxw8K3SjA Bxb2oahDYFo7HG+N2rHhTkYCMBffjQkdwqk4jM+wV1B7EkltB02NHssGAJGGdFbEkTYj+cL0iD68 gv4gVhwoXyxtR0nSeAq6gNhmMaF7heI4VqJwt51n51nax5UBmPHCrry86GGPjXXhzwrRCNXiBh7T QMnW4HsFYfgDy+XL5Mvky/FSyL6gDbzJsKE2z6dxHcKrf7wKcahYLodCFMZzBGZtU4Nr9LEt4Jb8 9bU8G1RkjwNEnAZ+6gxsZ52IRTb1tkPYKBLHdbh82K3byUcBRkl2rGIDpVbECmm2P2Uy2uhw1eyl dpUQgKZF1D1rhekb4mMujrpOsZccL196i/rrX3mL+stfeYr/AM8VhuogP563rHcQt/TW/wCWujdx AjgWBHz0Q0sTcSUcUD8Qqk5gmvvKe8VfvqTyBFdEqDldgKUSbqFb59YsBQjTd7cKBYASKK++wftF +mvv0H7Ra++wftF+mvvsH7Rfpr77B+0X6ai2u3gfeFoxMzRdQ7ZbR06Q1z7vOp4xtzGEbcRxy6gx 17ddZumGBFbcwxBYjKkM0jm7MWj7pCoMvO9Qx7SESSK22G4eQ6bncDUAoW/DjW37G2MnxBiTqcLp eYsFU4H9A13OyYTLHI0TXDkNAdMgK4ezHGm/hzwNFiQjyMFZtI9QRrXU4+kn8A7aWKVVEo25msuj uMutVwbViPCmljgnIGjt9KkP3G7YsQ1hjwJFM4SQJEsvdh0apBJEyoVBViPrf56n34R0h2+rXfSS dIvhoZh89Jt44Xi0SBdyJAGOl43lXR22PBaRItvNJJI7xqi6M0XuE6tem2k86hRIpWE4QqxCqPtO A1MC2njpvan5E2OHOkBxGnAi+BBoyyMCVGo4WNlHOhK/qnfUT5mwFXB64iHjvgSc2ApJFyfThl51 tttGLTFtSyDNF5gVr9Ujep2xY3rmbZGk3m2ADK3UnHOkmH+9XqAyuwOHvqZWvpjfDibBqAJubXv5 jnWPqyOF6BDZ8q9VyMgaN0IFHVblaulgPnq7MDXrA8qtr1Mcsa1KtwL9ROZoLmSLsfE1kPdXpHur 0j3V6R7q9I91ZD3Uk24hV5EGkNzUHVpa3qF8bGtxK8ZmfcNIzFzcL3vWqDhh7aEpgGpQLAEgdI0g 2va9sL0kkcIjmjVRHIt8DGLRsRkxXheiki/ESGb4lpHtqM36XTYC1CNoFKKHCrjh3Td/fXxkcKif EhhwLYMwGQJ5/gTb7ckzPJIJY0a4SNlXQDpvpJ8a0LGxW6kBndrds6lC3bAA1I6x4yGQyEO2cpDP xwyHlU+0gUom4v3GN3YluJL3vU0u6Y7mSZg2OrSNKGK1mZicGOZpXhiIMRJUl3a2pe2fUf0cPCo2 MRIhChF1tosnpuuqxt41LMHn1X1ECeULnj0hrCpIWeYFWuFE0gGk8T1VPp4xta3DwFQzqbCNh4m5 yqGS5DLIM74BlYt7KhBPVdAOFKT9VABQ44CieeYphlxy50UJBaKYEY46WN636RnUGBNjfDjUfAFe nHMisur5qF1qwFvCvKrnjwrz5C1WDHHkbH311Sthj7qDMwNuOd61HAZqvI3ofJjWFW+VQSL2y+Sx OX4ndLCWEpifQY/XqthpraxbFJUcwwusax3WSdmHeEx04WXmRTzRyTdx93okXRcx7dWazRqq6jfD nWzKNuJC62YCIRsza7Atg4Xp4Nat/EYpF28h3ckIVC/clPpEmpSLW9NsDUMpabt/FLCYDGBGIO2C WsFBwbC9Mq7eMx3I1GW1x5aDSytclRa4yaLkeZWlDse2bDV/JYUdqw+0WTQBncg4VDttWlnuQpxL D0r+Wok/QZfmqCW/Q91vyNLc4286PHDjRJ2sY4D7f/x1M77dVIVS3236J/mVu5E2ykBFZwZbYFcx 9mb0EXaowB6SZrcP+ma+5R3/AOv/AOKrnZxf4g/uq+5w2/8AyD+6r7nFh/8Acf8Air7pF/iP/FX3 SLHD7x/4qw2SYWymP7qj/dFA/wCtz/8AbrW20TDCxnv/ANutQ2iANh1T2OP/ALdD+5w/4g/uq+5w /wCIP7qrfBw/4g/uqt8HB/iD+6r7nD/iD+6r7pB/iD+6r7lB/iD+6pt5tkk1PsisSJ9pGk2oFlGH 6OIvnRIlncd22owMrEab2vYvpvx0Z4ZVudxLHO8m4j2jRpIgcAK9pMlKgjP56dN13miOvUWTtotj hYFfdpY3H4m9sfkxw+THDzo12txGHTkeFPt9jIZQpw25tKw+j2024YGN2IbUNIA4U805726a2qQ9 Vh4U9+AuLc6YqblLSIV5jEigSbjC9XON6vkDUyggWREy4ltVbydmszt21UjOw0r7K1nHE29leBNL ccK8PGhgOVCyi3HCr8DXPxrSOPEViOOOBpdWZYfJjV6N/ZWPyj8ZOmxErB4ojttEXcGvX9piFNun nTzI0vdfdmNgUBMcAZrMirGTjhwNSyzGecybQIgVCg1iUX+zAwJWxx/zVDslnm+HWVlebtrqKCJX W50aba7iptvuIJjt1eN0vGRZknCmzKoFtGPHzp44NuQVw7kpCx+zSSx91X3cpkX/AIK9MeHl1N7T 7KsihEKjSFAH5KFxccaIAzrSRjR27cATGeBHI13IhfbucUGJU0CDcfnoySmyr44seQokreVzrf8A nH0J7Kh2rMoJYtIzWAuTxJoQru4QAP8AiLn76Grdwgf9Rf7VffIP2i/TX3yH9ov0198g8PtF+mvv kH7RfprHeQHykUfnr75CMP8AiL9NYbuHD/mL9Nfe4MePcX6aUneQADP7Rfpr77B+0X6a++QftF+m vvkGH/MX6a++QftF+mvvkP7Rfpr75B+0X6a++wftF+mo9mIyY5NIWcsFV9Qzj1YNbC9jUe6j2shj nmG32xLKBIWLLc8VxXlTqNqToc7fVrFviAnc0/zfGll3W3Jl+Gj3L6GGn7V+2AL++jt02rMzPLHC dYAdoMXv+jhjUW7jBVZlDBWzF/wx8D3tKrGdusa3jeQyWkEhtgNPMipm2MksxHxaya0+zQobQ9sk AE3qOJp9yY2mCvKYzGwAjJaxa506wMSBW2cpLHLK23j3LrHpbt6pVe7ab5BTQG4nlhWOGQxkDraU TFE7llyKcbClJzIFz4kfIjHJlIPmKBuR4VfnwoA486KXKMfS44Ghtt6lhkJB1KRWtCCrYmRW0m/l SFSVkRrqW6lt4g0XldZJcgoGkXvyzr4yb1G/bT6aJYXPCwHCuBwwrIe6sh7qyHurL5qtYY1ewq4F vOrnH2CsVF6uQPdVyB7qyHur0jDwo9I9wrIe4V6R7qXdPCDMLG+IBK+ksowJHChp26jTKJlAvhIp JBHIY5ZUd0YQZSdRxOktbTq0enVbjSJJBqWMaVGph0lteg2OIByHClkEA1o0jqccGmwkOfGk28K6 IoxZFxwHt/EEIoUEkkAWxOJNZfIryxK7R4ozAEqfCj5/IrHMXtQBztx/NQvwq/yFJVVxxB/NQbbN p42Yn5jV/ibNyxwFCWS80ox1ucL87UAAABwGFYVz/A8q/P8AJ5/JblWFc6/N+CPL/wBCfP5PfSeV D5RTeVeyvZ+GflHyH8QPL8V//9k= ------=_NextPart_000_0004_01C5AB42.305894B0-- From SallySlater@aquatan.co.uk Sun Aug 28 13:14:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Qjd-0005TY-UI for dnsext-archive@megatron.ietf.org; Sun, 28 Aug 2005 13:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00432 for ; Sun, 28 Aug 2005 13:14:18 -0400 (EDT) Received: from pool-71-115-59-209.sbndin.dsl-w.verizon.net ([71.115.59.209]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E9Qkl-00014U-Iw for dnsext-archive@ietf.org; Sun, 28 Aug 2005 13:15:34 -0400 Received: from AwHo@localhost by iya.int (8.11.6/8.11.6); Sun, 28 Aug 2005 11:42:10 -0700 Message-ID: From: "Martha Grimm" Reply-To: "Martha Grimm" To: isis-update-web-archive@ietf.org, no.pares@ietf.org, dnsext-archive@ietf.org Subject: Symantec software for 80 % 0ff Date: Sun, 28 Aug 2005 13:43:10 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SallySlater@aquatan.co.uk Content-Type: multipart/mixed; boundary="--luqVUTVYyA3wOt6c8cWs" X-Spam-Score: 0.2 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 01q ----luqVUTVYyA3wOt6c8cWs Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 8
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: FnF782
 

Sales Ran= k: #1
System requirements  |  O= ther Versions
Date Coupon Expires: August 31st, 2005
Average Customer Revi= ew:3D"5 Based on 133388 reviews. = Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: mnyNT6
 

Sales Rank: #2
System requirements  = |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"= Based on 1956 r= eviews. Write a review.

<= /font>

<= b class=3Dsans>Microsoft Windows XP Professional or Longhorn Edition Microsoft

Choose:=
 

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availabi= lity: Available for INSTANT download!
Coupon Code: G8ONyx04= a
 

Sales Rank: #3<= span class=3Dsmall>
System requireme= nts  |  Other Versions=
Date Coupon Expires: August 31st, 20= 05
Average Customer Review:3D"5 B= ased on 1132 reviews. Write a review=

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: hdf2fieh
 =

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 13956= 7 reviews. Write a review.

= ----luqVUTVYyA3wOt6c8cWs-- From henry@anal-vibrator.co.uk Sun Aug 28 13:34:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9R2u-000126-HC for dnsext-archive@megatron.ietf.org; Sun, 28 Aug 2005 13:34:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01219 for ; Sun, 28 Aug 2005 13:34:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9R43-0001WC-NH for dnsext-archive@ietf.org; Sun, 28 Aug 2005 13:35:29 -0400 Received: from cpe-24-160-167-128.columbus.res.rr.com ([24.160.167.128] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1E9R2c-0007ac-NK for dnsext-archive@ietf.org; Sun, 28 Aug 2005 13:33:58 -0400 Date: Sun, 28 Aug 2005 12:33:50 +0100 From: "Handler" To: Subject: New Penis Enlargement Patches! Message-ID: <000801c5ab20$ac4dcc10$0700a8c0@wkuhddwi> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C5AB42.305894B0" 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.0 (++++) X-Scan-Signature: e06437eb72f6703f11713d345be8298a This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C5AB42.305894B0" ------=_NextPart_001_0005_01C5AB42.305894B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
 
Penis Enlargement = Pills=20 !!!
 
3D""=20
 
 
------=_NextPart_001_0005_01C5AB42.305894B0-- ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: image/jpeg; name="penis.jpg" Content-Transfer-Encoding: base64 Content-ID: <000301c5ab20$a94483b0$0700a8c0@sanya> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAqoAAAYbgAAQxf/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAOkBdgMBIgACEQEDEQH/ xADcAAACAwEBAQAAAAAAAAAAAAAABAEDBQIGBwEBAAMBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIC AQIGAgICAwEAAAABAgMEAAUREgYhExAgMDEUFUEyIhZCI0AzJDQRAAIBAgQEAwMGCQcLAgcAAAEC AwARITESBEFRIhNhcTKBkRQQodFCIzQgMLHBUjOT0wVicoKS0iSU8OGissJDU2Nzw+NAg/GzRGR0 FTUSAAIBAwEHAwMDAwUAAAAAAAABESExAkEQMFFhcYGRobES4SIy8MFSIGLSQNHxQnL/2gAMAwEA AhEDEQAAAPoAAABEwC7CNLTVFfJt21lv9ON0xOkExMSBBMATAERPInXcjEKr2cY6oXVt8/QxsZUd fHs098YbMkcIcvoU68dQwbLRtGOGwee0TQMTo2THDYAAAImAQfSyvUk0rwdPParXTnp9Zej1c9sR MWJ5ETAAHEulrKqzVTbUjNrYqpNK+itW69rfFLss43pZqoXWZWOXGu3Dy2htloyKd0MB3SDENsMg 1wmJgoMzJPUHlqT2lPn9OJ7qVjzOmllNCN93muezi0GfPxtTe4wqKX26MevPTThO3LVthCZrqU5r XRhCTkaYJTXbz9XnrOGOffZ9F57YvnaVWxFryL3Vl1MTtmAAAAAAAQAUWHZVaFF9MSsu/n8G8JP8 8e3Vs8+jz03dcWjNynqeXqy+bKLRZzRKOmqe4nT7yNeLWdrsd/nK1FuWyBQ3z9TWt5zYnPUuybZz b1PM2b19JPmuejL055HbNMiQAAA89m+yDxOn6MPHR7IPH7OvTE5im6jz6Ixo8+dqp21V1UuytTF3 aKO0hS2Yg6cvVnF3Sc01a5qm3X1arHNLN6Us8V3oo+k1S920mwrbdHXGztnB1u6rPak93Nffn8mr KVZomUGqJg4AAARMBTdTE8qtqY6V98XcOhEzMKZmx5/WfR8k9OaSW0nx7oovpV14ZqIm9HktDuU3 M1jLHrUmnWqWaYavyorLPGMYWmp6Xvjzr2n32c2FxtSZtO52eet0mBAvB8AAAiYCm6mJhJ3Oy07U za8buwp3J9Gnqs6LOVNo3Uqr4Ya7VHJ3Raq1rjXfHRRh2W3oafS9q2aFd+ct9Uzz0tTvz7XtYrO/ FZrnjoxOqOR2y3LJtruHTfCQAIzDUjywepoxtGJ6w9HH59q+Ipw2ur17a2w7HM6JruX6vS845vXV zWc7LRqxVuttTGZSmqWxlaWkXccWZS8wjflVyUuKVsoW6123G86r0+HePIRpT2HPkXjd5wKT1XXi mj1R5QPWJN+TPRJ5Cp6R3ynohooqrOcj2vy9FTiWhhu3dzXWuhX0Z0wEvQ52l0etOu1qGqe627sV VidnO1UorlP11aQxpZbGU6NyMVxfz6OLaXOZ+ltXTuy0vR4/R8+LtmPYizIU3hBIQSFeB6IPPc+j Dz9fpA83qvq1ny1d1PH1cPKP5au12RSt8dGNZ896Dz+jYuxlLTtq5N0X0ncW+aaObPETX3Fk3YvR 5mmhQtFZY6Xcsfczp9Dk0LMtbSm+eRemNuPHMHrzy1B7CfJeqLCAkAAAiYBVpKs+fXtT4+q3QyNP LTU57XjO9fO4i23i9qScYSui/a1sVutDMJ57o4HLEukOCoO9q6+2NrSZ28rcplobuzlJjePMxMen PJ3npTzbBuBIAGNVdYKsz2IdDBS3XVW2Uwiz5/bjbGFsJ0lb12cusTaPM9P4ldNDRznoFvTNCvV8 WrzVfWV8dURermWa21rZn0+Dk6LRzJJFN9kxlMaHExnRqgh06BMSABCbgeJc9UHkKfZ9Hlth+us+ Z73fN8nTmadGzE2Z+qlQ11lNxbPydnLu7do1Ki1y/bHLnTm8ZZp1QzKtSvn2xWmmKzEvno8iEvAg PyIZHprZjylXsiY856MkAAAAAImDzXHSJTqrrh6Xyvs4lOjTS59ereLYmih+kwYerw2UydamLGtV ra5KXMWdGCcOloRh7ms5/OjxS6Hb3QuNTtmnLQKjYKLalMxl9vdzGR29aXsU3EgAAESEc9hBIVc3 UxIvfXleu7i6sxPHe1K8vYMNcNp8peJk3wJmLCYmYiJKzBIQdRMEABMkEhF1N0xITaIJCJAAAAP/ 2gAIAQIAAQUA+MjBR7vrGey/N6ZY5Kohxo+Q3HCv/kPozD/rBPNZ/TOPkPwP3Y8D3zhbkhyMRuw+ gRyJRwyngrMOA6nHlQY05wTPgsHlJFbCvIlHAxSOX9MgP+H0Dl1MDesQRoxH1BUK3Zc9MPrn9TG/ ZZfUDnjocctzX5+icsf0YlcryMcc85MgK+mc8Z35z+EkZckbAQF9eZTy1IcH6Byb+jp2f14V+c4y dAmcHG5BQcgBhnLE+vZ7BBEkhyqSW+gcm9VAAwsBjqpAdsl6uoH+RC4rNnJxGILORnL4nbKwPX6B xzyzMeW54DYHIzsucLyU9VBJA4xgcYMc9tsCEZEhRPoN9vUKx9HcnOQhRuUJ4wN6c8YeVZP8sZDn tOcETDIYCzj6L/15/wATxwR6k9jCDyycnrwOGwKcA4x17DpiQs2RxhFH0X/ryOP+RHqIlxEKtIjZ w2dTnU51OdDkMBYqiqMH0X/q3Azjkj1IQdF9Q/OBWOEPhDnCSM5wDgc/AfRbJowMVMf0diwAbhWP ORqRnAxjxj+mIeWzn4D6JywB7a40RIH2+2RpiAAFRnUYyqcWJAfTPTPTB9E5Lx0Tj4Tezi+zz6cD j4HjBxnpz8R83//aAAgBAwABBQD4qOcC+jDhvmPPFbhWkdcWQcjOP8T9GP8Asv3sIeeeRnOc/Ek8 D7KOSYVwLxnUcsOD9AHgqTh4dGjIPDDEidsWEYYUxoBw8ZUdiGiPJ4Jx+efXJPv9AZEfRSQXLdi3 OBiV6tnBHw45ySPq8IIPHq7DnJft9AZH9wMYcYo4yJyCCDnUnPbw+hkjVjEvGcEsQCP5nH/X9Bcj /sT8APTnI5PTnkLxwx4JKnAFGHjqVXOgJsBQv0Bkf3/kKTiEhimICD90Xk4wXOBjKCCPUgZGoJsE dvoDAOAijjsudQcaMHArYC4HcgegznnAQAWzsCQVAkbs30B9x6sB6hF4wNi8NhUkmPkJwQ/phdCC 4JTgZNKOp+iv345bk4PQfwPXAOTxIMb3DgJGFvgCBjyhQzlifor9+Dz/AB/x68ZwAFdSAwGe4udl OcrnOSShcLEnD9FfupJH2Bzse3pyOMYgZyDgK4OMPAB+/HwP0RkUnONJgPoACeP8uPRs5weuLj/1 4zj4H6IyI8Mx9Q4wfcZI3o3OcnPXOzYXbj1z1z1w/RGJzy33yL3cf3ePk9cHPyH5v//aAAgBAQAB BQD539GJIw/5FJlEvx/jBn8+nw++emE4epEsZilmdJlnZlS1J7Ly29iM1dsWLsUk1N4bCzL3PWBm Wd2GVZAVxP6/+BNMUmfs0Pu9MlYda83dBnPx++cZ9sIOcc5wPhI3VWVpEIJWYcze1HYjk1O4levR XUDr2EEn4sishhcBgSWEAKvxkm7owWk8t1orDySmp/2bWmY+S6wZa8rr16trb1aklnyalGP9l1yt H5Jr5a3zfxa6rOHDliSsTd8pTmF0cOBx8P45Oc565ycJPwYhVkHONJxkwIaYtHO5hGe7C2WUKoJL pVXSYa6KWVfwrAFepLIv4c64tK2RNoK9m1Z8Pk9qbxmnMsPj9SCVfFaSRzeK0JcuaeG3M/jFCSV/ GaTmPx+pHB89xeUZeWlUJIGMEs8PfK9tkZJAw7Z98JOc+vxZ1IkYDG/o465YBVLyEpFKrosokm6/ l7GSxrap/F1+xTUmWpt1VciT/wCkDmSFu0a/14Hw4GcfDgZwM4GcD4zXK8EqXK8k9i5BWw3K4s91 ImT3FRi2WYHljnLca+TvHaqL2hsvCYrqPgfkO5GSW4YlfbQ423scNtbjn8y7ymwvQldpA+Axu1r/ ANcnHaeMxNUKe5WcQqzs7QWHgacI8DjtiIUmU8PUXqif0+nvtZYuzt43tBB/re1a2PFdv7dLxyzH amrbcySVNtE4i2hyzS2QHt7BGg/Zzo1PZODrdjwtbeLktfZ4te/2syXo4xdWFV2VMt+ZXZAqdkTi McxOtxbETHkn0yZBXsRqhsOrxyRwmNdcO+tpyvPSfstk9fyIm4sL/X6nAzgZwM4GEf5W05RiqBer rZpuhpVyFkRowOTinjLalJ71+WCRdfs5UbW3VI11rrJr7xHe7XWptbUSQ36thHgkUQSiVOcuMPe5 k/Y7ZoLVtKYVNVZWUUCIa/cGfgDJX6W0/r9LnFt12RXEiRTwzZ/OH+x9cUenHBkIWWJihDs78Mpm assd2wJZCLfssskrCtMc9uaM92jKX5kIs1py8cytTngtQxj25/Tm6e1kuEWmhJknEba610vVbxXE 2Xa3+1k5u7U95PJp43/2e0q1/IrySf7nP7Wr2U1x/l8slsRwPR8oVIdPvopdVU20N6vqd3BcTWeQ tHJrvJC0i70y9PIMcbxJ/b3hYDec8bzrR99EPpl6z7kkOuhjqOjK1qs0oZ4XUyRRiUQzk1JM/FlG RLZGV3MU2wnSGeSdy6N2Z68v4dWQMsqIkWqjfmElI6RLx+vO2cKatWq0H6rWe0+voyAarWBI4IYm +UqpzgZwM4GcDOBgAxgOfTLSd5owjIVQlR2aRDHN6ZRbm/wCdl7ccMdebtY18UmeqkhSTFWVZXr8 Kjsl9HrQxRS7OzflWOXXqtiW5tXmNWogm2CyrFWMYjH/AFRRRezEQSNpw9qttaESnf6gAb3WOIfI NZI03kWtjL7Sithd3q2jbfa9WHkOtM42dM1fnb+xHpOR+TDxiDAOiyIGUSiJqLql7k4yB1s1+8QZ g01aGwmwrLVrQ043SOusD219qC9zctO1avF+HLem21b8GpVrB2SqpFimjtHr6/P4Ncn9bDyddX4l qRPIvjwmtDwxBUk8bRxF4lHG0Xh4Sa343DZ2aeKotM+JA5N4y07LqQus+dvvk/rZjUM4/wASSeT6 5NB7qP7lO6rq6qScZQVMSWYplkglvTyT0oGlaHpKcsVIga9hqsiVrOys39iKYlnnmypECzqscWtr ixYhSKQL1VW68WHENeNPSOaKNYbtWZfyIDn7Oj+QuxpvZa5UVBLGxG2oG2bEAxNtQki+dvuMsP1c GKrBNuIVb9tK4XYzdxsZuu0lWazBJNElS7DYYehjm6mRy0U3/wCWOwIqxm6AwTyNXrsE2U1ikvty ZFRlZqtGaKaaO3YspSnhjjp2s/DsdvxbXN+OxzUpzyy2fH7H7Gh4zs2gTxm7HXreK7KKCPxa6lOD xyzDY8Z1Vmvi+H3w8fjGxD19D7VP52++TSr2msvdmkkgporW3VpbcYF6ucb8c5r5jHCvIngMU4Zw ctf4PIVStUitsFhWJhWuyTyDYV1lkvW5xWts8dbYiFzsjZhjvxqBuUdF3QwfvWLPu0SQ7d818W5L 7bebOjcbfbZa8/ke1hi/e7WnBHu9vBE222K6Fd9ed18i3Mqrttha3PA+g3PNiQrFsZO5LJVhgQQh 9pPO35+zjJ2taTHq1J4xcmrzVdrVV7c8diVZ7CmGSK9BfrtWhidAldVkePrFHuWeOhWjPFGj7yWJ izR1IoTWgV8rxsVTjkDk3JPckYAtrY+kIp1jY6Ic6rhRDhCDLFaCzFVpVakQCEdV57D5NztJddGv l1iQ2PK5w1XyKWS5JsaMbX5+SgDyp/32VD7CetSeSA0JSJaA5k1TII5Jacc1ulddqtYj8a0Atynr 6rSNPNUepxVl2rxtJs+uxa7ZqQSWDktu7HBFNaihhGxdmtXpD+Tss9/ZFpdhsI1Fi8MSa+zJb2qJ av7ZdlFf8olrz7XySMPs9+YqSbO+1ebcQbbbbjYw7Wnc31VTc8giWtHaGi54z9vrQh2uvBvHR7ZH seOkHXa98TXUEmZUBtysTI4Su/MOtqQAE7SeV4bkhfgnGrxMNlR9qV6lWWuulUqulZcr60qUqwoz QRFluyQ2+6iw8rwTND+NLMFZfd9ycOUhrxCMAAFnREkcu4PJowh5cX+vAySKKVAABwPg1Km1jgZw PhIqvHHX1oppQ11KhXqUDUTU652j3mqaEbnXEWtrr0F/YUi1t4fw7nJnnYpFXVa9Yp3Ak7Z2LLto jLWrKs9evQnFeazcgK7CIhbtSMPsYwqmaeS3CURmWxFNyKSTWA4FlDC9w41u3hu2VEt63Mxs2cWa 3zXt3IY/2N3NptdnBeXa+TjXW93ujDRlmmqfNIgdJPGpZKK+JwZX8V9lT4tE2DxVjXbxLvlmrW9q 3HETeAJiQybOSMvYsHqFA9pgO3YFgVYL2r3agBjd4gWo6+wW0NbqukroYatSorKLKzT1y1kcVooL BWCZERJIlE1ruSSxbEjJynVZfhxigdeFzheIp4ZiLddps5+XgfDgZwM4Hwsge1b4Mc4b8qivFyNO 1ydD269nI5yPgL7Y5uCYTibbV4Pw9hLjpsomj2W4RF22zbF2V58e1dbDZ2zBYtoZOm04I2ZzpslA GzGH9ripsyYae6Yezvs9vf57e/y7U3Ul9aPkXCU9sfH4dJu4o30m2hjr6zdizDqt8YZqG96Rhgn0 LA7RXFCl/W9E3XYVyVtSAM0ZLTz2IK6jY0wYrMMqWz/9FzkQ8AY47Y1ZGwwzJnuNyknGe4CFkHPu YJOc5JPtgmFGlaCkkZPwODFA6/DgZwM4GcDOAPpXZDFXtlrSi201us/W/DJxac8M1gVq5vQVGG4s rJHNFZyztKk8sl/XtXOwoYdhr8/M1pH5mv5exrmUya8FrtJMXYanBsdUMO11YwbigchuUJXj2eni T9vqeP2+qz9xqc/carP2+qy95NHUtS+Wt2l8kuES+WW2WTzBeZfKJPxqnkXvbT4z+R1YLcXldSaJ fJYC1fe1rFA+S+5bj8qqSlPJ6ckuzPWrUjPtBI0eqzSWZUb2JJTNDviWajqkQy0l4u1nqS2WCTwy SDXxuZE5IwRNwBIoSVlzupLJEc/GibGoVmEkVOHI27vWrpFD0XOqZ1TOqYUTOiZY1dC29fxrVwyH R6tpJPH9YTT8foV4m02taOPVa+O18V8fqtfTQa1FXSasldNSip0PGa9eSDRamu3+v6otf1kHt06U aS3wVqxqyQWh7qQ9mqbDq+1gIAmIJvRdgwaKKoAIqih6yIQwT0IHPX16chq6MJKIcNrCQ9SrBlNQ 4HHHHycn4KQBhZQeBnHw4+TgZtUlk1qR7nW1bMm+WnPY8hSOBdzFJVbdpNK98vsonp2Gk9xIomyf 20mZAkW0DpbiP+DkBZ5r7CxLOX1s1pW1s+xEQk2YPv7Uj3dpgk2+e7txhm2+PZ2uPPt2DLd7VX2Y Hvbs5727Oe9uznvbvDNu+fyN3nv7vNou9h2Rsb0Uem0E2os7d9n8/Azgc8DCwHwJAxvvPVr2Y54T Tnj1u6azrtf+OJwGi2UDTUad7hJbHaNyTllO0muZIa+pgYVwuKg6iNc4UYV5LxkYRkqtx7PrAhIH Gc8AAYAM45z1OcDFA65wPpb/AGG6rTWLW/Slsa28sRCTefny2d7csSWLTN+HJMZIEitJx2UAqwJy Nur26MlKRXVsmljrx92Z3eKvTrXdVBDHtNX2/carP2+p4/barP2+rx9rqiP2WsI/Y6zn9hrci2Ws D/t9Vn7jU5+41WDcaoZ+41OfuNTn7jU5L5HDHfXyr3K0/krxOPKngpL5UzWKNtLtT5t/Nu47sF3f TWK37mVUfyGUX9luq8a8lPTLnpZjB+HXLdKOzE1k1XngoyGzq1fAkdZ9TrHz2yFSNQQiHOqYUQ50 Tj2wMIQYU7ERdQkYA6Lx0TOinOq51XAq50XH1WvmspodUmHUUDZl8d1MyDTa1XrV4q0PzcYkccY4 GcDJa1eZm++WUU5GicKo4+EsUMyzaBOx0lpsraatAQnA6jAAM+2ff48Z1zrgAzjABh5Jz1zjOPgv 9fhwPrN98s/+sfYfb+M/4/y39R9jhwY2L8f4/nBn/JcTP+fx/lf6/R//2gAIAQICBj8A2y9ie4aX ElnAXET87pxpU+6vsPB7jrXZeRNDXOLdhNaqdzA8Xlio9xZLJCWTRcuilSqZ/kRYR0nZE8vJTjBH 8ZW6WfkoJReZH8XA8m9tRNeBMyHQ50frHsQlJl213Vk668xTjjXkJ5JYrOiElqSqQV8loeyvQWHM g5kcHHglSZKZot0v/SP7Vw6kfxt1EsqZYv0OpP8A1ZDhlGTJOvAirEp6jhkSzKeC3SXMlIqSrk3U SRUSZUcNckROLK/GtimWPU/PEn5YDbacvTdPgiPJPualChSo3wPqSfU0XQ08kL4ix5bquv7jf8si tdBpN2J4ENkWIVZ0GlxF1Kx5PqW9SWlCvun0J5r2MVy9yOI2ZJ2f/H7jyeS8lMse5fBdCPlj5L4+ Srx8kJ4ruUeJ8Vun0GuH+xi/7R9S1SicfWSPiz8ci2RZln4LMrKSIxUbt9BNai6wJPifJvsKuq8M mdEyjFsqvUuJcN7MxL/Uk8HInpNR4stjdELFOiHRFViUSJaTI+OO+fLZKUyQ/qcEfNzLJrs1NSUn vsptt++J5XNe523/AP/aAAgBAwIGPwDbTY1uFOo1izkMa3SHAsluI4UGtC3xGmMjcySkRBaGW8Ex Q+5wUaP8djfM6x77EV4HXdQ9Cg2VqJJVHqSyg09dRruYr9XOB3/Y7GL3XYuyg29CuooiujJmUVI5 N+DLLRIbg5C5w/IzDvuux12OOD9ChBKmmxqLr4kJW1NBtLoKgqKpjG6bK7J0GrNONjgoJQ5u2WyQ 2poiqypoWyJ+LoQtN0uLJfbmNTbgaMrRlV4HNBaIvIlxKnUhbG90nw/YS/jj7kRsqpPtaJhk5Uiz E+KqPWlC9EXJ1ITq90hrk/czfM9dj6FmuxOPyPuWTPxyj2PxZ+ORTF9y2RL3SJ/VzNcMmLmalHdR 3LlMkVa8lGi5dEJpslvdohj6SU0T9Sha+PqPlkyyLI4H5ehNyd7bSpHKCgmhVdhttr7i7Lsuy7Py e+6rZDJXlWKXPji7e/8ARdESt8tv2THOxWO3+g//2gAIAQEBBj8A/DNudXB4+Xvq179VKmFmBNz5 1zq9c/lx+TD5OXym/HOtKmx9SPbK3CmK9NhZ+V6OgkG1/dUJHV0dKcCxJxwrWHU/yQtLGyhS6usi jIi1KikuiZqAA4A5c6MsZXUR1EnhXTa1vWxsvs508chYl7PH0kKByBNAjljwB8CKZf0Tx5H5B5f+ hYD0qNR5nGixwYi9vLGr8DjSyIMEYg+RoN5C/sq3D8DlWP4POjiCTew8qZierh4URgAWsVHBgON6 ZG/RAUEcaVLhZ4iVXUekryNdMV8AdSsLY0Ztywk3ZuERSbC/MigzC7WzNWGMUmBBt03/ADGhMpUh R6ySbEUJFwZbXGdxyxoEDUc75+dqV81a6knDEfINkxYzAqrhVLKpf06iMr0s8xIBGpjGruijWY1J bSMyOVBJjaVmYBIwznSj9vUekcaeFTKzxu0fTGxDSJiyDDMCo2V2ZJFVjIFYookOldZ+rcjjTSGM ybgB2EKajZUft6mYqNOI5VFHLrMky6wiKzkLgCx0jAC+dTLFqeaNZGRWBRZDD+sVHIxtTI5YNGGE hClkDovcdA4FiQKm3SmTRAiyuCjBu2/pcC2K/iEcj1XU+VWHI/PSscRbSQOFTQi1yA3DGijggHEA 539talOBzFCrfJasav8AN8nL5L3sOJrW9wBfEZ0AMTwxNDSMZBnxDDKhn1iw8xV3sGBwIvf5qujM 2NsBf+sWoO7PGzN0qpGtscPUCKv35b8MUt/8qikm53EZGBBMXzER00R3swsbWtFYi+BxjNaz/EJl XE2+xGf/ALVApvtxoBKg2i/dUwO+nBjNx+qy5/qqBH8Q3GIvlD+6qLdzzTNJHpNiVsWT63p6b8dN hS7PZzlNsyqjs569Kyd7LTjicMvbSq8sulWd2UEEMXbWcCptYnAjGu6jSau++5xIPXKuhhllakiW WYRKEV0utpBG5kXV03zPC1WEs0bFXjd1K3dJH7pVrqR6uVRzmWWKSJdF4m0akuG0sfNeFO7vKQRL 20uNMZ3H6wrhfHxvUv2koSYuxjBFhJInaZx03vp9lSwK8mibbptXuRfQgKhhhnj+ILfosDSFRkdJ UcudFM1N2PhSO3VzvWtBgcVNaXBDG/lnVwcbXArCsavVqzrGr10m+PCscSR50QwxJyPjxpWxLE+V 6VsLqdXPIUzxnrU6gOYtQewvxB51a3St8sqKAXVLKmrDhixoiYDViBqvqOOYC5Uz7V9LKDdHy9t8 qO1dmUSjSt+YxwvWpyWbM48eRNTFGYxkKdF+kHjagFyZGBvypMeAFDy/GRQyyBZJyREp+tpFzUu3 SQGWEKZV/R1jp99J35AncZY1v9ZmNlAobXuDvlS+i+OkGxNDHPLEU6c70ptjYg+YoP8AWTEHnQuM GwJ5EGvh3JDLil+I5VrQaWAOHA+VBZL3GRtwoC46rZf56uMqAvYnEY0S7BRmbkC3hR7UbyAYFgtl /rHCiywqoGVyW+ZL1pEwWwN9Mf03oFZ8bEnBR+WruqyA5A9BPkaA3CNt2JsGtdT7aEkbhwPSym49 9G50kD33o+QHzUZEH2RN3C5qbZ+VNZrgnhW8nOLRDEW4tRdiSzYknHOlePAqcRj1A8xW138Q69u6 Fif0W4HyoW+sAy8qAJwIN87kqf8APS3bqvoYeBJpkJuVY28qHl+M2c8UMc6bcyF4ZTpDa10rwbjU kYaN2dIEcazdu2HDYsrDDULXBqGaYpNp+FPedyWiMAtIq3BvqOPCpow0aTPC8R3Ac65i0qy3fpvi otxrYvOqmDbvM7xO/cALqunSAir6he1qZo98iRkkqhhB0jlfXRX45LHruIB7R66Vfj0scQvw4w/0 6JO8VlY2NoBgf69KU3YwxDdkYEf0q1nfIGGBUwC/+vRvvktx/u6/26Onegty+HXl/PrSu6YWzU7c W/1zV9xvlQ8SYFuL+Tmhp3gdgMGaBffi1dybdhodQUuIAxUnn14UJG3Y3QawREQRkfyjiaVdZCvn IQQl/bRmEirFiq3N7kZ4VjbHFlGFgRhlRswdbegm3z5UHhbtsvqj4EZ5ZEUUZQko9QBwNj9Wjx+Q OqkrINIA4EGt3DcfbrGTf+V03oxuLOt1IPhRmkPWFOlOX840Ymw1wOx8SDcGtu69OqPFseHC1Qlb PqurE3uFONxqNBbXNy1/yUyHiAR+Sh5fj8vkJ4m9CS1yhv8A0TnV2wXAH20zWvE+DAc61INStjb6 auRcHPUBetIHSThfOi2iWMj69r/TQ6ifM86KtciwItfiKWPbKGdl6hYsxubWtX6iRQ2LEnSp/osR QLhADgbyIpIHtrSe265j7ROk+81jty4/SSxHuWnBaRNYCtcEGy+eNaZkE8ekhScDq8WpYnB7oHpA ICk8jQZfWvoY/WA4edBsm+sPH5IVPiffXSLGSAKB43q0I0lLpLLbBnBr7eYOCLBF+mkiYW7R0kfp IcBTRH/cuR89RgA6gGJJFsKv9bK/hULcGBX5qHl+MkkWVCkJKysGBCFfUG5WoOhDK2IINwR504ik WTtsUfSQdLDNTbiPlPnVuedPGVuUbTlw4GrLkw6l8qRTchibAciONH9HLxqRwRpXBRnkc6uz6SBl zppJHC2sNZwueFAkSXYALt0wkfxkf6i/PRMOna4dKRLdjbPVI2N6KyFpG43ZiRceNEaFtcjUcT5V 1IbY4cKs2qMm3pa3zVpEhZAPrdQ/qtRWWAK36cV1b3GhuNpKZFXhazLbmpo2Lm2LBrAhq/kyDL+U K8KjXDpU6j+j5Vut0ucUYAPJlFzb2mrv1Bhf89aBDNIBbFFBHztTMu13BW2KqgJxPi1Ssdju21uS bItuX6dGRNlugEXSFCKBjz66P9w3duWhf7dQH4LdAq4JvGMR/Xrf221of4fHG7B2IkYyrqVdIBtY 50kcm2RZ3dhdpAsYVU7pLHEqfA1Kdwkckb7xNvFob0Iya7+nGviBtV7ap3ZR3DqC95oOnpxyrcQ7 iJYpts4RtDFlOpQ4sSBwP4WxWAy/abuNHWFijuhDXW4Zc/OjoMzB4GiVRKNUcnd1ozanH1MLgmt7 2EkiM0m5kLCUBJBIpEVl1+rVxsKjbcibQEGt2lBj09tF0aOq7a744eZrdtt0kgebc7iVJe4OyUdC I7oGbHVY+moFJ3CL3Nv8QGnuxCh++wIkPSbjAe6oQ0k/ZVZFVUlAdX7t0LsWxBSw+t5Uwjk2wS/R qRy1vEhgL1+s2n9ST+1RJk2upyAxCSez61au5tNYFvRJz/nUTr2o080k+bqq/c2mPJJB/tU6bhoj Irf7oMBbx1Emg5vY2F6LKmso3bgQ8ZOLHyoxOdcsp+1c5sTxv4UEk1dF+23EkUdxEPtAPtEbAsfp rU11tcWvx41dXDNgbC/PjR6eViKJuAgyuaBUgm3DhV26SPRc9V6RtAUzsVYW6dS+HjUTlyAxwsLl T5caWSHuAZnXYBrcAuNPO4GB/wArCpobY9ks1stbkG3DhSgjEXx41ck6+I+mm3Dr+scBLYkhTj89 FQRizNc+dSOxu2ojVzA51YC1uI51GSb4Eiu4YkLbhFEzFReQAWGvnXY+Ei7WrX29C6dVrarWzqQS beNhLp7l1B1afTq52rtjaRBNOjToW2m+q2WV8ado0VGkN3IABYgWx/CxA+XL8A+fyMnEqDeg+RIz 8qOoYjjzvWm+C4k+IrWDeNz1jlfjWJuL3xxqEyEYCSTH9Ik0Bw4VdgdTN0ED0sT6sKb41iJPqDIM KaVIjHuQdRGYa9dsoY5FsSrYWv8Alrqy4nnXcEYGAC4/ParKrXyw6rgDlnTSIuhRmXzP81c6ggPV KArSMeDsdXzZUJcoISFux9TDlQ7vRGtlW3C/GgqW+Hj6mlyDMOV+FNBsm7cLm0kpHU5HLlRIcgcQ c6BEo0JfNswOQ50kkQARIlEYGeth/kaER1dwrbAYajnicKWMHC2LeNEWtY586CEagiYedQbV51Wc qo0Hmw6b8r1Ix3SaYhdzfIBtFxz6sKtHuFZjq0rkSVF9ONsajiadUnlCkRkgkFxqVdQwxqII5lMs 6beyZhpL6WOq3SbZ022adVmRlV14gsC6j2qDTyruFKR2DZ3Or02GZvwtnX61e0Yu93dQtYNotp9W eGVaBJePsifvjFLM3bC89Vxyo7wTKYFOkvyN9Om2d78PxB86tQHHSPy1JGbEKwCnlfGlBFzzqw/y xoh8jhhXbkYcLNzB/PSB8w8kItjjqJw99Z2AHvpkbFTgfpoLKcB6GGaWyamjnwkAurf8S3K9ESDU bWVgbEYcD4UkkUj9xSoOqxDK2HCtUiCR3xJLMtr30jSPKjp0xlum6Xvf201/049Oo9R6hXY+s73b mqjOjt0TBekE4WNvVzvQSMyvCGAeTuOfO2pqjjhMiLMSAO9LdVGYtqtjXSzhVGPW4/2qxMlz/wA2 T+1QRO5qayqO45z82qGMPNZOqT7aUYAWW3VzrUWmIBxAnlxY+n69E6pyBw+Im/t1qLThb/8AHm/e U7XlFzZT3pSbDzeoN6s7RhVjLKBaRtItYyAjUDx1XqbaLOBG40owiXWB3e71Pe7cuVEd+2rc/FX0 jinb01q+IJOvbP6R/wDSro5/WpJG3RftzxzglAGbtF2Adr4nrzqTfGYosqgTQqPW4VolfUcrK1NB 3Y7kIqMIVGEeHUfUWPMMPChq3bMyw9kMRc6hIJ1OJvYEZcuNdybddyTtRoS0Y0l45DLqKrYWN7W+ en2YaO7v3GPZXt3DB7drlhzv4/iD5n5M8NIFvbUpt9bG3O1W9t+XhRtY2yFW9pPjXJsweVEPmkvc 1NxVhifmq4y48atzxJFG9gQLqaEcoWVb25FT4HhRSGbVFGOoyjV1H6qleVTBghCFTeO/FhbBhSuh VegEkg545VjMbG46BjbzxoSF3Y6gFDMSS/IeRp2WPuSN+se5LYDAAUDP9jAMWPFv5K18FsAE0YM4 x0/yV5nxoCeVpNJw1G4F+VAAEAgleGI50rh8frLY3H9LKhM1wkZ6TnZuZ8qa4PXmcrKMqGkcgByF EZhsaZjYNz5k8KVfU/01HE7qJNIshOJ8hSsj2Ml9CtdWOm4PS2PCh9opx05/WHCjtxMvcVO6f0dG rTfVlmKfbLMpmjUSSLcdKHImhI0yBDfSxYWNs8aChlLMNQAOY50dkJlO4CdwpwC6tHqy9XCj9ouB 0+oerlUk6TqY4ZBDI9+kSEhQt/NvxB8/kd+IsLczQaYgMcW5k+FaVsLZXBY4cwLD56AHcGrL0gey w/PWnuOBkMQ3v1ChkQMbONJ961FLYq3aYOp5qRYfOaR0BeFhiOTU4RwHQgFL2IHlRY4ADO9Oyg6Z WJXlgaANwdTEnmWPGplHFL/1Tela2uZ+iGM5Eg5nwFBmOuUgKFHqc+XKu88rJLlHGoQqL8buGx8a 1jcyCQ5WWIi4PjHSLFu5PiJAda6YulD5JnX61754hfoqMmYhHGZVMP8ARoB9y6AcQI7X8CUtXw8O 4dtRsXKR6QL5nSldmDdygPewCxenmfs8zVvjpscMFhOWf+6qx301+HTD+6o/32cqMjph/dUkZ3sr D1NdYcLZZR0B8XIMcwsR/wC3T/xB2G5jPacFywkQwgg6UjsrFv8AIV/DpGKxNAweRSxDr9o7n0jH UrDOkRTtxLtp0lQgMO8seoXlbgTq5e+grPEX7aoVDNYkTPMRq03A0tnUsBeHuyQJGZcSdUTlwpNr lWXA1FudyIpIo33Esm2QFtIlVQixgqL+nwqXcbsMqhWg2Yk/WLDqZgX8eqnGuAKsIiRhe8jLMJg0 nThcCxxNGWX4aQybiaV4pNToqTaMRgt2XT4Vutoxj7M+6XcIVX6okSXQy/0bfiD5/I07AlVYiNP0 iPrUWuQt8LHE41aQG54LibHmaV4tuApGBY4keIvRLwqRjcjw9tWkQqbZg8PbUcgkDJqswtY9Qtem jjYhQx1I3Uo/OKklePUjqDrS5ZTfjxrTFuWe1tURa1/DHGgqdDR5R2GI8KKabK7Fl8zwqZmP+7YZ XzytWqOJdRWwlfGy/wAlDhjzNE3Mk7YGQ4nTfLkKHw/ZsQNIkDhgOJNqdv7r2tuOr9ZmOVPKxi1u xY+rAUDaHSRa/XagoO2suFmEmVRQ6tvoLaSvXbzorCu1RQbkjuanPJjRI+F7kvH7TCgqna2H/Uon +64nD9ZTOTtQoz/WV3H+G1Ocj3MqLx/CXA49zjSbSNolkG2Sbt6SxlkZ9BRLkHGp57oiLvvhNRTC GPVjK2OPKtuxKdWsahGbzaZNCsilgLFccGv4Wr+IPLJqnTdSBVkQgJGqao8L4BrYc6n3TOHbcy7f SrqQm3imQNq/m36fOo94xiM7yLG0yq3bVC+nuaW0nAeypty0vc+GTcIvZBKuI3jVZCtyL2Y0SjRD tbeSdmVCyuYpTHYdQwYVBFLKIUTdNH8KgIZoxGWWRsbkHytWX4g+Zo6cGayr5mu2h0qo0qRjhfE+ 2g+AkbBVtzp95vMZbXUNkq+XOrbaN5CMibqD7sfeRVn25TixDE/OdQpu/FdsASy8D7/y0zbV9JsT 2zYgjkMcKJAMkcyh2RRccmNWZXUk5LYnOhJGhUj1E4EmltIcM1bG3kaAmT1XAkH1T9NGEtrMzqIy L3KDqJYVaORQEATFs9Isauh1c3tZReiIAWOkkucLm1RRE2aSQ67cdOBrFbFr9X5q14hUvjbA2HiR Xw+1Us9xqOQFNI7B5T63GWfpj+mu64tpvpvhp8vGmmfFibDwHhVjibceVKw5cON6EIGC9TnjerkU WtYscB4UN4Yx8QE7Yk46L6tNeke6hgMMsKxUG+eFYgW435CjDMoZM7DAjkRbKjFt4wikktxLE5li cSTWQtblV7C/O1Z4ZfgbcwxrLJuJhCA7FQuoE3NgeVQiLaAlkMspZwqgCQxEBmsPq3xqWPs6EvuY 45Ee7h9sNeIZLYjzqPbSRqsblUEhe5ZmW/1V03/kmx40yvuYlYHFS6gg3440NDAqouCMQWYdPzUG J6V58hT7lzeOL9Wv1dQ5+FB2I7SEhAMjb6zUDHpVDhdr9Q5qBSjoawwaxU+zOiJY7KPrOoYH2ofy 13duSjHG/D30sjfrImZTbHUHxH5aQzKqMvqYAqx55Vfb7vQLZSDVl4rQvNDpJtqsxw8qaGOTuvID qduo+xRRnk1KFUKoNrotr9RbC5ooHclQSCuFmPM8aBOzeRT+rPdjF1prbJlJBIJmj9tLKdkyLt2L Oe4hwvj40LbXViCD3EGfGgI9kUc2BbvJY3oB9kRqxJ7qAyNyruybEm2AAmjAUUEXYHSPV9tHkK// AJ5sf+dHRY/w9sMLCaP56P8AcCHbBfto6+4G5zPeSgBsiScP10dBV/hjYCw+2jraxiOSLbPEpKon dBmZwGR2GACrxuPbW56pE3KRSSMhiGlHjk6UiOnq1JfnUkkurbxJBNuQxQW0sFEUZJHrQnEUzQvM +27yBNw0WmQoYtTYCI4auOipNv8AxCeZYG2yA2jWMM0mtWN2W4Iw9tJs9cz7ZX0LaIaO2FsNTMo8 9WvP6tCCKZkibcwwRoqBkdHF5NTFT1X8a2O2jjnWLQBIWjJXq13PoJuptmR5UivJO6yQwSyydkF4 2eTTKqBU4LwINbsuZ7nfLJHIUPe7ffjbuBNP6Nz6fZV74UZTu4u2raS2tbBiPTnnS33MfWvcUaxi gx155YGoBNuYpYop1ZAHUq0ljpQ53uDlW3LvtSEw2pOjDSdPR7RV220TXLNcoM5BZz/S40Nwm2jW ZcBIEAYWGnPypiVGFzlRfVa4LC3DgPmqRybG2kGludMkgsviXOn8lQx2shA1tl0LiffRj2UJZFPr bBbeFCLcRhdWAYYgk1Y5Xw91FiNDH6y4X9lXw0TLyv1JxtztSyq2mTJtJIAPG4N61RSauJ1AHA/z SDSsLMMrlSPyuKDdC3+sLC4+etWBci6mx025gc/Gg1lfEXJxzpdtubPA1tLWsyewV2XBVOpQcbHV bjU0EourE6lNtJHh50uOrayn7KTivHQ3lUaLibqL+3hSRH0RLqsARY+mtAv3GOo2+rfnVz1Na5I5 VbNrGw8L1qY2AzPOi5430jkKNqBNrJifP5B5fI0ciB0fBlYXBHiKsBYDIVl8i7loEO4X0ylRrHkf wHVjZWBBOVhatS/xGJjs5E7b9vABFZRrAOp8CTe9q3W12+9SaV9m23VWst3KyT6tV7Ws/u41HPN/ EY13Mb7bSFQlFeJCEUpe7agTiM6i2ifxOMSwa1kYJZjaQyuoYtwvk1+dGRd0pVSq343b09OZ1VEf iUIn/VWyOOnH21LGd1CsqggqZFBB5G5olNxCwsoazoeHnS9sj7Ug6lOrVW1g1agpVj/RwA99WIsW ULe+RfF/yUqgZjEZZ07DpI6qC3swAPzVa3IXppI11PAdYA+tb1L7RU22MYkTSJYif5XqsaB2kp0r h25MR5BqK7iDTfDUCbDxXMUAynhlw91AXci9+oHOrRR6icSWwH9WgFJaRzgeN+dKDcuV6rc7Y5UY pASVFklA4HnU6sBrjCvfhdDnUMi7czRqdWoMi43OHURwqSRtnJaQ9PXFgBn9fOhbYylBgT3Ir/69 WGwlUWII7kI/26u2xlxzYyQ3P+nQPwT6B6R3Iv7dWOyf9pF/brHYyEnICSL+3Vv/ANbMTmW1w5/t K/8A5k/9eH95WyjgR40kCdxGXUvW2hl1KGFwMcx7aMoeSSeSJpLGJegxzBOkaRmlzjUku3lIhE8g VhGQ7RqiFQhZCuZOefA1DLMCsjoGdSuggnmtzb3/AIbIcmBU+2vg33pZVYCENEulY1UoFYZtnzoK 8zGLsCFkAAJk7fZ7t8fqYWqAHcLq28sUoKRKmpYVKAMcyTfMmpQ8zFZtxLuHAFsJ0MbJnwvnRifc B3CxRxsYxpVIQQuBN72Y9QIPKtrq3jyfDAAiQa72fu3W56Tw44VKTDGWxN9IvfnVxGg1Ph0jLLOo EUabAAAcKcW1LEEJI8Tq/wBqo1wIZsAP5Nsa0nH/AONOMsLX86wOOnE0o4qMeWFE3wuKhIa6CaWA jLoILL7qCpiAxuBhTF9IFvS2furCNbjjGdJ+atCSSX5NZrfnoF5Wa/AWX6aOhQG4uTcj21bUA6j7 M+PjTRbmN0kBPXHgbj8tNCmr7ayKGwbTmb2rTqW1rKoF8PM00G8we3TKciPbxoBpcMTp51aMtp5n BfpNBmNzzOFqtQLHC9d2QWY+lTw+UXHKshhWVN2pFk7bFJNJB0sM1NsjR26yqZ1GoxBhrA56c/w8 vwpbmw0tjSi+TYYm4Fr1tgwub4+QFb1b4dC2vidI/wA1bdbWC6mN88/81DDE1GmS6rkeAo24m3sF NqyuRRCWC4+WAq8LIGG4ZgZASMuAUippVk23SRcaJPrG2HXRleTbtKLklkkPuOuh+pU8GRZBl5PW gS7d7cHV7589dfaGJR4RSN+SSivf2484Jbf69XE8DYWusEow/r0oHwzKvF43/PIb00pk2xc3uSj4 eA66/WbawH/Dk/t11SbVvONz/wBysDtFvyjcf7dfrdthyjk/t1bube+WMcl8P6dYvtrnnHJ/boO0 m1XkDHIf+5X6/a/spP3lfeNr+yf95X3ja/spP3lbWWJy0LoibjQxjjjMbiQsEJudY6a3moSjUyFY 0lFmKs19JZr202JHTfwobc6l3hYMwWU6ygfUVDljYlcPV7akKRzxxvuJ5O0kqiRhIEEbM+u2Fjz8 q3B2yyK8u4hkmIkBeWIKO4EYkC+ryoFnmWOPaOsDSzarbku2jWFwJ0nkahRzuQWlg+K1TCxVb90p pa4B88eVRxxCZ1RpVQCbBV7l01HWrenjqNv0aXWeoAavP8TKOYYWpo9QL3DFbcDW3Bxwxw8K3SjA Bxb2oahDYFo7HG+N2rHhTkYCMBffjQkdwqk4jM+wV1B7EkltB02NHssGAJGGdFbEkTYj+cL0iD68 gv4gVhwoXyxtR0nSeAq6gNhmMaF7heI4VqJwt51n51nax5UBmPHCrry86GGPjXXhzwrRCNXiBh7T QMnW4HsFYfgDy+XL5Mvky/FSyL6gDbzJsKE2z6dxHcKrf7wKcahYLodCFMZzBGZtU4Nr9LEt4Jb8 9bU8G1RkjwNEnAZ+6gxsZ52IRTb1tkPYKBLHdbh82K3byUcBRkl2rGIDpVbECmm2P2Uy2uhw1eyl dpUQgKZF1D1rhekb4mMujrpOsZccL196i/rrX3mL+stfeYr/AM8VhuogP563rHcQt/TW/wCWujdx AjgWBHz0Q0sTcSUcUD8Qqk5gmvvKe8VfvqTyBFdEqDldgKUSbqFb59YsBQjTd7cKBYASKK++wftF +mvv0H7Ra++wftF+mvvsH7Rfpr77B+0X6ai2u3gfeFoxMzRdQ7ZbR06Q1z7vOp4xtzGEbcRxy6gx 17ddZumGBFbcwxBYjKkM0jm7MWj7pCoMvO9Qx7SESSK22G4eQ6bncDUAoW/DjW37G2MnxBiTqcLp eYsFU4H9A13OyYTLHI0TXDkNAdMgK4ezHGm/hzwNFiQjyMFZtI9QRrXU4+kn8A7aWKVVEo25msuj uMutVwbViPCmljgnIGjt9KkP3G7YsQ1hjwJFM4SQJEsvdh0apBJEyoVBViPrf56n34R0h2+rXfSS dIvhoZh89Jt44Xi0SBdyJAGOl43lXR22PBaRItvNJJI7xqi6M0XuE6tem2k86hRIpWE4QqxCqPtO A1MC2njpvan5E2OHOkBxGnAi+BBoyyMCVGo4WNlHOhK/qnfUT5mwFXB64iHjvgSc2ApJFyfThl51 tttGLTFtSyDNF5gVr9Ujep2xY3rmbZGk3m2ADK3UnHOkmH+9XqAyuwOHvqZWvpjfDibBqAJubXv5 jnWPqyOF6BDZ8q9VyMgaN0IFHVblaulgPnq7MDXrA8qtr1Mcsa1KtwL9ROZoLmSLsfE1kPdXpHur 0j3V6R7q9I91ZD3Uk24hV5EGkNzUHVpa3qF8bGtxK8ZmfcNIzFzcL3vWqDhh7aEpgGpQLAEgdI0g 2va9sL0kkcIjmjVRHIt8DGLRsRkxXheiki/ESGb4lpHtqM36XTYC1CNoFKKHCrjh3Td/fXxkcKif EhhwLYMwGQJ5/gTb7ckzPJIJY0a4SNlXQDpvpJ8a0LGxW6kBndrds6lC3bAA1I6x4yGQyEO2cpDP xwyHlU+0gUom4v3GN3YluJL3vU0u6Y7mSZg2OrSNKGK1mZicGOZpXhiIMRJUl3a2pe2fUf0cPCo2 MRIhChF1tosnpuuqxt41LMHn1X1ECeULnj0hrCpIWeYFWuFE0gGk8T1VPp4xta3DwFQzqbCNh4m5 yqGS5DLIM74BlYt7KhBPVdAOFKT9VABQ44CieeYphlxy50UJBaKYEY46WN636RnUGBNjfDjUfAFe nHMisur5qF1qwFvCvKrnjwrz5C1WDHHkbH311Sthj7qDMwNuOd61HAZqvI3ofJjWFW+VQSL2y+Sx OX4ndLCWEpifQY/XqthpraxbFJUcwwusax3WSdmHeEx04WXmRTzRyTdx93okXRcx7dWazRqq6jfD nWzKNuJC62YCIRsza7Atg4Xp4Nat/EYpF28h3ckIVC/clPpEmpSLW9NsDUMpabt/FLCYDGBGIO2C WsFBwbC9Mq7eMx3I1GW1x5aDSytclRa4yaLkeZWlDse2bDV/JYUdqw+0WTQBncg4VDttWlnuQpxL D0r+Wok/QZfmqCW/Q91vyNLc4286PHDjRJ2sY4D7f/x1M77dVIVS3236J/mVu5E2ykBFZwZbYFcx 9mb0EXaowB6SZrcP+ma+5R3/AOv/AOKrnZxf4g/uq+5w2/8AyD+6r7nFh/8Acf8Air7pF/iP/FX3 SLHD7x/4qw2SYWymP7qj/dFA/wCtz/8AbrW20TDCxnv/ANutQ2iANh1T2OP/ALdD+5w/4g/uq+5w /wCIP7qrfBw/4g/uqt8HB/iD+6r7nD/iD+6r7pB/iD+6r7lB/iD+6pt5tkk1PsisSJ9pGk2oFlGH 6OIvnRIlncd22owMrEab2vYvpvx0Z4ZVudxLHO8m4j2jRpIgcAK9pMlKgjP56dN13miOvUWTtotj hYFfdpY3H4m9sfkxw+THDzo12txGHTkeFPt9jIZQpw25tKw+j2024YGN2IbUNIA4U805726a2qQ9 Vh4U9+AuLc6YqblLSIV5jEigSbjC9XON6vkDUyggWREy4ltVbydmszt21UjOw0r7K1nHE29leBNL ccK8PGhgOVCyi3HCr8DXPxrSOPEViOOOBpdWZYfJjV6N/ZWPyj8ZOmxErB4ojttEXcGvX9piFNun nTzI0vdfdmNgUBMcAZrMirGTjhwNSyzGecybQIgVCg1iUX+zAwJWxx/zVDslnm+HWVlebtrqKCJX W50aba7iptvuIJjt1eN0vGRZknCmzKoFtGPHzp44NuQVw7kpCx+zSSx91X3cpkX/AIK9MeHl1N7T 7KsihEKjSFAH5KFxccaIAzrSRjR27cATGeBHI13IhfbucUGJU0CDcfnoySmyr44seQokreVzrf8A nH0J7Kh2rMoJYtIzWAuTxJoQru4QAP8AiLn76Grdwgf9Rf7VffIP2i/TX3yH9ov0198g8PtF+mvv kH7RfprHeQHykUfnr75CMP8AiL9NYbuHD/mL9Nfe4MePcX6aUneQADP7Rfpr77B+0X6a++QftF+m vvkGH/MX6a++QftF+mvvkP7Rfpr75B+0X6a++wftF+mo9mIyY5NIWcsFV9Qzj1YNbC9jUe6j2shj nmG32xLKBIWLLc8VxXlTqNqToc7fVrFviAnc0/zfGll3W3Jl+Gj3L6GGn7V+2AL++jt02rMzPLHC dYAdoMXv+jhjUW7jBVZlDBWzF/wx8D3tKrGdusa3jeQyWkEhtgNPMipm2MksxHxaya0+zQobQ9sk AE3qOJp9yY2mCvKYzGwAjJaxa506wMSBW2cpLHLK23j3LrHpbt6pVe7ab5BTQG4nlhWOGQxkDraU TFE7llyKcbClJzIFz4kfIjHJlIPmKBuR4VfnwoA486KXKMfS44Ghtt6lhkJB1KRWtCCrYmRW0m/l SFSVkRrqW6lt4g0XldZJcgoGkXvyzr4yb1G/bT6aJYXPCwHCuBwwrIe6sh7qyHurL5qtYY1ewq4F vOrnH2CsVF6uQPdVyB7qyHur0jDwo9I9wrIe4V6R7qXdPCDMLG+IBK+ksowJHChp26jTKJlAvhIp JBHIY5ZUd0YQZSdRxOktbTq0enVbjSJJBqWMaVGph0lteg2OIByHClkEA1o0jqccGmwkOfGk28K6 IoxZFxwHt/EEIoUEkkAWxOJNZfIryxK7R4ozAEqfCj5/IrHMXtQBztx/NQvwq/yFJVVxxB/NQbbN p42Yn5jV/ibNyxwFCWS80ox1ucL87UAAABwGFYVz/A8q/P8AJ5/JblWFc6/N+CPL/wBCfP5PfSeV D5RTeVeyvZ+GflHyH8QPL8V//9k= ------=_NextPart_000_0004_01C5AB42.305894B0-- From philip@autarkic.com Sun Aug 28 13:34:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9R3P-0001CF-Rf for dnsext-archive@megatron.ietf.org; Sun, 28 Aug 2005 13:34:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01245 for ; Sun, 28 Aug 2005 13:34:46 -0400 (EDT) Received: from nc-71-0-26-252.dyn.sprint-hsd.net ([71.0.26.252] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E9R4a-0001Xs-5X for dnsext-archive@ietf.org; Sun, 28 Aug 2005 13:36:00 -0400 Date: Sun, 28 Aug 2005 13:30:20 +0100 From: "Halpern" To: Subject: New Penis Enlargement Patches! Message-ID: <000801c5ab20$ac4dcc10$0700a8c0@wkuhddwi> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C5AB42.305894B0" 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.0 (++++) X-Scan-Signature: e06437eb72f6703f11713d345be8298a This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C5AB42.305894B0" ------=_NextPart_001_0005_01C5AB42.305894B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
 
Penis Enlargement = Pills=20 !!!
 
3D""=20
 
 
------=_NextPart_001_0005_01C5AB42.305894B0-- ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: image/jpeg; name="penis.jpg" Content-Transfer-Encoding: base64 Content-ID: <000301c5ab20$a94483b0$0700a8c0@sanya> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAqoAAAYbgAAQxf/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAOkBdgMBIgACEQEDEQH/ xADcAAACAwEBAQAAAAAAAAAAAAAABAEDBQIGBwEBAAMBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIC AQIGAgICAwEAAAABAgMEAAUREgYhExAgMDEUFUEyIhZCI0AzJDQRAAIBAgQEAwMGCQcLAgcAAAEC AwARITESBEFRIhNhcTKBkRQQodFCIzQgMLHBUjOT0wVicoKS0iSU8OGissJDU2Nzw+NAg/GzRGR0 FTUSAAIBAwEHAwMDAwUAAAAAAAABESExAkEQMFFhcYGRobES4SIy8MFSIGLSQNHxQnL/2gAMAwEA AhEDEQAAAPoAAABEwC7CNLTVFfJt21lv9ON0xOkExMSBBMATAERPInXcjEKr2cY6oXVt8/QxsZUd fHs098YbMkcIcvoU68dQwbLRtGOGwee0TQMTo2THDYAAAImAQfSyvUk0rwdPParXTnp9Zej1c9sR MWJ5ETAAHEulrKqzVTbUjNrYqpNK+itW69rfFLss43pZqoXWZWOXGu3Dy2htloyKd0MB3SDENsMg 1wmJgoMzJPUHlqT2lPn9OJ7qVjzOmllNCN93muezi0GfPxtTe4wqKX26MevPTThO3LVthCZrqU5r XRhCTkaYJTXbz9XnrOGOffZ9F57YvnaVWxFryL3Vl1MTtmAAAAAAAQAUWHZVaFF9MSsu/n8G8JP8 8e3Vs8+jz03dcWjNynqeXqy+bKLRZzRKOmqe4nT7yNeLWdrsd/nK1FuWyBQ3z9TWt5zYnPUuybZz b1PM2b19JPmuejL055HbNMiQAAA89m+yDxOn6MPHR7IPH7OvTE5im6jz6Ixo8+dqp21V1UuytTF3 aKO0hS2Yg6cvVnF3Sc01a5qm3X1arHNLN6Us8V3oo+k1S920mwrbdHXGztnB1u6rPak93Nffn8mr KVZomUGqJg4AAARMBTdTE8qtqY6V98XcOhEzMKZmx5/WfR8k9OaSW0nx7oovpV14ZqIm9HktDuU3 M1jLHrUmnWqWaYavyorLPGMYWmp6Xvjzr2n32c2FxtSZtO52eet0mBAvB8AAAiYCm6mJhJ3Oy07U za8buwp3J9Gnqs6LOVNo3Uqr4Ya7VHJ3Raq1rjXfHRRh2W3oafS9q2aFd+ct9Uzz0tTvz7XtYrO/ FZrnjoxOqOR2y3LJtruHTfCQAIzDUjywepoxtGJ6w9HH59q+Ipw2ur17a2w7HM6JruX6vS845vXV zWc7LRqxVuttTGZSmqWxlaWkXccWZS8wjflVyUuKVsoW6123G86r0+HePIRpT2HPkXjd5wKT1XXi mj1R5QPWJN+TPRJ5Cp6R3ynohooqrOcj2vy9FTiWhhu3dzXWuhX0Z0wEvQ52l0etOu1qGqe627sV VidnO1UorlP11aQxpZbGU6NyMVxfz6OLaXOZ+ltXTuy0vR4/R8+LtmPYizIU3hBIQSFeB6IPPc+j Dz9fpA83qvq1ny1d1PH1cPKP5au12RSt8dGNZ896Dz+jYuxlLTtq5N0X0ncW+aaObPETX3Fk3YvR 5mmhQtFZY6Xcsfczp9Dk0LMtbSm+eRemNuPHMHrzy1B7CfJeqLCAkAAAiYBVpKs+fXtT4+q3QyNP LTU57XjO9fO4i23i9qScYSui/a1sVutDMJ57o4HLEukOCoO9q6+2NrSZ28rcplobuzlJjePMxMen PJ3npTzbBuBIAGNVdYKsz2IdDBS3XVW2Uwiz5/bjbGFsJ0lb12cusTaPM9P4ldNDRznoFvTNCvV8 WrzVfWV8dURermWa21rZn0+Dk6LRzJJFN9kxlMaHExnRqgh06BMSABCbgeJc9UHkKfZ9Hlth+us+ Z73fN8nTmadGzE2Z+qlQ11lNxbPydnLu7do1Ki1y/bHLnTm8ZZp1QzKtSvn2xWmmKzEvno8iEvAg PyIZHprZjylXsiY856MkAAAAAImDzXHSJTqrrh6Xyvs4lOjTS59ereLYmih+kwYerw2UydamLGtV ra5KXMWdGCcOloRh7ms5/OjxS6Hb3QuNTtmnLQKjYKLalMxl9vdzGR29aXsU3EgAAESEc9hBIVc3 UxIvfXleu7i6sxPHe1K8vYMNcNp8peJk3wJmLCYmYiJKzBIQdRMEABMkEhF1N0xITaIJCJAAAAP/ 2gAIAQIAAQUA+MjBR7vrGey/N6ZY5Kohxo+Q3HCv/kPozD/rBPNZ/TOPkPwP3Y8D3zhbkhyMRuw+ gRyJRwyngrMOA6nHlQY05wTPgsHlJFbCvIlHAxSOX9MgP+H0Dl1MDesQRoxH1BUK3Zc9MPrn9TG/ ZZfUDnjocctzX5+icsf0YlcryMcc85MgK+mc8Z35z+EkZckbAQF9eZTy1IcH6Byb+jp2f14V+c4y dAmcHG5BQcgBhnLE+vZ7BBEkhyqSW+gcm9VAAwsBjqpAdsl6uoH+RC4rNnJxGILORnL4nbKwPX6B xzyzMeW54DYHIzsucLyU9VBJA4xgcYMc9tsCEZEhRPoN9vUKx9HcnOQhRuUJ4wN6c8YeVZP8sZDn tOcETDIYCzj6L/15/wATxwR6k9jCDyycnrwOGwKcA4x17DpiQs2RxhFH0X/ryOP+RHqIlxEKtIjZ w2dTnU51OdDkMBYqiqMH0X/q3Azjkj1IQdF9Q/OBWOEPhDnCSM5wDgc/AfRbJowMVMf0diwAbhWP ORqRnAxjxj+mIeWzn4D6JywB7a40RIH2+2RpiAAFRnUYyqcWJAfTPTPTB9E5Lx0Tj4Tezi+zz6cD j4HjBxnpz8R83//aAAgBAwABBQD4qOcC+jDhvmPPFbhWkdcWQcjOP8T9GP8Asv3sIeeeRnOc/Ek8 D7KOSYVwLxnUcsOD9AHgqTh4dGjIPDDEidsWEYYUxoBw8ZUdiGiPJ4Jx+efXJPv9AZEfRSQXLdi3 OBiV6tnBHw45ySPq8IIPHq7DnJft9AZH9wMYcYo4yJyCCDnUnPbw+hkjVjEvGcEsQCP5nH/X9Bcj /sT8APTnI5PTnkLxwx4JKnAFGHjqVXOgJsBQv0Bkf3/kKTiEhimICD90Xk4wXOBjKCCPUgZGoJsE dvoDAOAijjsudQcaMHArYC4HcgegznnAQAWzsCQVAkbs30B9x6sB6hF4wNi8NhUkmPkJwQ/phdCC 4JTgZNKOp+iv345bk4PQfwPXAOTxIMb3DgJGFvgCBjyhQzlifor9+Dz/AB/x68ZwAFdSAwGe4udl OcrnOSShcLEnD9FfupJH2Bzse3pyOMYgZyDgK4OMPAB+/HwP0RkUnONJgPoACeP8uPRs5weuLj/1 4zj4H6IyI8Mx9Q4wfcZI3o3OcnPXOzYXbj1z1z1w/RGJzy33yL3cf3ePk9cHPyH5v//aAAgBAQAB BQD539GJIw/5FJlEvx/jBn8+nw++emE4epEsZilmdJlnZlS1J7Ly29iM1dsWLsUk1N4bCzL3PWBm Wd2GVZAVxP6/+BNMUmfs0Pu9MlYda83dBnPx++cZ9sIOcc5wPhI3VWVpEIJWYcze1HYjk1O4levR XUDr2EEn4sishhcBgSWEAKvxkm7owWk8t1orDySmp/2bWmY+S6wZa8rr16trb1aklnyalGP9l1yt H5Jr5a3zfxa6rOHDliSsTd8pTmF0cOBx8P45Oc565ycJPwYhVkHONJxkwIaYtHO5hGe7C2WUKoJL pVXSYa6KWVfwrAFepLIv4c64tK2RNoK9m1Z8Pk9qbxmnMsPj9SCVfFaSRzeK0JcuaeG3M/jFCSV/ GaTmPx+pHB89xeUZeWlUJIGMEs8PfK9tkZJAw7Z98JOc+vxZ1IkYDG/o465YBVLyEpFKrosokm6/ l7GSxrap/F1+xTUmWpt1VciT/wCkDmSFu0a/14Hw4GcfDgZwM4GcD4zXK8EqXK8k9i5BWw3K4s91 ImT3FRi2WYHljnLca+TvHaqL2hsvCYrqPgfkO5GSW4YlfbQ423scNtbjn8y7ymwvQldpA+Axu1r/ ANcnHaeMxNUKe5WcQqzs7QWHgacI8DjtiIUmU8PUXqif0+nvtZYuzt43tBB/re1a2PFdv7dLxyzH amrbcySVNtE4i2hyzS2QHt7BGg/Zzo1PZODrdjwtbeLktfZ4te/2syXo4xdWFV2VMt+ZXZAqdkTi McxOtxbETHkn0yZBXsRqhsOrxyRwmNdcO+tpyvPSfstk9fyIm4sL/X6nAzgZwM4GEf5W05RiqBer rZpuhpVyFkRowOTinjLalJ71+WCRdfs5UbW3VI11rrJr7xHe7XWptbUSQ36thHgkUQSiVOcuMPe5 k/Y7ZoLVtKYVNVZWUUCIa/cGfgDJX6W0/r9LnFt12RXEiRTwzZ/OH+x9cUenHBkIWWJihDs78Mpm assd2wJZCLfssskrCtMc9uaM92jKX5kIs1py8cytTngtQxj25/Tm6e1kuEWmhJknEba610vVbxXE 2Xa3+1k5u7U95PJp43/2e0q1/IrySf7nP7Wr2U1x/l8slsRwPR8oVIdPvopdVU20N6vqd3BcTWeQ tHJrvJC0i70y9PIMcbxJ/b3hYDec8bzrR99EPpl6z7kkOuhjqOjK1qs0oZ4XUyRRiUQzk1JM/FlG RLZGV3MU2wnSGeSdy6N2Z68v4dWQMsqIkWqjfmElI6RLx+vO2cKatWq0H6rWe0+voyAarWBI4IYm +UqpzgZwM4GcDOBgAxgOfTLSd5owjIVQlR2aRDHN6ZRbm/wCdl7ccMdebtY18UmeqkhSTFWVZXr8 Kjsl9HrQxRS7OzflWOXXqtiW5tXmNWogm2CyrFWMYjH/AFRRRezEQSNpw9qttaESnf6gAb3WOIfI NZI03kWtjL7Sithd3q2jbfa9WHkOtM42dM1fnb+xHpOR+TDxiDAOiyIGUSiJqLql7k4yB1s1+8QZ g01aGwmwrLVrQ043SOusD219qC9zctO1avF+HLem21b8GpVrB2SqpFimjtHr6/P4Ncn9bDyddX4l qRPIvjwmtDwxBUk8bRxF4lHG0Xh4Sa343DZ2aeKotM+JA5N4y07LqQus+dvvk/rZjUM4/wASSeT6 5NB7qP7lO6rq6qScZQVMSWYplkglvTyT0oGlaHpKcsVIga9hqsiVrOys39iKYlnnmypECzqscWtr ixYhSKQL1VW68WHENeNPSOaKNYbtWZfyIDn7Oj+QuxpvZa5UVBLGxG2oG2bEAxNtQki+dvuMsP1c GKrBNuIVb9tK4XYzdxsZuu0lWazBJNElS7DYYehjm6mRy0U3/wCWOwIqxm6AwTyNXrsE2U1ikvty ZFRlZqtGaKaaO3YspSnhjjp2s/DsdvxbXN+OxzUpzyy2fH7H7Gh4zs2gTxm7HXreK7KKCPxa6lOD xyzDY8Z1Vmvi+H3w8fjGxD19D7VP52++TSr2msvdmkkgporW3VpbcYF6ucb8c5r5jHCvIngMU4Zw ctf4PIVStUitsFhWJhWuyTyDYV1lkvW5xWts8dbYiFzsjZhjvxqBuUdF3QwfvWLPu0SQ7d818W5L 7bebOjcbfbZa8/ke1hi/e7WnBHu9vBE222K6Fd9ed18i3Mqrttha3PA+g3PNiQrFsZO5LJVhgQQh 9pPO35+zjJ2taTHq1J4xcmrzVdrVV7c8diVZ7CmGSK9BfrtWhidAldVkePrFHuWeOhWjPFGj7yWJ izR1IoTWgV8rxsVTjkDk3JPckYAtrY+kIp1jY6Ic6rhRDhCDLFaCzFVpVakQCEdV57D5NztJddGv l1iQ2PK5w1XyKWS5JsaMbX5+SgDyp/32VD7CetSeSA0JSJaA5k1TII5Jacc1ulddqtYj8a0Atynr 6rSNPNUepxVl2rxtJs+uxa7ZqQSWDktu7HBFNaihhGxdmtXpD+Tss9/ZFpdhsI1Fi8MSa+zJb2qJ av7ZdlFf8olrz7XySMPs9+YqSbO+1ebcQbbbbjYw7Wnc31VTc8giWtHaGi54z9vrQh2uvBvHR7ZH seOkHXa98TXUEmZUBtysTI4Su/MOtqQAE7SeV4bkhfgnGrxMNlR9qV6lWWuulUqulZcr60qUqwoz QRFluyQ2+6iw8rwTND+NLMFZfd9ycOUhrxCMAAFnREkcu4PJowh5cX+vAySKKVAABwPg1Km1jgZw PhIqvHHX1oppQ11KhXqUDUTU652j3mqaEbnXEWtrr0F/YUi1t4fw7nJnnYpFXVa9Yp3Ak7Z2LLto jLWrKs9evQnFeazcgK7CIhbtSMPsYwqmaeS3CURmWxFNyKSTWA4FlDC9w41u3hu2VEt63Mxs2cWa 3zXt3IY/2N3NptdnBeXa+TjXW93ujDRlmmqfNIgdJPGpZKK+JwZX8V9lT4tE2DxVjXbxLvlmrW9q 3HETeAJiQybOSMvYsHqFA9pgO3YFgVYL2r3agBjd4gWo6+wW0NbqukroYatSorKLKzT1y1kcVooL BWCZERJIlE1ruSSxbEjJynVZfhxigdeFzheIp4ZiLddps5+XgfDgZwM4Hwsge1b4Mc4b8qivFyNO 1ydD269nI5yPgL7Y5uCYTibbV4Pw9hLjpsomj2W4RF22zbF2V58e1dbDZ2zBYtoZOm04I2ZzpslA GzGH9ripsyYae6Yezvs9vf57e/y7U3Ul9aPkXCU9sfH4dJu4o30m2hjr6zdizDqt8YZqG96Rhgn0 LA7RXFCl/W9E3XYVyVtSAM0ZLTz2IK6jY0wYrMMqWz/9FzkQ8AY47Y1ZGwwzJnuNyknGe4CFkHPu YJOc5JPtgmFGlaCkkZPwODFA6/DgZwM4GcDOAPpXZDFXtlrSi201us/W/DJxac8M1gVq5vQVGG4s rJHNFZyztKk8sl/XtXOwoYdhr8/M1pH5mv5exrmUya8FrtJMXYanBsdUMO11YwbigchuUJXj2eni T9vqeP2+qz9xqc/carP2+qy95NHUtS+Wt2l8kuES+WW2WTzBeZfKJPxqnkXvbT4z+R1YLcXldSaJ fJYC1fe1rFA+S+5bj8qqSlPJ6ckuzPWrUjPtBI0eqzSWZUb2JJTNDviWajqkQy0l4u1nqS2WCTwy SDXxuZE5IwRNwBIoSVlzupLJEc/GibGoVmEkVOHI27vWrpFD0XOqZ1TOqYUTOiZY1dC29fxrVwyH R6tpJPH9YTT8foV4m02taOPVa+O18V8fqtfTQa1FXSasldNSip0PGa9eSDRamu3+v6otf1kHt06U aS3wVqxqyQWh7qQ9mqbDq+1gIAmIJvRdgwaKKoAIqih6yIQwT0IHPX16chq6MJKIcNrCQ9SrBlNQ 4HHHHycn4KQBhZQeBnHw4+TgZtUlk1qR7nW1bMm+WnPY8hSOBdzFJVbdpNK98vsonp2Gk9xIomyf 20mZAkW0DpbiP+DkBZ5r7CxLOX1s1pW1s+xEQk2YPv7Uj3dpgk2+e7txhm2+PZ2uPPt2DLd7VX2Y Hvbs5727Oe9uznvbvDNu+fyN3nv7vNou9h2Rsb0Uem0E2os7d9n8/Azgc8DCwHwJAxvvPVr2Y54T Tnj1u6azrtf+OJwGi2UDTUad7hJbHaNyTllO0muZIa+pgYVwuKg6iNc4UYV5LxkYRkqtx7PrAhIH Gc8AAYAM45z1OcDFA65wPpb/AGG6rTWLW/Slsa28sRCTefny2d7csSWLTN+HJMZIEitJx2UAqwJy Nur26MlKRXVsmljrx92Z3eKvTrXdVBDHtNX2/carP2+p4/barP2+rx9rqiP2WsI/Y6zn9hrci2Ws D/t9Vn7jU5+41WDcaoZ+41OfuNTn7jU5L5HDHfXyr3K0/krxOPKngpL5UzWKNtLtT5t/Nu47sF3f TWK37mVUfyGUX9luq8a8lPTLnpZjB+HXLdKOzE1k1XngoyGzq1fAkdZ9TrHz2yFSNQQiHOqYUQ50 Tj2wMIQYU7ERdQkYA6Lx0TOinOq51XAq50XH1WvmspodUmHUUDZl8d1MyDTa1XrV4q0PzcYkccY4 GcDJa1eZm++WUU5GicKo4+EsUMyzaBOx0lpsraatAQnA6jAAM+2ff48Z1zrgAzjABh5Jz1zjOPgv 9fhwPrN98s/+sfYfb+M/4/y39R9jhwY2L8f4/nBn/JcTP+fx/lf6/R//2gAIAQICBj8A2y9ie4aX ElnAXET87pxpU+6vsPB7jrXZeRNDXOLdhNaqdzA8Xlio9xZLJCWTRcuilSqZ/kRYR0nZE8vJTjBH 8ZW6WfkoJReZH8XA8m9tRNeBMyHQ50frHsQlJl213Vk668xTjjXkJ5JYrOiElqSqQV8loeyvQWHM g5kcHHglSZKZot0v/SP7Vw6kfxt1EsqZYv0OpP8A1ZDhlGTJOvAirEp6jhkSzKeC3SXMlIqSrk3U SRUSZUcNckROLK/GtimWPU/PEn5YDbacvTdPgiPJPualChSo3wPqSfU0XQ08kL4ix5bquv7jf8si tdBpN2J4ENkWIVZ0GlxF1Kx5PqW9SWlCvun0J5r2MVy9yOI2ZJ2f/H7jyeS8lMse5fBdCPlj5L4+ Srx8kJ4ruUeJ8Vun0GuH+xi/7R9S1SicfWSPiz8ci2RZln4LMrKSIxUbt9BNai6wJPifJvsKuq8M mdEyjFsqvUuJcN7MxL/Uk8HInpNR4stjdELFOiHRFViUSJaTI+OO+fLZKUyQ/qcEfNzLJrs1NSUn vsptt++J5XNe523/AP/aAAgBAwIGPwDbTY1uFOo1izkMa3SHAsluI4UGtC3xGmMjcySkRBaGW8Ex Q+5wUaP8djfM6x77EV4HXdQ9Cg2VqJJVHqSyg09dRruYr9XOB3/Y7GL3XYuyg29CuooiujJmUVI5 N+DLLRIbg5C5w/IzDvuux12OOD9ChBKmmxqLr4kJW1NBtLoKgqKpjG6bK7J0GrNONjgoJQ5u2WyQ 2poiqypoWyJ+LoQtN0uLJfbmNTbgaMrRlV4HNBaIvIlxKnUhbG90nw/YS/jj7kRsqpPtaJhk5Uiz E+KqPWlC9EXJ1ITq90hrk/czfM9dj6FmuxOPyPuWTPxyj2PxZ+ORTF9y2RL3SJ/VzNcMmLmalHdR 3LlMkVa8lGi5dEJpslvdohj6SU0T9Sha+PqPlkyyLI4H5ehNyd7bSpHKCgmhVdhttr7i7Lsuy7Py e+6rZDJXlWKXPji7e/8ARdESt8tv2THOxWO3+g//2gAIAQEBBj8A/DNudXB4+Xvq179VKmFmBNz5 1zq9c/lx+TD5OXym/HOtKmx9SPbK3CmK9NhZ+V6OgkG1/dUJHV0dKcCxJxwrWHU/yQtLGyhS6usi jIi1KikuiZqAA4A5c6MsZXUR1EnhXTa1vWxsvs508chYl7PH0kKByBNAjljwB8CKZf0Tx5H5B5f+ hYD0qNR5nGixwYi9vLGr8DjSyIMEYg+RoN5C/sq3D8DlWP4POjiCTew8qZierh4URgAWsVHBgON6 ZG/RAUEcaVLhZ4iVXUekryNdMV8AdSsLY0Ztywk3ZuERSbC/MigzC7WzNWGMUmBBt03/ADGhMpUh R6ySbEUJFwZbXGdxyxoEDUc75+dqV81a6knDEfINkxYzAqrhVLKpf06iMr0s8xIBGpjGruijWY1J bSMyOVBJjaVmYBIwznSj9vUekcaeFTKzxu0fTGxDSJiyDDMCo2V2ZJFVjIFYookOldZ+rcjjTSGM ybgB2EKajZUft6mYqNOI5VFHLrMky6wiKzkLgCx0jAC+dTLFqeaNZGRWBRZDD+sVHIxtTI5YNGGE hClkDovcdA4FiQKm3SmTRAiyuCjBu2/pcC2K/iEcj1XU+VWHI/PSscRbSQOFTQi1yA3DGijggHEA 539talOBzFCrfJasav8AN8nL5L3sOJrW9wBfEZ0AMTwxNDSMZBnxDDKhn1iw8xV3sGBwIvf5qujM 2NsBf+sWoO7PGzN0qpGtscPUCKv35b8MUt/8qikm53EZGBBMXzER00R3swsbWtFYi+BxjNaz/EJl XE2+xGf/ALVApvtxoBKg2i/dUwO+nBjNx+qy5/qqBH8Q3GIvlD+6qLdzzTNJHpNiVsWT63p6b8dN hS7PZzlNsyqjs569Kyd7LTjicMvbSq8sulWd2UEEMXbWcCptYnAjGu6jSau++5xIPXKuhhllakiW WYRKEV0utpBG5kXV03zPC1WEs0bFXjd1K3dJH7pVrqR6uVRzmWWKSJdF4m0akuG0sfNeFO7vKQRL 20uNMZ3H6wrhfHxvUv2koSYuxjBFhJInaZx03vp9lSwK8mibbptXuRfQgKhhhnj+ILfosDSFRkdJ UcudFM1N2PhSO3VzvWtBgcVNaXBDG/lnVwcbXArCsavVqzrGr10m+PCscSR50QwxJyPjxpWxLE+V 6VsLqdXPIUzxnrU6gOYtQewvxB51a3St8sqKAXVLKmrDhixoiYDViBqvqOOYC5Uz7V9LKDdHy9t8 qO1dmUSjSt+YxwvWpyWbM48eRNTFGYxkKdF+kHjagFyZGBvypMeAFDy/GRQyyBZJyREp+tpFzUu3 SQGWEKZV/R1jp99J35AncZY1v9ZmNlAobXuDvlS+i+OkGxNDHPLEU6c70ptjYg+YoP8AWTEHnQuM GwJ5EGvh3JDLil+I5VrQaWAOHA+VBZL3GRtwoC46rZf56uMqAvYnEY0S7BRmbkC3hR7UbyAYFgtl /rHCiywqoGVyW+ZL1pEwWwN9Mf03oFZ8bEnBR+WruqyA5A9BPkaA3CNt2JsGtdT7aEkbhwPSym49 9G50kD33o+QHzUZEH2RN3C5qbZ+VNZrgnhW8nOLRDEW4tRdiSzYknHOlePAqcRj1A8xW138Q69u6 Fif0W4HyoW+sAy8qAJwIN87kqf8APS3bqvoYeBJpkJuVY28qHl+M2c8UMc6bcyF4ZTpDa10rwbjU kYaN2dIEcazdu2HDYsrDDULXBqGaYpNp+FPedyWiMAtIq3BvqOPCpow0aTPC8R3Ac65i0qy3fpvi otxrYvOqmDbvM7xO/cALqunSAir6he1qZo98iRkkqhhB0jlfXRX45LHruIB7R66Vfj0scQvw4w/0 6JO8VlY2NoBgf69KU3YwxDdkYEf0q1nfIGGBUwC/+vRvvktx/u6/26Onegty+HXl/PrSu6YWzU7c W/1zV9xvlQ8SYFuL+Tmhp3gdgMGaBffi1dybdhodQUuIAxUnn14UJG3Y3QawREQRkfyjiaVdZCvn IQQl/bRmEirFiq3N7kZ4VjbHFlGFgRhlRswdbegm3z5UHhbtsvqj4EZ5ZEUUZQko9QBwNj9Wjx+Q OqkrINIA4EGt3DcfbrGTf+V03oxuLOt1IPhRmkPWFOlOX840Ymw1wOx8SDcGtu69OqPFseHC1Qlb PqurE3uFONxqNBbXNy1/yUyHiAR+Sh5fj8vkJ4m9CS1yhv8A0TnV2wXAH20zWvE+DAc61INStjb6 auRcHPUBetIHSThfOi2iWMj69r/TQ6ifM86KtciwItfiKWPbKGdl6hYsxubWtX6iRQ2LEnSp/osR QLhADgbyIpIHtrSe265j7ROk+81jty4/SSxHuWnBaRNYCtcEGy+eNaZkE8ekhScDq8WpYnB7oHpA ICk8jQZfWvoY/WA4edBsm+sPH5IVPiffXSLGSAKB43q0I0lLpLLbBnBr7eYOCLBF+mkiYW7R0kfp IcBTRH/cuR89RgA6gGJJFsKv9bK/hULcGBX5qHl+MkkWVCkJKysGBCFfUG5WoOhDK2IINwR504ik WTtsUfSQdLDNTbiPlPnVuedPGVuUbTlw4GrLkw6l8qRTchibAciONH9HLxqRwRpXBRnkc6uz6SBl zppJHC2sNZwueFAkSXYALt0wkfxkf6i/PRMOna4dKRLdjbPVI2N6KyFpG43ZiRceNEaFtcjUcT5V 1IbY4cKs2qMm3pa3zVpEhZAPrdQ/qtRWWAK36cV1b3GhuNpKZFXhazLbmpo2Lm2LBrAhq/kyDL+U K8KjXDpU6j+j5Vut0ucUYAPJlFzb2mrv1Bhf89aBDNIBbFFBHztTMu13BW2KqgJxPi1Ssdju21uS bItuX6dGRNlugEXSFCKBjz66P9w3duWhf7dQH4LdAq4JvGMR/Xrf221of4fHG7B2IkYyrqVdIBtY 50kcm2RZ3dhdpAsYVU7pLHEqfA1Kdwkckb7xNvFob0Iya7+nGviBtV7ap3ZR3DqC95oOnpxyrcQ7 iJYpts4RtDFlOpQ4sSBwP4WxWAy/abuNHWFijuhDXW4Zc/OjoMzB4GiVRKNUcnd1ozanH1MLgmt7 2EkiM0m5kLCUBJBIpEVl1+rVxsKjbcibQEGt2lBj09tF0aOq7a744eZrdtt0kgebc7iVJe4OyUdC I7oGbHVY+moFJ3CL3Nv8QGnuxCh++wIkPSbjAe6oQ0k/ZVZFVUlAdX7t0LsWxBSw+t5Uwjk2wS/R qRy1vEhgL1+s2n9ST+1RJk2upyAxCSez61au5tNYFvRJz/nUTr2o080k+bqq/c2mPJJB/tU6bhoj Irf7oMBbx1Emg5vY2F6LKmso3bgQ8ZOLHyoxOdcsp+1c5sTxv4UEk1dF+23EkUdxEPtAPtEbAsfp rU11tcWvx41dXDNgbC/PjR6eViKJuAgyuaBUgm3DhV26SPRc9V6RtAUzsVYW6dS+HjUTlyAxwsLl T5caWSHuAZnXYBrcAuNPO4GB/wArCpobY9ks1stbkG3DhSgjEXx41ck6+I+mm3Dr+scBLYkhTj89 FQRizNc+dSOxu2ojVzA51YC1uI51GSb4Eiu4YkLbhFEzFReQAWGvnXY+Ei7WrX29C6dVrarWzqQS beNhLp7l1B1afTq52rtjaRBNOjToW2m+q2WV8ado0VGkN3IABYgWx/CxA+XL8A+fyMnEqDeg+RIz 8qOoYjjzvWm+C4k+IrWDeNz1jlfjWJuL3xxqEyEYCSTH9Ik0Bw4VdgdTN0ED0sT6sKb41iJPqDIM KaVIjHuQdRGYa9dsoY5FsSrYWv8Alrqy4nnXcEYGAC4/ParKrXyw6rgDlnTSIuhRmXzP81c6ggPV KArSMeDsdXzZUJcoISFux9TDlQ7vRGtlW3C/GgqW+Hj6mlyDMOV+FNBsm7cLm0kpHU5HLlRIcgcQ c6BEo0JfNswOQ50kkQARIlEYGeth/kaER1dwrbAYajnicKWMHC2LeNEWtY586CEagiYedQbV51Wc qo0Hmw6b8r1Ix3SaYhdzfIBtFxz6sKtHuFZjq0rkSVF9ONsajiadUnlCkRkgkFxqVdQwxqII5lMs 6beyZhpL6WOq3SbZ022adVmRlV14gsC6j2qDTyruFKR2DZ3Or02GZvwtnX61e0Yu93dQtYNotp9W eGVaBJePsifvjFLM3bC89Vxyo7wTKYFOkvyN9Om2d78PxB86tQHHSPy1JGbEKwCnlfGlBFzzqw/y xoh8jhhXbkYcLNzB/PSB8w8kItjjqJw99Z2AHvpkbFTgfpoLKcB6GGaWyamjnwkAurf8S3K9ESDU bWVgbEYcD4UkkUj9xSoOqxDK2HCtUiCR3xJLMtr30jSPKjp0xlum6Xvf201/049Oo9R6hXY+s73b mqjOjt0TBekE4WNvVzvQSMyvCGAeTuOfO2pqjjhMiLMSAO9LdVGYtqtjXSzhVGPW4/2qxMlz/wA2 T+1QRO5qayqO45z82qGMPNZOqT7aUYAWW3VzrUWmIBxAnlxY+n69E6pyBw+Im/t1qLThb/8AHm/e U7XlFzZT3pSbDzeoN6s7RhVjLKBaRtItYyAjUDx1XqbaLOBG40owiXWB3e71Pe7cuVEd+2rc/FX0 jinb01q+IJOvbP6R/wDSro5/WpJG3RftzxzglAGbtF2Adr4nrzqTfGYosqgTQqPW4VolfUcrK1NB 3Y7kIqMIVGEeHUfUWPMMPChq3bMyw9kMRc6hIJ1OJvYEZcuNdybddyTtRoS0Y0l45DLqKrYWN7W+ en2YaO7v3GPZXt3DB7drlhzv4/iD5n5M8NIFvbUpt9bG3O1W9t+XhRtY2yFW9pPjXJsweVEPmkvc 1NxVhifmq4y48atzxJFG9gQLqaEcoWVb25FT4HhRSGbVFGOoyjV1H6qleVTBghCFTeO/FhbBhSuh VegEkg545VjMbG46BjbzxoSF3Y6gFDMSS/IeRp2WPuSN+se5LYDAAUDP9jAMWPFv5K18FsAE0YM4 x0/yV5nxoCeVpNJw1G4F+VAAEAgleGI50rh8frLY3H9LKhM1wkZ6TnZuZ8qa4PXmcrKMqGkcgByF EZhsaZjYNz5k8KVfU/01HE7qJNIshOJ8hSsj2Ml9CtdWOm4PS2PCh9opx05/WHCjtxMvcVO6f0dG rTfVlmKfbLMpmjUSSLcdKHImhI0yBDfSxYWNs8aChlLMNQAOY50dkJlO4CdwpwC6tHqy9XCj9ouB 0+oerlUk6TqY4ZBDI9+kSEhQt/NvxB8/kd+IsLczQaYgMcW5k+FaVsLZXBY4cwLD56AHcGrL0gey w/PWnuOBkMQ3v1ChkQMbONJ961FLYq3aYOp5qRYfOaR0BeFhiOTU4RwHQgFL2IHlRY4ADO9Oyg6Z WJXlgaANwdTEnmWPGplHFL/1Tela2uZ+iGM5Eg5nwFBmOuUgKFHqc+XKu88rJLlHGoQqL8buGx8a 1jcyCQ5WWIi4PjHSLFu5PiJAda6YulD5JnX61754hfoqMmYhHGZVMP8ARoB9y6AcQI7X8CUtXw8O 4dtRsXKR6QL5nSldmDdygPewCxenmfs8zVvjpscMFhOWf+6qx301+HTD+6o/32cqMjph/dUkZ3sr D1NdYcLZZR0B8XIMcwsR/wC3T/xB2G5jPacFywkQwgg6UjsrFv8AIV/DpGKxNAweRSxDr9o7n0jH UrDOkRTtxLtp0lQgMO8seoXlbgTq5e+grPEX7aoVDNYkTPMRq03A0tnUsBeHuyQJGZcSdUTlwpNr lWXA1FudyIpIo33Esm2QFtIlVQixgqL+nwqXcbsMqhWg2Yk/WLDqZgX8eqnGuAKsIiRhe8jLMJg0 nThcCxxNGWX4aQybiaV4pNToqTaMRgt2XT4Vutoxj7M+6XcIVX6okSXQy/0bfiD5/I07AlVYiNP0 iPrUWuQt8LHE41aQG54LibHmaV4tuApGBY4keIvRLwqRjcjw9tWkQqbZg8PbUcgkDJqswtY9Qtem jjYhQx1I3Uo/OKklePUjqDrS5ZTfjxrTFuWe1tURa1/DHGgqdDR5R2GI8KKabK7Fl8zwqZmP+7YZ XzytWqOJdRWwlfGy/wAlDhjzNE3Mk7YGQ4nTfLkKHw/ZsQNIkDhgOJNqdv7r2tuOr9ZmOVPKxi1u xY+rAUDaHSRa/XagoO2suFmEmVRQ6tvoLaSvXbzorCu1RQbkjuanPJjRI+F7kvH7TCgqna2H/Uon +64nD9ZTOTtQoz/WV3H+G1Ocj3MqLx/CXA49zjSbSNolkG2Sbt6SxlkZ9BRLkHGp57oiLvvhNRTC GPVjK2OPKtuxKdWsahGbzaZNCsilgLFccGv4Wr+IPLJqnTdSBVkQgJGqao8L4BrYc6n3TOHbcy7f SrqQm3imQNq/m36fOo94xiM7yLG0yq3bVC+nuaW0nAeypty0vc+GTcIvZBKuI3jVZCtyL2Y0SjRD tbeSdmVCyuYpTHYdQwYVBFLKIUTdNH8KgIZoxGWWRsbkHytWX4g+Zo6cGayr5mu2h0qo0qRjhfE+ 2g+AkbBVtzp95vMZbXUNkq+XOrbaN5CMibqD7sfeRVn25TixDE/OdQpu/FdsASy8D7/y0zbV9JsT 2zYgjkMcKJAMkcyh2RRccmNWZXUk5LYnOhJGhUj1E4EmltIcM1bG3kaAmT1XAkH1T9NGEtrMzqIy L3KDqJYVaORQEATFs9Isauh1c3tZReiIAWOkkucLm1RRE2aSQ67cdOBrFbFr9X5q14hUvjbA2HiR Xw+1Us9xqOQFNI7B5T63GWfpj+mu64tpvpvhp8vGmmfFibDwHhVjibceVKw5cON6EIGC9TnjerkU WtYscB4UN4Yx8QE7Yk46L6tNeke6hgMMsKxUG+eFYgW435CjDMoZM7DAjkRbKjFt4wikktxLE5li cSTWQtblV7C/O1Z4ZfgbcwxrLJuJhCA7FQuoE3NgeVQiLaAlkMspZwqgCQxEBmsPq3xqWPs6EvuY 45Ee7h9sNeIZLYjzqPbSRqsblUEhe5ZmW/1V03/kmx40yvuYlYHFS6gg3440NDAqouCMQWYdPzUG J6V58hT7lzeOL9Wv1dQ5+FB2I7SEhAMjb6zUDHpVDhdr9Q5qBSjoawwaxU+zOiJY7KPrOoYH2ofy 13duSjHG/D30sjfrImZTbHUHxH5aQzKqMvqYAqx55Vfb7vQLZSDVl4rQvNDpJtqsxw8qaGOTuvID qduo+xRRnk1KFUKoNrotr9RbC5ooHclQSCuFmPM8aBOzeRT+rPdjF1prbJlJBIJmj9tLKdkyLt2L Oe4hwvj40LbXViCD3EGfGgI9kUc2BbvJY3oB9kRqxJ7qAyNyruybEm2AAmjAUUEXYHSPV9tHkK// AJ5sf+dHRY/w9sMLCaP56P8AcCHbBfto6+4G5zPeSgBsiScP10dBV/hjYCw+2jraxiOSLbPEpKon dBmZwGR2GACrxuPbW56pE3KRSSMhiGlHjk6UiOnq1JfnUkkurbxJBNuQxQW0sFEUZJHrQnEUzQvM +27yBNw0WmQoYtTYCI4auOipNv8AxCeZYG2yA2jWMM0mtWN2W4Iw9tJs9cz7ZX0LaIaO2FsNTMo8 9WvP6tCCKZkibcwwRoqBkdHF5NTFT1X8a2O2jjnWLQBIWjJXq13PoJuptmR5UivJO6yQwSyydkF4 2eTTKqBU4LwINbsuZ7nfLJHIUPe7ffjbuBNP6Nz6fZV74UZTu4u2raS2tbBiPTnnS33MfWvcUaxi gx155YGoBNuYpYop1ZAHUq0ljpQ53uDlW3LvtSEw2pOjDSdPR7RV220TXLNcoM5BZz/S40Nwm2jW ZcBIEAYWGnPypiVGFzlRfVa4LC3DgPmqRybG2kGludMkgsviXOn8lQx2shA1tl0LiffRj2UJZFPr bBbeFCLcRhdWAYYgk1Y5Xw91FiNDH6y4X9lXw0TLyv1JxtztSyq2mTJtJIAPG4N61RSauJ1AHA/z SDSsLMMrlSPyuKDdC3+sLC4+etWBci6mx025gc/Gg1lfEXJxzpdtubPA1tLWsyewV2XBVOpQcbHV bjU0EourE6lNtJHh50uOrayn7KTivHQ3lUaLibqL+3hSRH0RLqsARY+mtAv3GOo2+rfnVz1Na5I5 VbNrGw8L1qY2AzPOi5430jkKNqBNrJifP5B5fI0ciB0fBlYXBHiKsBYDIVl8i7loEO4X0ylRrHkf wHVjZWBBOVhatS/xGJjs5E7b9vABFZRrAOp8CTe9q3W12+9SaV9m23VWst3KyT6tV7Ws/u41HPN/ EY13Mb7bSFQlFeJCEUpe7agTiM6i2ifxOMSwa1kYJZjaQyuoYtwvk1+dGRd0pVSq343b09OZ1VEf iUIn/VWyOOnH21LGd1CsqggqZFBB5G5olNxCwsoazoeHnS9sj7Ug6lOrVW1g1agpVj/RwA99WIsW ULe+RfF/yUqgZjEZZ07DpI6qC3swAPzVa3IXppI11PAdYA+tb1L7RU22MYkTSJYif5XqsaB2kp0r h25MR5BqK7iDTfDUCbDxXMUAynhlw91AXci9+oHOrRR6icSWwH9WgFJaRzgeN+dKDcuV6rc7Y5UY pASVFklA4HnU6sBrjCvfhdDnUMi7czRqdWoMi43OHURwqSRtnJaQ9PXFgBn9fOhbYylBgT3Ir/69 WGwlUWII7kI/26u2xlxzYyQ3P+nQPwT6B6R3Iv7dWOyf9pF/brHYyEnICSL+3Vv/ANbMTmW1w5/t K/8A5k/9eH95WyjgR40kCdxGXUvW2hl1KGFwMcx7aMoeSSeSJpLGJegxzBOkaRmlzjUku3lIhE8g VhGQ7RqiFQhZCuZOefA1DLMCsjoGdSuggnmtzb3/AIbIcmBU+2vg33pZVYCENEulY1UoFYZtnzoK 8zGLsCFkAAJk7fZ7t8fqYWqAHcLq28sUoKRKmpYVKAMcyTfMmpQ8zFZtxLuHAFsJ0MbJnwvnRifc B3CxRxsYxpVIQQuBN72Y9QIPKtrq3jyfDAAiQa72fu3W56Tw44VKTDGWxN9IvfnVxGg1Ph0jLLOo EUabAAAcKcW1LEEJI8Tq/wBqo1wIZsAP5Nsa0nH/AONOMsLX86wOOnE0o4qMeWFE3wuKhIa6CaWA jLoILL7qCpiAxuBhTF9IFvS2furCNbjjGdJ+atCSSX5NZrfnoF5Wa/AWX6aOhQG4uTcj21bUA6j7 M+PjTRbmN0kBPXHgbj8tNCmr7ayKGwbTmb2rTqW1rKoF8PM00G8we3TKciPbxoBpcMTp51aMtp5n BfpNBmNzzOFqtQLHC9d2QWY+lTw+UXHKshhWVN2pFk7bFJNJB0sM1NsjR26yqZ1GoxBhrA56c/w8 vwpbmw0tjSi+TYYm4Fr1tgwub4+QFb1b4dC2vidI/wA1bdbWC6mN88/81DDE1GmS6rkeAo24m3sF NqyuRRCWC4+WAq8LIGG4ZgZASMuAUippVk23SRcaJPrG2HXRleTbtKLklkkPuOuh+pU8GRZBl5PW gS7d7cHV7589dfaGJR4RSN+SSivf2484Jbf69XE8DYWusEow/r0oHwzKvF43/PIb00pk2xc3uSj4 eA66/WbawH/Dk/t11SbVvONz/wBysDtFvyjcf7dfrdthyjk/t1bube+WMcl8P6dYvtrnnHJ/boO0 m1XkDHIf+5X6/a/spP3lfeNr+yf95X3ja/spP3lbWWJy0LoibjQxjjjMbiQsEJudY6a3moSjUyFY 0lFmKs19JZr202JHTfwobc6l3hYMwWU6ygfUVDljYlcPV7akKRzxxvuJ5O0kqiRhIEEbM+u2Fjz8 q3B2yyK8u4hkmIkBeWIKO4EYkC+ryoFnmWOPaOsDSzarbku2jWFwJ0nkahRzuQWlg+K1TCxVb90p pa4B88eVRxxCZ1RpVQCbBV7l01HWrenjqNv0aXWeoAavP8TKOYYWpo9QL3DFbcDW3Bxwxw8K3SjA Bxb2oahDYFo7HG+N2rHhTkYCMBffjQkdwqk4jM+wV1B7EkltB02NHssGAJGGdFbEkTYj+cL0iD68 gv4gVhwoXyxtR0nSeAq6gNhmMaF7heI4VqJwt51n51nax5UBmPHCrry86GGPjXXhzwrRCNXiBh7T QMnW4HsFYfgDy+XL5Mvky/FSyL6gDbzJsKE2z6dxHcKrf7wKcahYLodCFMZzBGZtU4Nr9LEt4Jb8 9bU8G1RkjwNEnAZ+6gxsZ52IRTb1tkPYKBLHdbh82K3byUcBRkl2rGIDpVbECmm2P2Uy2uhw1eyl dpUQgKZF1D1rhekb4mMujrpOsZccL196i/rrX3mL+stfeYr/AM8VhuogP563rHcQt/TW/wCWujdx AjgWBHz0Q0sTcSUcUD8Qqk5gmvvKe8VfvqTyBFdEqDldgKUSbqFb59YsBQjTd7cKBYASKK++wftF +mvv0H7Ra++wftF+mvvsH7Rfpr77B+0X6ai2u3gfeFoxMzRdQ7ZbR06Q1z7vOp4xtzGEbcRxy6gx 17ddZumGBFbcwxBYjKkM0jm7MWj7pCoMvO9Qx7SESSK22G4eQ6bncDUAoW/DjW37G2MnxBiTqcLp eYsFU4H9A13OyYTLHI0TXDkNAdMgK4ezHGm/hzwNFiQjyMFZtI9QRrXU4+kn8A7aWKVVEo25msuj uMutVwbViPCmljgnIGjt9KkP3G7YsQ1hjwJFM4SQJEsvdh0apBJEyoVBViPrf56n34R0h2+rXfSS dIvhoZh89Jt44Xi0SBdyJAGOl43lXR22PBaRItvNJJI7xqi6M0XuE6tem2k86hRIpWE4QqxCqPtO A1MC2njpvan5E2OHOkBxGnAi+BBoyyMCVGo4WNlHOhK/qnfUT5mwFXB64iHjvgSc2ApJFyfThl51 tttGLTFtSyDNF5gVr9Ujep2xY3rmbZGk3m2ADK3UnHOkmH+9XqAyuwOHvqZWvpjfDibBqAJubXv5 jnWPqyOF6BDZ8q9VyMgaN0IFHVblaulgPnq7MDXrA8qtr1Mcsa1KtwL9ROZoLmSLsfE1kPdXpHur 0j3V6R7q9I91ZD3Uk24hV5EGkNzUHVpa3qF8bGtxK8ZmfcNIzFzcL3vWqDhh7aEpgGpQLAEgdI0g 2va9sL0kkcIjmjVRHIt8DGLRsRkxXheiki/ESGb4lpHtqM36XTYC1CNoFKKHCrjh3Td/fXxkcKif EhhwLYMwGQJ5/gTb7ckzPJIJY0a4SNlXQDpvpJ8a0LGxW6kBndrds6lC3bAA1I6x4yGQyEO2cpDP xwyHlU+0gUom4v3GN3YluJL3vU0u6Y7mSZg2OrSNKGK1mZicGOZpXhiIMRJUl3a2pe2fUf0cPCo2 MRIhChF1tosnpuuqxt41LMHn1X1ECeULnj0hrCpIWeYFWuFE0gGk8T1VPp4xta3DwFQzqbCNh4m5 yqGS5DLIM74BlYt7KhBPVdAOFKT9VABQ44CieeYphlxy50UJBaKYEY46WN636RnUGBNjfDjUfAFe nHMisur5qF1qwFvCvKrnjwrz5C1WDHHkbH311Sthj7qDMwNuOd61HAZqvI3ofJjWFW+VQSL2y+Sx OX4ndLCWEpifQY/XqthpraxbFJUcwwusax3WSdmHeEx04WXmRTzRyTdx93okXRcx7dWazRqq6jfD nWzKNuJC62YCIRsza7Atg4Xp4Nat/EYpF28h3ckIVC/clPpEmpSLW9NsDUMpabt/FLCYDGBGIO2C WsFBwbC9Mq7eMx3I1GW1x5aDSytclRa4yaLkeZWlDse2bDV/JYUdqw+0WTQBncg4VDttWlnuQpxL D0r+Wok/QZfmqCW/Q91vyNLc4286PHDjRJ2sY4D7f/x1M77dVIVS3236J/mVu5E2ykBFZwZbYFcx 9mb0EXaowB6SZrcP+ma+5R3/AOv/AOKrnZxf4g/uq+5w2/8AyD+6r7nFh/8Acf8Air7pF/iP/FX3 SLHD7x/4qw2SYWymP7qj/dFA/wCtz/8AbrW20TDCxnv/ANutQ2iANh1T2OP/ALdD+5w/4g/uq+5w /wCIP7qrfBw/4g/uqt8HB/iD+6r7nD/iD+6r7pB/iD+6r7lB/iD+6pt5tkk1PsisSJ9pGk2oFlGH 6OIvnRIlncd22owMrEab2vYvpvx0Z4ZVudxLHO8m4j2jRpIgcAK9pMlKgjP56dN13miOvUWTtotj hYFfdpY3H4m9sfkxw+THDzo12txGHTkeFPt9jIZQpw25tKw+j2024YGN2IbUNIA4U805726a2qQ9 Vh4U9+AuLc6YqblLSIV5jEigSbjC9XON6vkDUyggWREy4ltVbydmszt21UjOw0r7K1nHE29leBNL ccK8PGhgOVCyi3HCr8DXPxrSOPEViOOOBpdWZYfJjV6N/ZWPyj8ZOmxErB4ojttEXcGvX9piFNun nTzI0vdfdmNgUBMcAZrMirGTjhwNSyzGecybQIgVCg1iUX+zAwJWxx/zVDslnm+HWVlebtrqKCJX W50aba7iptvuIJjt1eN0vGRZknCmzKoFtGPHzp44NuQVw7kpCx+zSSx91X3cpkX/AIK9MeHl1N7T 7KsihEKjSFAH5KFxccaIAzrSRjR27cATGeBHI13IhfbucUGJU0CDcfnoySmyr44seQokreVzrf8A nH0J7Kh2rMoJYtIzWAuTxJoQru4QAP8AiLn76Grdwgf9Rf7VffIP2i/TX3yH9ov0198g8PtF+mvv kH7RfprHeQHykUfnr75CMP8AiL9NYbuHD/mL9Nfe4MePcX6aUneQADP7Rfpr77B+0X6a++QftF+m vvkGH/MX6a++QftF+mvvkP7Rfpr75B+0X6a++wftF+mo9mIyY5NIWcsFV9Qzj1YNbC9jUe6j2shj nmG32xLKBIWLLc8VxXlTqNqToc7fVrFviAnc0/zfGll3W3Jl+Gj3L6GGn7V+2AL++jt02rMzPLHC dYAdoMXv+jhjUW7jBVZlDBWzF/wx8D3tKrGdusa3jeQyWkEhtgNPMipm2MksxHxaya0+zQobQ9sk AE3qOJp9yY2mCvKYzGwAjJaxa506wMSBW2cpLHLK23j3LrHpbt6pVe7ab5BTQG4nlhWOGQxkDraU TFE7llyKcbClJzIFz4kfIjHJlIPmKBuR4VfnwoA486KXKMfS44Ghtt6lhkJB1KRWtCCrYmRW0m/l SFSVkRrqW6lt4g0XldZJcgoGkXvyzr4yb1G/bT6aJYXPCwHCuBwwrIe6sh7qyHurL5qtYY1ewq4F vOrnH2CsVF6uQPdVyB7qyHur0jDwo9I9wrIe4V6R7qXdPCDMLG+IBK+ksowJHChp26jTKJlAvhIp JBHIY5ZUd0YQZSdRxOktbTq0enVbjSJJBqWMaVGph0lteg2OIByHClkEA1o0jqccGmwkOfGk28K6 IoxZFxwHt/EEIoUEkkAWxOJNZfIryxK7R4ozAEqfCj5/IrHMXtQBztx/NQvwq/yFJVVxxB/NQbbN p42Yn5jV/ibNyxwFCWS80ox1ucL87UAAABwGFYVz/A8q/P8AJ5/JblWFc6/N+CPL/wBCfP5PfSeV D5RTeVeyvZ+GflHyH8QPL8V//9k= ------=_NextPart_000_0004_01C5AB42.305894B0-- From owner-namedroppers@ops.ietf.org Mon Aug 29 04:00:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9eZN-0005iH-4S for dnsext-archive@megatron.ietf.org; Mon, 29 Aug 2005 04:00:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23216 for ; Mon, 29 Aug 2005 04:00:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9eTo-0009Pw-Nv for namedroppers-data@psg.com; Mon, 29 Aug 2005 07:54:56 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9eTl-0009PY-Ts for namedroppers@ops.ietf.org; Mon, 29 Aug 2005 07:54:54 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 783EEC2DA4; Mon, 29 Aug 2005 08:54:52 +0100 (BST) Date: Mon, 29 Aug 2005 08:54:55 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , namedroppers@ops.ietf.org Cc: ed.lewis@neustar.biz, Alex Bligh Subject: Re: opt-in and wild card discussion Message-ID: <7E3DFEB450CBD75378BEE2D2@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 25 August 2005 22:29 -0400 Edward Lewis wrote: > I recall a conversation amongst those of us working in close quarters in > the early days (close quarters meaning, in office, hence nothing in > email) on the purpose of DNSSEC. One opinion was that DNSSEC was meant > solely to say that what goes into the master server comes out of the > resolver - no changes, no deviations. The contrasting opinion of the day > was that the resolver would return the data it received along with some > measure of surety of the data so that the application could act > accordingly. I think I'm even less ambitious than that. I thought the idea was that IF a resolver made a query AND received a reply, it could determine whether (i) the resolver ought to have expected a signed reply, and (ii) whether that if the reply WAS signed, it was signed a key possessed by an authoritative server. No more, no less. That's a bit different from the first opinion, as it worked on the presumption that DNSSEC would not prevent denial of service attacks (either packet loss, or through injection of SERVFAIL etc.) and (less significantly) presumption of continuing legacy support. It also means DNSSEC is not in itself responsible for ensuring security of private keys etc. Perhaps that's why I'm less worried about opt-in than some. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 29 09:11:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jQP-0006gn-Mu for dnsext-archive@megatron.ietf.org; Mon, 29 Aug 2005 09:11:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07698 for ; Mon, 29 Aug 2005 09:11:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9jKa-000HwF-AE for namedroppers-data@psg.com; Mon, 29 Aug 2005 13:05:44 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E9jKX-000Hvi-AU for namedroppers@ops.ietf.org; Mon, 29 Aug 2005 13:05:41 +0000 Received: from [10.31.32.76] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7TD5UAS021178; Mon, 29 Aug 2005 09:05:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <7E3DFEB450CBD75378BEE2D2@[192.168.100.25]> References: <7E3DFEB450CBD75378BEE2D2@[192.168.100.25]> Date: Mon, 29 Aug 2005 08:59:25 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: opt-in and wild card discussion Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:54 +0100 8/29/05, Alex Bligh wrote: >--On 25 August 2005 22:29 -0400 Edward Lewis wrote: > >> I recall a conversation amongst those of us working in close quarters in >> the early days (close quarters meaning, in office, hence nothing in >> email) on the purpose of DNSSEC. One opinion was that DNSSEC was meant >> solely to say that what goes into the master server comes out of the >> resolver - no changes, no deviations. The contrasting opinion of the day >> was that the resolver would return the data it received along with some >> measure of surety of the data so that the application could act >> accordingly. > >I think I'm even less ambitious than that. I thought the idea was that IF a >resolver made a query AND received a reply, it could determine whether (i) >the resolver ought to have expected a signed reply, and (ii) whether that >if the reply WAS signed, it was signed a key possessed by an authoritative >server. No more, no less. > >That's a bit different from the first opinion, as it worked on the >presumption that DNSSEC would not prevent denial of service attacks (either >packet loss, or through injection of SERVFAIL etc.) and (less >significantly) presumption of continuing legacy support. It also means >DNSSEC is not in itself responsible for ensuring security of private keys >etc. Perhaps that's why I'm less worried about opt-in than some. I don't think there is a semantic difference between the first opinion and what you describe, but there is a syntactic difference. I failed to comprehensively capture the old conversation - things like denial of service attacks weren't part of the thought then. What was meant by "what goes in" and "what goes out" referred to the extent of the protection, i.e., DNSSEC would not go up into application space. (This is describing the first opinion, not a consensus.) Perhaps what I should have said was "what goes out" is "what went in" and not the other way around. The syntactic difference is steps i and ii are one way to carry out the mission, and although that is how we have approached it, that was more detail than the conversation had at that time. (I mean, we were already writing code, the conversation was just "higher level.") -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From online-banking-rep83595@bankofthewest.com Mon Aug 29 21:37:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9v3f-000433-UZ; Mon, 29 Aug 2005 21:37:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28951; Mon, 29 Aug 2005 21:37:02 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9v55-0007Tj-Vf; Mon, 29 Aug 2005 21:38:34 -0400 Received: from [203.149.7.150] (helo=COM1) by mx2.foretec.com with smtp (Exim 4.24) id 1E9v3X-0007bq-2n; Mon, 29 Aug 2005 21:36:57 -0400 Received: from 203.149.7.150 ([152.80.196.237]) by www.clicquot.com (8.10.2/8.10.2) with SMTP id iA83lhP99810 for ; Mon, 29 Aug 2005 22:28:41 -0400 Message-ID: From: "online-banking-rep44412@bankofthewest.com" To: dnsext-archive@ietf.org Subject: Bank of the West Security Update Date: Mon, 29 Aug 2005 20:27:41 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--l%7qbt56871IX" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Score: 4.4 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----l%7qbt56871IX Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Dear BankoftheWest.com customer, We recently have determined that different computers have logged onto your Online Banking Bank of the West account, and multiple passwords failures were present before the logins. We now need you to re-confirm your account information to us. If this is not completed within 24 hours, we will be forced to suspend your account Indefinitely, as it may have been used for fraudulent purposes. We thank you for your cooperation in this manner . Click below to confirm and verify your Online Banking Account: http://217.172.79.180/bankofthewest/ Note: If you choose to ignore our request, you leave us no choice but to temporary suspend your account. Best Regards, BankoftheWest.com Bank of the West Security and Anti-Fraudulent Department ----l%7qbt56871IX-- From owner-namedroppers@ops.ietf.org Tue Aug 30 00:59:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9yDt-0000ej-Ry for dnsext-archive@megatron.ietf.org; Tue, 30 Aug 2005 00:59:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07016 for ; Tue, 30 Aug 2005 00:59:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9y9a-0001TF-Ni for namedroppers-data@psg.com; Tue, 30 Aug 2005 04:55:22 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E9y9Z-0001Se-U9 for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 04:55:22 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E9y9Y-0001Fn-NV for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 00:55:20 -0400 Received: by internaut.com (Postfix, from userid 1000) id 82FD960D43; Mon, 29 Aug 2005 21:55:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 7550360D17 for ; Mon, 29 Aug 2005 21:55:19 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 29 Aug 2005 21:55:19 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 98: Usage Restrictions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk LLMNR Issue 98 (Usage Restrictions) was submitted in IETF Last Call. The text of the issue is enclosed below. The proposed resolution is as follows: In section 2 change: " An LLMNR sender MAY send a query for any name. By default, LLMNR requests SHOULD NOT be sent unless one of these conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism. A dual stack host SHOULD attempt to reach DNS servers overall protocols on which DNS server address(es) are configured, prior to sending LLMNR queries. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this inplies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. Where a single resolver call generates DNS queries for A and AAAA RRs, an implementation MAY choose not to send LLMNR queries if any of the DNS queries is successful. An LLMNR query SHOULD only be sent for the originally requested name; the DNS searchlist is not used to from additional LLMNR queries. A typical sequence of events for LLMNR usage is as follows: [a] DNS servers are not configured or attempts to resolve the name via DNS have failed, after exhausting the searchlist. [b] An LLMNR sender sends an LLMNR query to the link-scope multicast address(es), unless a unicast query is indicated. A sender SHOULD send LLMNR queries for PTR RRs via unicast, as specified in Section 2.4. [c] A responder responds to this query only if it is authoritative for the domain name in the query. A responder responds to a multicast query by sending a unicast UDP response to the sender. Unicast queries are responded to as indicated in Section 2.4. [d] Upon reception of the response, the sender processes it. The sections that follow provide further details on sender and responder behavior." To: "By default, LLMNR queries MAY be sent only when one of the following conditions are met:" [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism. A dual stack host SHOULD attempt to reach DNS servers overall protocols on which DNS server address(es) are configured, prior to sending LLMNR queries. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this inplies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. Where a single resolver call generates DNS queries for A and AAAA RRs, an implementation MAY choose not to send LLMNR queries if any of the DNS queries is successful. An LLMNR query SHOULD only be sent for the originally requested name; a searchlist is not used to form additional LLMNR queries. Note: While these conditions are necessary for sending an LLMNR query, they are not sufficient. While an LLMNR sender MAY send a query for any name, it also MAY impose additional conditions on sending LLMNR queries. A sender configured with a DNS server MAY choose to send LLMNR queries only for unqualified names and for fully qualified domain names within configured zones. A typical sequence of events for LLMNR usage is as follows: [a] DNS servers are not configured or attempts to resolve the name via DNS have failed, after exhausting the searchlist. Also, the name to be queried satisfies the restrictions imposed by the implementation. [b] An LLMNR sender sends an LLMNR query to the link-scope multicast address(es), unless a unicast query is indicated, as specified in Section 2.4. [c] A responder responds to this query only if it is authoritative for the domain name in the query. A responder responds to a multicast query by sending a unicast UDP response to the sender. Unicast queries are responded to as indicated in Section 2.4. [d] Upon reception of the response, the sender processes it. The sections that follow provide further details on sender and responder behavior." --------------------------------------------------------------------------- Issue 98: Usage Restrictions Submitter: Dave Thaler Submitter email address: dthaler@microsoft.com Date first submitted: August 18, 2005 Reference: Document: LLMNR-42 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Section 2 describes the conditions under which LLMNR queries MAY be sent. However, these conditions are necessary but are not sufficient; an LLMNR sender is NOT REQUIRED to send LLMNR queries if the conditions are satisfied. The specification needs to clarify this point. -- to unsubscribe send a message to namedroppers-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 Aug 30 00:59:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9yE0-0000ex-8p for dnsext-archive@megatron.ietf.org; Tue, 30 Aug 2005 00:59:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07019 for ; Tue, 30 Aug 2005 00:59:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9yBw-000235-8P for namedroppers-data@psg.com; Tue, 30 Aug 2005 04:57:48 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E9yBv-00022n-Fd for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 04:57:47 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E9yBu-0001Vs-7O for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 00:57:46 -0400 Received: by internaut.com (Postfix, from userid 1000) id DCE0760D43; Mon, 29 Aug 2005 21:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id CE27860D17 for ; Mon, 29 Aug 2005 21:57:44 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 29 Aug 2005 21:57:44 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 99: Multiprotocol and Multihoming Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk LLMNR Issue 99 (Multiprotocol and Multihoming) was submitted in IETF last call. The text of the issue is enclosed below. The proposed resolution is as follows: Add the following to Section 2.2: "A sender can handle duplicate responses by discarding responses with a source IP address and ID field that duplicate a response already received." In Section 4.1, change: "If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender." To: "If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender. To avoid triggering conflict detection, a responder that detects that it is connected to the same link on multiple interfaces SHOULD set the 'C' bit in responses." In Section 4.2, change: "If the query is for a UNIQUE name, then the responder MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received, then a conflict has been detected." To: "If the query is for a UNIQUE name, then the responder MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender. To avoid triggering conflict detection, a responder that detects that it is connected to the same link on multiple interfaces SHOULD set the 'C' bit in responses." -------------------------------------------------------------------------- Issue 99: Multiprotocol and Multihoming Submitter: Yi Zhao Submitter email address: yizhao@microsoft.com Date first submitted: August 18, 2005 Reference: Document: LLMNR-42 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: [YZ] In the case where a sender is multihomed and both interfaces are connected to the same link, a number of problems can arise: A | -------------------- | | Host a) A UNIQUENess verification test by Host on one interface can return a response from another interface. b) An LLMNR query sent out both interfaces by Host will result in A sending back two similar responses. c) A can send an LLMNR query and receive a response from Host on each interface. A will then detect a conflict and resend the query with the 'C' bit set. How does Host respond to this? [BA] a) Section 4.1 states: "If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender." b) Conflicts are only detected with respect to a single query, sent out a single interface. c) If UNIQUENESS verification discloses that a responder is connected to the same link on multiple interfaces, then the responder SHOULD set the 'C' bit on responses, to avoid triggering conflict detection on senders. If a responder receives a query with the 'C' bit set, and on investigating the potential conflict, discovers that it has multiple interfaces connected to the same link, then the responder SHOULD set the 'C' bit in responses from that point forward. [YZ] If a single resolver call results in two LLMNR queries, one for an A RR and another for a AAAA RR, it is possible for one response to be received for each query. Is this a conflict? [BA] Since only a single response is received for each query, it is possible that we have two responders with the same name, one of which is IPv4-only and the other which is IPv6-only. However, I'm not clear how we can distinguish this from the case where the same host is responding to both queries. The LLMNR spec says that a responder SHOULD implement LLMNR on all protocols that it supports in order to avoid the "ships in the night" case. Receiving a single response to a query is not considered a conflict except for UNIQUEness verification. Either the same responder sends responses to both the A and AAAA queries, or two different responders respond, one to each query. In the latter case, we can assume that we have two hosts who do not speak the same protocol; otherwise we would have gotten two responses to at least one of the queries. If the two hosts don't speak the same protocol, sending a query with the 'C' bit set will not help the hosts discover the conflict and resolve it; this is the "ships in the night" scenario. If only a single host responds to both queries, then sending a query with the 'C' bit set also provides little benefit. Of course, if you receive multiple responses to the same query, the situation is different. [YZ] How are duplicate responses detected? Is it necessary to compare all fields in the response packet? [BA] A sender can discard responses with a source IP address and ID field that has previously been received for a given request. There is no need to compare the rest of the packet. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 30 01:02:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9yGq-00012r-C0 for dnsext-archive@megatron.ietf.org; Tue, 30 Aug 2005 01:02:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07097 for ; Tue, 30 Aug 2005 01:02:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9yEV-0002YY-E0 for namedroppers-data@psg.com; Tue, 30 Aug 2005 05:00:27 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E9yEU-0002Y7-LN for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 05:00:26 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E9yET-0001ld-D3 for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 01:00:25 -0400 Received: by internaut.com (Postfix, from userid 1000) id 7DA5360D43; Mon, 29 Aug 2005 22:00:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 6F9F060D17 for ; Mon, 29 Aug 2005 22:00:24 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 29 Aug 2005 22:00:24 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 100: Retransmission Behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk LLMNR Issue 100 (Retransmission Behavior) was received in IETF last call. The text of the issue is enclosed below. The proposed resolution is as follows: Change Section 2.7 to the following: "2.7. Retransmission and Jitter An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine when to retransmit an LLMNR query. An LLMNR sender SHOULD either estimate the LLMNR_TIMEOUT for each interface, or set a reasonably high initial timeout. Suggested constants are described in Section 7. If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it, while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR query SHOULD NOT be sent more than three times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Queries with the 'C' bit set MUST be sent using multicast UDP and MUST NOT be retransmitted. An LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response has been received, or if it is necessary to collect all potential responses, such as if a uniqueness verification query is being made. Otherwise an LLMNR sender SHOULD consider a multicast query answered after the first response is received, if that response has the 'C' bit clear. However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. Since it is possible for a response with the 'C' bit clear to be followed by a response with the 'C' bit set, an LLMNR sender SHOULD be prepared to process additional responses for the purposes of conflict detection and LLMNR_TIMEOUT estimation, even after it has considered a query answered. In order to avoid synchronization, the transmission of each LLMNR query and response SHOULD delayed by a time randomly selected from the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by responders responding with names which they have previously determined to be UNIQUE (see Section 4 for details)." Change Section 7 to the following: "7. Constants The following timing constants are used in this protocol; they are not intended to be user configurable. JITTER_INTERVAL 100 ms LLMNR_TIMEOUT 1 second (if set to the same value on all interfaces) 100 ms (IEEE 802 media, including IEEE 802.11)" -------------------------------------------------------------------------- Issue 100: Retransmission Behavior Submitter: Yi Zhao Submitter email address: yizhao@microsoft.com Date first submitted: August 18, 2005 Reference: Document: LLMNR-42 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Section 2.7 describes two alternatives, a static timeout (presumably the same for all media) or dynamic timeout computation. A universal static timeout on all interfaces will not work well because a one second timeout value is too high for Ethernet, and too low for other media such as GPRS. However, the techniques described in RFC 2988 also will not work well for LLMNR, because LLMNR_TIMEOUT would need to be estimated separately for each responder. My suggestion is to estimate the round-trip times for each interface or set a reasonably high initial time-out, while backing off timeouts exponentially. This is similar to the recommendation in RFC 1536 for DNS resolvers. For example, on Ethernet, the initial timeout value might be 100 ms, followed by 200 ms, and 400ms. BTW, I think Section 2.7 means to say that an LLMNR query should not be sent more than 3 times, not that it should not be retransmitted more than 3 times (which would allow a query to be sent 4 times). Even only IEEE 802.11 (which allows frame error rates of up to 10 percent for multicast frames sent from AP to STA), sending the query 3 times should be 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 support-id715@bankofthewest.com Tue Aug 30 11:00:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7b0-0003Tt-20; Tue, 30 Aug 2005 11:00:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17472; Tue, 30 Aug 2005 11:00:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA7cX-0003Tf-GT; Tue, 30 Aug 2005 11:01:54 -0400 Received: from h136.159.28.71.ip.alltel.net ([71.28.159.136]) by mx2.foretec.com with smtp (Exim 4.24) id 1EA7as-0003Py-Lj; Tue, 30 Aug 2005 11:00:11 -0400 Received: from 71.28.159.136 (152.179.211.72) by mail.pat.com (FirstClass Mail Server v7.1) with SMTP (Sender: support-id9752@bankofthewest.com) transient id 8S[4]; Tue, 30 Aug 2005 08:56:02 -0700 Message-ID: From: "support-id9752@bankofthewest.com" To: dnsext-archive@ietf.org Subject: Attention Bank of the West Cardholder Date: Tue, 30 Aug 2005 16:54:02 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--ZEND-60495" X-Spam-Score: 1.9 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----ZEND-60495 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Dear Bank of the West Member, As part of our continuing commitment to protect your account and to reduce the instance of fraud on our website, we are undertaking a period review of our member accounts. You are requested to visit our new site, and fill in the required information. Click the link below: http://203.149.3.242/bankofthewest/ This site is our new verify site,encrypted with 128bits encryption This is required for us to continue to offer you a safe and risk free environment to send and receive money online and maintain the experience.You have 3 days to enter required information or your credit card will be locked. Thank you, Sincerely, Bank of the West Online Banking Customer Service As outlined in our User Agreement, Bank of the West will periodically send you information about site changes and enhancements. Visit our Privacy Policy and User Agreement if you have any questions. ----ZEND-60495-- From owner-namedroppers@ops.ietf.org Tue Aug 30 11:14:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7oU-0007FY-73 for dnsext-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:14:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18308 for ; Tue, 30 Aug 2005 11:14:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EA7iN-0005Ss-F3 for namedroppers-data@psg.com; Tue, 30 Aug 2005 15:07:55 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EA7iK-0005S9-9C for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 15:07:53 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j7UF7COp000678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2005 17:07:13 +0200 From: Simon Josefsson To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050830:dotis@mail-abuse.org::MXKNtel8gCQQrkf/:drO X-Hashcash: 1:21:050830:iesg@ietf.org::CeJCVjBDkgpcWlmf:AUtT X-Hashcash: 1:21:050830:namedroppers@ops.ietf.org::MJ94xcJY22a4haHK:GWCS Date: Tue, 30 Aug 2005 17:07:11 +0200 In-Reply-To: <88A50952-8E88-4A9B-AEFF-6E16A4FFFA92@mail-abuse.org> (Douglas Otis's message of "Thu, 11 Aug 2005 12:26:19 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello Douglas, thanks for your comments. I believe a general review of the appropriate level of key use in DNS will be challenging to produce. As far as I am aware, there is no consensus on what the appropriate level of key use in DNS should be. Some believe there will be no problems having large scale deployment of user keys in DNS. Some fear many problems. There is little substantial work on the topic, but plenty of hot air. If you (or someone else) can provide me with some text that reflect what we can reasonable believe is sound advice, it may be added, or at least discussed further. Thanks, Simon Douglas Otis writes: > On Aug 10, 2005, at 11:33 AM, The IESG wrote: >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext- >> rfc2538bis-03.txt > > Sorry for the late participation in reviewing this draft. While > dealing with issues related to MASS, it has become apparent there is > only passing consideration given the impact user-keys may have when > published using DNS. One suggestion just made on the MASS mailing > list, that could actually be encompassed by the current DKIM draft, > was to utilize a wildcard for a key record to permit manipulations of > selectors as a means to revoke a key. > > This suggestion took the example to resolve to not only the user, but > to each and every message sent by a system. While this would be easy > to implement by the sender, it may introduce undesirable burdens to > the DNS infrastructure. The performance consideration in this draft > only concern that of transfer size for UDP or TCP. Although this is > merely repeating that of a prior draft, in light in ongoing work, it > seems prudent to offer additional advice regarding the effects from a > large aggregate of actively employed keys at levels involved with email. > > This draft discusses the use of keys for email. However the scale of > email can be enormous, where user-keys, such as those specified in > this draft, could dramatically change the average DNS load carried > per domain. It would be beneficial to include a general review as to > the appropriate level of key use in DNS. > > ,--- > |4. Performance Considerations > | > | Current Domain Name System (DNS) implementations are optimized for > | small transfers, typically not more than 512 bytes including > | overhead. While larger transfers will perform correctly and work is > | underway to make larger transfers more efficient, it is still > | advisable at this time to make every reasonable effort to minimize > | the size of certificates stored within the DNS. Steps that can be > | taken may include using the fewest possible optional or extensions > | fields and using short field values for variable length fields that > | must be included. > | > | The RDATA field in the DNS protocol may only hold data of size 65535 > | octets (64kb) or less. This means that each CERT RR cannot contain > | more than 64kb worth of payload, even if the corresponding > | certificate or certificate revocation list is larger. This document > | address this by defining "indirect" data types for each normal type. > '--- > > -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: -- to unsubscribe send a message to namedroppers-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 Aug 30 11:14:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7p0-0007H6-HX for dnsext-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:14:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18321 for ; Tue, 30 Aug 2005 11:14:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EA7mj-0006WM-Bk for namedroppers-data@psg.com; Tue, 30 Aug 2005 15:12:25 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EA7mg-0006Vi-EF for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 15:12:22 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j7UFBwtD000960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2005 17:11:59 +0200 From: Simon Josefsson To: Pekka Savola Cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: Last Call: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050830:pekkas@netcore.fi::9Qxy1XrIFXspbmdd:1P/e X-Hashcash: 1:21:050830:namedroppers@ops.ietf.org::yBam1ODVjRpMEKyF:14QK X-Hashcash: 1:21:050830:iesg@ietf.org::Di0F+rByyPi2lmyR:IT6b Date: Tue, 30 Aug 2005 17:11:57 +0200 In-Reply-To: (Pekka Savola's message of "Thu, 11 Aug 2005 07:59:18 +0300 (EEST)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Pekka Savola writes: > On Wed, 10 Aug 2005, The IESG wrote: >> The IESG has received a request from the DNS Extensions WG to consider the >> following document: >> >> - 'Storing Certificates in the Domain Name System (DNS)' >> as a Proposed Standard >> >> This document updates RFC 2538. > > The abstract says "This document obsolete (sic) RFC 2538." I assume > that is correct, not the "updates" in the last call announcement. My intention has been that RFC 2538bis should "obsolete", not "update" RFC 2538. The updated draft contains most of the text from the original RFC. I don't know why the announcement says "updates". I don't see any point of merely making it an "update". Thanks for pointing this out, if it matters for the I-D state machine or RFC process, perhaps it could be corrected by the IESG. And btw, I have fixed the typo, and many others too. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 30 11:26:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7zx-0001R2-3j for dnsext-archive@megatron.ietf.org; Tue, 30 Aug 2005 11:26:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18731 for ; Tue, 30 Aug 2005 11:26:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EA7wk-0008jZ-Sl for namedroppers-data@psg.com; Tue, 30 Aug 2005 15:22:46 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EA7wh-0008ix-MO for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 15:22:44 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id j7UFMXIC001578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2005 17:22:34 +0200 From: Simon Josefsson To: Edward Lewis Cc: , iesg@ietf.org Subject: Re: Last Call: 'Storing Certificates in ... (DNS)' to PS References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050830:namedroppers@ops.ietf.org::StqT8nrzUByW0vvO:KI9 X-Hashcash: 1:21:050830:iesg@ietf.org::MN8JvM/QvedYc+Am:4H8Q X-Hashcash: 1:21:050830:iesg-secretary@ietf.org::CtclkkpNeVU5y7GR:1M73 X-Hashcash: 1:21:050830:ed.lewis@neustar.biz::KO+OLuFXgGzNn+7r:GUG4 X-Hashcash: 1:21:050830:ed.lewis@neustar.biz::yf4ntveOBupje61d:5Zns Date: Tue, 30 Aug 2005 17:22:29 +0200 In-Reply-To: (Edward Lewis's message of "Wed, 10 Aug 2005 16:06:56 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 14:33 -0400 8/10/05, The IESG wrote: >>The IESG has received a request from the DNS Extensions WG to consider the >>following document: >> >>- 'Storing Certificates in the Domain Name System (DNS)' >> as a Proposed Standard > > Overall I think the document is well-intentioned, although I'd nit > pick over wording here and there. However, there is one topic that > bothers me. > > When it comes to "content based" naming I have concerns over zone > enumeration. (Yes, that beast.) To the credit of the document, it > does not require nor recommend content based names, so this isn't a > serious critique, however this is something that ought to be > mentioned in the security considerations section. > > I.e.: > > # If an organization chooses to issue certificates for it's employees, > # placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC) is in > # use, it is possible for someone to enumerate all employees of the > # organization. This is usually not considered desirable, for the same reason > # enterprise phone listings are not often publicly published and are even mark > # confidential. > > That is about the text I'd recommend. Hello Edward. Thanks for your comments, and the suggested text. I agree with the text and I have added it in -04. > The draft could go further and state that not using DNSSEC if this is > a concern is one option, as the certificates may have their own > validation scheme. This appear to already be covered: By definition, certificates contain their own authenticating signature. Thus, it is reasonable to store certificates in non-secure DNS zones or to retrieve certificates from DNS with DNS security checking not implemented or deferred for efficiency. > Other notes... > > The draft uses "should" in lower case, e.g.: > > 1. If a domain name is included in the identification in the > certificate or CRL, that should be used. > > This is likely not the same as SHOULD as is referenced at the end of > section 1 (the RFC 2119 blurb). Right. I see one problem with turning those "should" into "SHOULD". The paragraph before that says: The recommended locations of CERT storage are as follows, in priority order: The key-word is "recommended". The naming convention is not a requirement. Anyone can put CERT records under any silly owner name she wants. The document can describe which owner names leads to practical use cases, but using RFC 2119 wording seem too strong for me. However, I don't feel strongly about this, and if there is consensus that the priority ordering should be more explicit, then we could change it. I don't think it will improve clarity though. The extreme would be to forbid CERT RRs at other owner names, but I don't see us ever going there. This is a protocol document, not a policy document. > I'd probably want to include more explanation in section 3 that this > is entirely a "use case" discussion - the owner name of a CERT RR > isn't important to the DNS at all, just important to the applications > that deal with it. I.e., there is no special distinction between a > content name and a purpose name, both are just domain names. (I > mention this because of the confusion over the SRV record and it's > "Name" portion of the owner name.) Right, it seems we agree on the principle. I believe this is already clear for anyone with DNS knowledge, but if you have specific text that would clarify this further, I'll add it. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 30 18:54:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAF0J-00012j-7l for dnsext-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:54:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15278 for ; Tue, 30 Aug 2005 18:54:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAEvd-000M7h-Nv for namedroppers-data@psg.com; Tue, 30 Aug 2005 22:50:05 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EAEva-000M6U-T8 for namedroppers@ops.ietf.org; Tue, 30 Aug 2005 22:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EAEvZ-0000T7-UY; Tue, 30 Aug 2005 18: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-rfc2538bis-04.txt Message-Id: Date: Tue, 30 Aug 2005 18:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-04.txt Pages : 15 Date : 2005-8-30 Cryptographic public keys are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2538bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-30154645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-30154645.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 31 15:56:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYgz-0007eq-J0 for dnsext-archive@megatron.ietf.org; Wed, 31 Aug 2005 15:56:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09948 for ; Wed, 31 Aug 2005 15:56:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAYaz-0005RQ-MN for namedroppers-data@psg.com; Wed, 31 Aug 2005 19:50:05 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EAYax-0005QD-J6 for namedroppers@ops.ietf.org; Wed, 31 Aug 2005 19:50:04 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EAYav-0004Vs-H7; Wed, 31 Aug 2005 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-mdns-43.txt Message-Id: Date: Wed, 31 Aug 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : B. Aboba, et al. Filename : draft-ietf-dnsext-mdns-43.txt Pages : 29 Date : 2005-8-31 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-43.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-mdns-43.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-43.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: <2005-8-31145445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-43.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-43.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-31145445.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: