From marc.lampo@eurid.eu Mon Apr 2 04:53:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7784621F8883 for ; Mon, 2 Apr 2012 04:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VScOurJGFCth for ; Mon, 2 Apr 2012 04:53:45 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id F1ADE21F887E for ; Mon, 2 Apr 2012 04:53:44 -0700 (PDT) X-ASG-Debug-ID: 1333368058-0369490e9a82120001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id XNOLivA7nT3ulHEb for ; Mon, 02 Apr 2012 14:00:58 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 77016E4073 for ; Mon, 2 Apr 2012 13:53:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc4DOUUc9Nob for ; Mon, 2 Apr 2012 13:53:40 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 6693FE4059 for ; Mon, 2 Apr 2012 13:53:40 +0200 (CEST) From: "Marc Lampo" To: Date: Mon, 2 Apr 2012 13:53:40 +0200 (CEST) X-ASG-Orig-Subj: long / short TTL Message-ID: <0c0901cd10c7$3eafd720$bc0f8560$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0Qxz5p1l4WximAS+GgJlBU/JDuiA== Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1333368058 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: [DNSOP] long / short TTL X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:53:45 -0000 Hello, Following up on last week's DNSOP gathering in Paris, where one contribution pleaded for long TTL's (on infrastructure records) and another for short TTL's. >From the humming results I interpret that consensus will be hard to reach. Would it be an idea to spend some words on the theme in RFC4641bis ? (there is already wording in that draft, linking short TTL to applying corrections) As that document does not "give strong recommendations", but mostly "guidelines" (quoted from the Introduction of that draft), no "consensus" is needed and guidelines can refer to security aspect. However : the authors of the draft on long TTL's showed data on a large set of domains, over a period of time; regarding changes to NS records. Since they can already provide a table with % of changes over a period of time, can you also provide data on TTL of "about to be changed records" ? In other words : For those domains where a NS change was noticed, do you also have data on TTL values of the records, prior to the change ? (I assume most did not reduce the TTL of the old data) --> I remember a statement of 75% that did not change NS records. Leaving 25% that did change. If the change was not preceded by a lowering of TTL before the change, that 25% is the percentage of domains that will be *negatively* affected by large TTL's on infrastructure RR's ! Kind regards, Marc Lampo Security Officer EURid (for .eu) From matthijs@nlnetlabs.nl Mon Apr 2 07:34:43 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3268121F8575 for ; Mon, 2 Apr 2012 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEISIgTucKTI for ; Mon, 2 Apr 2012 07:34:42 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0021F857D for ; Mon, 2 Apr 2012 07:34:41 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q32EWmKP021561; Mon, 2 Apr 2012 16:32:49 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1333377170; bh=fh99QvPQ1TXT32qZczms+Zth2SwCAW/lzyic+H81gpU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=obo6TzCrMOzxA+CUOurgbNKyw69G0zAsaFqYMaWSjqRmOBCz/w47q/MdV9rYZWuaO ikHxXcnJCyf0C9riTMGPo1grPaUVDtjgb8IK7iBbBzRrtvcKqQZIXShy6DO1Bumri4 pZk2IiSdlsdReUSKJ6rVTW/Y/bIKmjYRk9lmf9nQ= Message-ID: <4F79B890.7060503@nlnetlabs.nl> Date: Mon, 02 Apr 2012 16:32:48 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Lampo References: <0c0901cd10c7$3eafd720$bc0f8560$@lampo@eurid.eu> In-Reply-To: <0c0901cd10c7$3eafd720$bc0f8560$@lampo@eurid.eu> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 02 Apr 2012 16:32:49 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] long / short TTL X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:34:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marc, As you said, there is already text in 4641bis on this subject. There is text that provides guidelines on TTLs for DS records: ..., there is the TTL value on the DS RRs. Shortening the TTL reduces the damage of a successful replay attack. It does mean that the authoritative servers will see more queries. But on the other hand, a short TTL lowers the persistence of DS RRsets in caches thereby increasing the speed with which updated DS RRsets propagate through the DNS. And section 4.4.1 covers many time considerations. Although not explicitly about NS RRset, imho they do cover all the considerations related to DNSSEC operational practices. So to be clear, I don't think the document needs to address this topic to more extent. Best regards, Matthijs On 04/02/2012 01:53 PM, Marc Lampo wrote: > Hello, > > Following up on last week's DNSOP gathering in Paris, where one > contribution pleaded for long TTL's (on infrastructure records) and > another for short TTL's. > >> From the humming results I interpret that consensus will be hard >> to reach. > Would it be an idea to spend some words on the theme in RFC4641bis > ? (there is already wording in that draft, linking short TTL to > applying corrections) As that document does not "give strong > recommendations", but mostly "guidelines" (quoted from the > Introduction of that draft), no "consensus" is needed and > guidelines can refer to security aspect. > > However : the authors of the draft on long TTL's showed data on a > large set of domains, over a period of time; regarding changes to > NS records. Since they can already provide a table with % of > changes over a period of time, can you also provide data on TTL of > "about to be changed records" ? In other words : For those domains > where a NS change was noticed, do you also have data on TTL values > of the records, prior to the change ? (I assume most did not reduce > the TTL of the old data) --> I remember a statement of 75% that did > not change NS records. Leaving 25% that did change. If the change > was not preceded by a lowering of TTL before the change, that 25% > is the percentage of domains that will be *negatively* affected by > large TTL's on infrastructure RR's ! > > > Kind regards, > > > Marc Lampo Security Officer EURid (for .eu) > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPebiQAAoJEA8yVCPsQCW5uJYIAJIepLp5HokBhOLXYWu3317w c9LZz+G7uFEK+rjihoUAH4qB3VoCTALlWL43BFkjuCq/kc+7lsTZCsh5U4mCrpRL X3cypOeVL3QKvtpIMBTEsCuuMqD2swqu99wOF4zXZqqNLc5BzFL020Ok/37cyI1V XYoL64xuh0m+0D2/AihKDdHftmCgzEBEcrjUpzX/lYGZH3hQEvypbIyKt1XwMBEB SA5JUzQL5Z3xnxc5+15ACzrUKuu0MM12gthLutgLtr3JSVy86kx3eoAh6oBsm2EG MtZ2ZK5RPKV1Mwf+8krNIiqu39QsojvIwhUBd9dH9wFkmH/lfTJMA0dVWsUaDmA= =PXB3 -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Mon Apr 2 07:35:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404AC21F8592 for ; Mon, 2 Apr 2012 07:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bolRHosuF1WU for ; Mon, 2 Apr 2012 07:35:54 -0700 (PDT) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB4021F857D for ; Mon, 2 Apr 2012 07:35:54 -0700 (PDT) X-ASG-Debug-ID: 1333377352-02dadd06672b6dd0001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id nwg0rnElFU4FE3K6 for ; Mon, 02 Apr 2012 16:35:52 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id D48FEE408C for ; Mon, 2 Apr 2012 16:35:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEGXGX70pwmD for ; Mon, 2 Apr 2012 16:35:52 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id C2839E407A for ; Mon, 2 Apr 2012 16:35:52 +0200 (CEST) From: "Marc Lampo" To: References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> In-Reply-To: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> Date: Mon, 2 Apr 2012 16:35:52 +0200 (CEST) X-ASG-Orig-Subj: RE: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Message-ID: <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0OWJE56uv4PcqqQASBdlSu0TFagQCfPf3g Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1333377352 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:35:55 -0000 Hello to the list, Nice piece of work ! Some remarks - nothing spectacular : 1) Last sentence in the first paragraph - Introduction (about : "no direct relation between ... and validating caching name servers.") Isn't this sentence superfluous ? I fail to see where a possible relation would indeed change something to these guidelines. But by including the sentence about no relationship, one starts to wonder if something escapes me ... 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states there are three steps. I think this is an error : There are three states, yes; but there are only two manipulations to perform. (to me it seems logical to interpret "step" as : "operation to perform") 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security Lameness (actually, 4.1.3 introduces another way of KSK rollover. In that respect the title of the section is confusing !) In 4.1.3 the text suggest to publish a DS record in the parent for which there is no DNSKEY record in the child zone. In 4.3.3 the text suggest the parent could verify that the DNSKEY is actually published by the child. --> 4.3.3 could explicitly state that, if a parent performs this kind of checking, then the "double DS method" of 4.1.3 is not possible. Furthermore : as registry (for .eu) we think that it is important to assist our registrars in setting DNSSEC up correctly. Consequently, we do verification when a registrar sends us DNSSEC information. So we cannot distinguish between a DNS Operator that performs double DS KSK rollover and an operator making a mistake ... 4) 4.3.4 DS Signature Validity Period The last paragraph holds a sentence that states : "Shortening the TTL reduces the damage of a successful replay attack." I don't think this is correct (or relevant). For me, the chances for a replay attack increase with the signature validity period, not with the value of the TTL. The value of the paragraph lays, for me, in the propagation of updated DS RRsets (cfr the presentation on low TTL's, last week). 5) 4.4.2.1 Maximum value (for Signature Validation Period) I think this paragraph should make a reference to Key Rollover ! Motivation : no matter how long a signature is valid, in order for it to be used, the corresponding Key must be available. (so : if the reason for long RRSIG validity is not to recalculate them, then ...) I do admit that none of the Key Rollover scenario's take into account the signature validity time (but the TTL). And indeed, nothing prevents to generate a signature, valid for 1 year, with TTL of 1 day, and perform key rollover every three months : the still valid signature simply times out of the cache, to be replaced by a new one, valid for a new year. Kind regards, Marc Lampo EURid (for .eu) -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 AM To: i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename : draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date : 2012-03-30 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt From fanf2@hermes.cam.ac.uk Mon Apr 2 09:13:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10221F8646 for ; Mon, 2 Apr 2012 09:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-9nkAG2w23T for ; Mon, 2 Apr 2012 09:13:32 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC321F86DB for ; Mon, 2 Apr 2012 09:13:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54109) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SEjsi-00029q-QJ (Exim 4.72) (return-path ); Mon, 02 Apr 2012 17:13:24 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SEjsi-0006em-3m (Exim 4.67) (return-path ); Mon, 02 Apr 2012 17:13:24 +0100 Date: Mon, 2 Apr 2012 17:13:24 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Alfred H?nes In-Reply-To: <201203292310.BAA21224@TR-Sys.de> Message-ID: References: <201203292310.BAA21224@TR-Sys.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Sender: Tony Finch Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:13:33 -0000 Alfred H?nes wrote: > Is there a clear summary somewhere of why multiple concurrent queries do not satisfy this requirement? A slightly irrelevant pedantic correction: > The distinguishing idea was to build in some kind of integrity of > RRsets using feedback signaling that allows to indicate empty RRsets > ("nodata" indication per RRtype); caches that do not "know" the > entire RRset of an RRtype asked for do not send a partial RRset > but indicate that the response does not answer for such RRtype. Partial RRsets are never allowed. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle, Faeroes: North or northeast 5 to 7, occasionally 4 at first, perhaps gale 8 later in Fair Isle. Rough or very rough. Snow then snow showers. Good, occasionally very poor. From matthijs@nlnetlabs.nl Tue Apr 3 01:38:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B71021F8528 for ; Tue, 3 Apr 2012 01:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM3xAsEAE5Mr for ; Tue, 3 Apr 2012 01:38:08 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F21121F8523 for ; Tue, 3 Apr 2012 01:38:05 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q338aGe2005208; Tue, 3 Apr 2012 10:36:16 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1333442177; bh=3hvxatNgBGyzNQBw/+3RoDLZ80o6+7fzTgPDA6NsSwg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xXCkhRE0cnHWeq1AZraYdqza6NdsTm36RO7PHQHUB0SAfGpARpAa2PlgQr2+8fLi8 JZvfLzfofzYau3/snjfdDBNiC4KWC6kaFyEyZ7lf0IpBzyxy2NwR984YqQBezBNoF3 vYdf5qXa/xVPfXV/kj+2ssVZwSASVNXCwdqsLmaQ= Message-ID: <4F7AB67F.6020603@nlnetlabs.nl> Date: Tue, 03 Apr 2012 10:36:15 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Lampo References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> In-Reply-To: <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 03 Apr 2012 10:36:16 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:38:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 04/02/2012 04:35 PM, Marc Lampo wrote: > Hello to the list, > > Nice piece of work ! > > Some remarks - nothing spectacular : 1) Last sentence in the first > paragraph - Introduction (about : "no direct relation between ... > and validating caching name servers.") > > Isn't this sentence superfluous ? I fail to see where a possible > relation would indeed change something to these guidelines. > > But by including the sentence about no relationship, one starts to > wonder if something escapes me ... The document just tries to make it very clear that it is targeted to the authoritative side of the DNS equation. > > 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence > states there are three steps. I think this is an error : There are > three states, yes; but there are only two manipulations to > perform. (to me it seems logical to interpret "step" as : > "operation to perform") Sure. More important is the fact that it is one step/stage shorter than Pre-publish ZSK rollover. > 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security > Lameness > > (actually, 4.1.3 introduces another way of KSK rollover. In that > respect the title of the section is confusing !) > > In 4.1.3 the text suggest to publish a DS record in the parent for > which there is no DNSKEY record in the child zone. It suggests to publish a DS record for which there is no *corresponding* DNSKEY record in the child zone, next to an existing chain of trust between parent and child. That is different from "no DNSKEY record in the child zone". > In 4.3.3 the text suggest the parent could verify that the DNSKEY > is actually published by the child. > > --> 4.3.3 could explicitly state that, if a parent performs this > kind of checking, then the "double DS method" of 4.1.3 is not > possible. There is already a forward reference in section 4.1.3 to 4.3.3. > Furthermore : as registry (for .eu) we think that it is important > to assist our registrars in setting DNSSEC up correctly. > Consequently, we do verification when a registrar sends us DNSSEC > information. So we cannot distinguish between a DNS Operator that > performs double DS KSK rollover and an operator making a mistake > ... I think you might have a false negative there: If a DNS operator requests for a second DS to be published, it does not break the chain of trust. Why classify it as a mistake? Double-DS rollover is perfectly acceptable within the boundaries of DNSSEC. > 4) 4.3.4 DS Signature Validity Period The last paragraph holds a > sentence that states : "Shortening the TTL reduces the damage of a > successful replay attack." > > I don't think this is correct (or relevant). For me, the chances > for a replay attack increase with the signature validity period, > not with the value of the TTL. The value of the paragraph lays, for > me, in the propagation of updated DS RRsets (cfr the presentation > on low TTL's, last week). You are right that the chances for a replay attack increase with the validity period, but the damage depends on how long that data will be in the cache. That depends on TTL. > 5) 4.4.2.1 Maximum value (for Signature Validation Period) > > I think this paragraph should make a reference to Key Rollover ! > Motivation : no matter how long a signature is valid, in order for > it to be used, the corresponding Key must be available. (so : if > the reason for long RRSIG validity is not to recalculate them, then > ...) > > I do admit that none of the Key Rollover scenario's take into > account the signature validity time (but the TTL). And indeed, > nothing prevents to generate a signature, valid for 1 year, with > TTL of 1 day, and perform key rollover every three months : the > still valid signature simply times out of the cache, to be replaced > by a new one, valid for a new year. Hence, I don't think this paragraph should make a reference to key rollover. Best regards, Matthijs > > Kind regards, > > Marc Lampo EURid (for .eu) > > > -----Original Message----- From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 AM To: > i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] I-D > Action: draft-ietf-dnsop-rfc4641bis-10.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Domain Name System > Operations Working Group of the IETF. > > Title : DNSSEC Operational Practices, Version 2 Author(s) > : Olaf M. Kolkman W. (Matthijs) Mekking Filename : > draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date > : 2012-03-30 > > This document describes a set of practices for operating the DNS > with security extensions (DNSSEC). The target audience is zone > administrators deploying DNSSEC. > > The document discusses operational aspects of using keys and > signatures in the DNS. It discusses issues of key generation, key > storage, signature generation, key rollover, and related policies. > > This document obsoletes RFC 4641 as it covers more operational > ground and gives more up-to-date requirements with respect to key > sizes and the DNSSEC operations. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > > > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPerZ/AAoJEA8yVCPsQCW5m6AH/R9rFXjaAtHZLxIO7F1gC4rE 5AxO7ahIrzb1O7nNJhsAJ1HgTh1ViaOBPMlaU9UaCOKuvQ0jPJfD/aP/5WFFUz7Q DY0xeCCeQG0YO7NM1Z1O59DYXGsvvo2lkkDIPkITJG5G7hQJ+K7s/r+BF8tvQbtF Zzbcr3ZAG5jMyArrkGAogJUSZbQqc95pgYHzaeIxIiLZ4GuckrzDHraR4dke9DbW vK8GFmZFEjmhxrMH3kR/BQx5sHGj9pgQccoAIrNuWbJ8yT5HgtTD5kIh0IbE+RUG bPRPdF3G6A84U6szMnibB2SWchfiBdj0ncMMbeJQQ42miNlJsLJ0D505WlLECXQ= =0PCG -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Tue Apr 3 02:11:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCFB21F84D3 for ; Tue, 3 Apr 2012 02:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT7D5RqMYRJm for ; Tue, 3 Apr 2012 02:11:54 -0700 (PDT) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id DC93121F84CF for ; Tue, 3 Apr 2012 02:11:53 -0700 (PDT) X-ASG-Debug-ID: 1333444311-02dadd06672b97e0001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id GF7NDvkEFpukNLeM; Tue, 03 Apr 2012 11:11:51 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 928C0E4065; Tue, 3 Apr 2012 11:11:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5IjBJ-t9fxz; Tue, 3 Apr 2012 11:11:51 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 6F780E4050; Tue, 3 Apr 2012 11:11:51 +0200 (CEST) From: "Marc Lampo" To: "'Matthijs Mekking'" References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> <4F7AB67F.6020603@nlnetlabs.nl> In-Reply-To: <4F7AB67F.6020603@nlnetlabs.nl> Date: Tue, 3 Apr 2012 11:11:51 +0200 (CEST) X-ASG-Orig-Subj: RE: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Message-ID: <008501cd1179$ce4cd830$6ae68890$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0RdRXo+uON3PZUTTWrX5F0Crt32wAAhBpw Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1333444311 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:11:55 -0000 Hello again, About 1) If the document is for the authoritative side, why not simply state so. Instead of this confusing statement about relationship between authoritative and validating NS's ? About 2) So it is "two" steps ? About 3) I forgot the word "corresponding", my fault there. As such the text is not wrong, please don't misunderstand me. But the parent the only way, for a parent, to known/verify that DS information is correct, is by querying for the DNSKEY RRset and check if the corresponding ( ;-) DNSKEY is indeed present. If it is not, there is no way the parent can distinguish between a child zone administrator performing a double-DS rollover or making an error ... About 4) I can agree with the present text. About 5) Me too, I think published signatures should never be expired. Consequently, every key rollover will make signatures disappear that are, as such, not expired yet. >From that point of view it makes little difference if signature validity period is a couple of weeks or months or years. But if the zone administrator uses long validity time with the intention not to recalculate regularly, this implies that the ZSK cannot rollover either. (and this is practice - out there, right now ! There is one TLD that has signatures valid till "the end of the current year", and never did any key rollover since it started with DNSSEC) To conclude : I can "just" agree with the present text. Kind regards, Marc Lampo EURid (for .eu) -----Original Message----- From: Matthijs Mekking [mailto:matthijs@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 04/02/2012 04:35 PM, Marc Lampo wrote: > Hello to the list, > > Nice piece of work ! > > Some remarks - nothing spectacular : 1) Last sentence in the first > paragraph - Introduction (about : "no direct relation between ... > and validating caching name servers.") > > Isn't this sentence superfluous ? I fail to see where a possible > relation would indeed change something to these guidelines. > > But by including the sentence about no relationship, one starts to > wonder if something escapes me ... The document just tries to make it very clear that it is targeted to the authoritative side of the DNS equation. > > 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states > there are three steps. I think this is an error : There are three > states, yes; but there are only two manipulations to perform. (to me > it seems logical to interpret "step" as : > "operation to perform") Sure. More important is the fact that it is one step/stage shorter than Pre-publish ZSK rollover. > 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security > Lameness > > (actually, 4.1.3 introduces another way of KSK rollover. In that > respect the title of the section is confusing !) > > In 4.1.3 the text suggest to publish a DS record in the parent for > which there is no DNSKEY record in the child zone. It suggests to publish a DS record for which there is no *corresponding* DNSKEY record in the child zone, next to an existing chain of trust between parent and child. That is different from "no DNSKEY record in the child zone". > In 4.3.3 the text suggest the parent could verify that the DNSKEY is > actually published by the child. > > --> 4.3.3 could explicitly state that, if a parent performs this > kind of checking, then the "double DS method" of 4.1.3 is not > possible. There is already a forward reference in section 4.1.3 to 4.3.3. > Furthermore : as registry (for .eu) we think that it is important to > assist our registrars in setting DNSSEC up correctly. > Consequently, we do verification when a registrar sends us DNSSEC > information. So we cannot distinguish between a DNS Operator that > performs double DS KSK rollover and an operator making a mistake ... I think you might have a false negative there: If a DNS operator requests for a second DS to be published, it does not break the chain of trust. Why classify it as a mistake? Double-DS rollover is perfectly acceptable within the boundaries of DNSSEC. > 4) 4.3.4 DS Signature Validity Period The last paragraph holds a > sentence that states : "Shortening the TTL reduces the damage of a > successful replay attack." > > I don't think this is correct (or relevant). For me, the chances for a > replay attack increase with the signature validity period, not with > the value of the TTL. The value of the paragraph lays, for me, in the > propagation of updated DS RRsets (cfr the presentation on low TTL's, > last week). You are right that the chances for a replay attack increase with the validity period, but the damage depends on how long that data will be in the cache. That depends on TTL. > 5) 4.4.2.1 Maximum value (for Signature Validation Period) > > I think this paragraph should make a reference to Key Rollover ! > Motivation : no matter how long a signature is valid, in order for it > to be used, the corresponding Key must be available. (so : if the > reason for long RRSIG validity is not to recalculate them, then > ...) > > I do admit that none of the Key Rollover scenario's take into account > the signature validity time (but the TTL). And indeed, nothing > prevents to generate a signature, valid for 1 year, with TTL of 1 day, > and perform key rollover every three months : the still valid > signature simply times out of the cache, to be replaced by a new one, > valid for a new year. Hence, I don't think this paragraph should make a reference to key rollover. Best regards, Matthijs > > Kind regards, > > Marc Lampo EURid (for .eu) > > > -----Original Message----- From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 AM To: > i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] I-D > Action: draft-ietf-dnsop-rfc4641bis-10.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Domain Name System > Operations Working Group of the IETF. > > Title : DNSSEC Operational Practices, Version 2 Author(s) > : Olaf M. Kolkman W. (Matthijs) Mekking Filename : > draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date > : 2012-03-30 > > This document describes a set of practices for operating the DNS with > security extensions (DNSSEC). The target audience is zone > administrators deploying DNSSEC. > > The document discusses operational aspects of using keys and > signatures in the DNS. It discusses issues of key generation, key > storage, signature generation, key rollover, and related policies. > > This document obsoletes RFC 4641 as it covers more operational ground > and gives more up-to-date requirements with respect to key sizes and > the DNSSEC operations. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > > > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPerZ/AAoJEA8yVCPsQCW5m6AH/R9rFXjaAtHZLxIO7F1gC4rE 5AxO7ahIrzb1O7nNJhsAJ1HgTh1ViaOBPMlaU9UaCOKuvQ0jPJfD/aP/5WFFUz7Q DY0xeCCeQG0YO7NM1Z1O59DYXGsvvo2lkkDIPkITJG5G7hQJ+K7s/r+BF8tvQbtF Zzbcr3ZAG5jMyArrkGAogJUSZbQqc95pgYHzaeIxIiLZ4GuckrzDHraR4dke9DbW vK8GFmZFEjmhxrMH3kR/BQx5sHGj9pgQccoAIrNuWbJ8yT5HgtTD5kIh0IbE+RUG bPRPdF3G6A84U6szMnibB2SWchfiBdj0ncMMbeJQQ42miNlJsLJ0D505WlLECXQ= =0PCG -----END PGP SIGNATURE----- From wmaton@ryouko.imsb.nrc.ca Wed Apr 4 05:20:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45B421F8633 for ; Wed, 4 Apr 2012 05:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgjLQdvqbOD7 for ; Wed, 4 Apr 2012 05:20:40 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 28BC121F84DC for ; Wed, 4 Apr 2012 05:20:40 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.5/8.14.4) with ESMTP id q34CKYOn001393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 08:20:39 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.5/8.14.4/Submit) with ESMTP id q34CKYqR001390 for ; Wed, 4 Apr 2012 08:20:34 -0400 Date: Wed, 4 Apr 2012 08:20:34 -0400 (EDT) From: "William F. Maton Sotomayor" To: dnsop@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:20:40 -0000 All, It seems that after delivering my presentation on subsequent AS112 delegations in Quebec City, I hadn't recalled what the group thought about adopting this work as a dnsop item. So, I'm soliciting feedback on this request. I have posted version 03 for your consideration. Thanks, wfms From joe.abley@icann.org Wed Apr 4 05:41:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13C21F852E for ; Wed, 4 Apr 2012 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.98 X-Spam-Level: X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i57NB+hl6Fh for ; Wed, 4 Apr 2012 05:41:26 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8373521F8522 for ; Wed, 4 Apr 2012 05:41:26 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 4 Apr 2012 05:41:26 -0700 From: Joe Abley To: "wmaton@ryouko.imsb.nrc.ca" Date: Wed, 4 Apr 2012 05:41:24 -0700 Thread-Topic: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item Thread-Index: Ac0SYD/6iREDU94aQ3iiKbZkVTWSag== Message-ID: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:41:27 -0000 On 2012-04-04, at 08:20, William F. Maton Sotomayor wrote: > It seems that after delivering my presentation on subsequent AS112=20 > delegations in Quebec City, I hadn't recalled what the group thought abou= t=20 > adopting this work as a dnsop item. So, I'm soliciting feedback on this=20 > request. I have posted version 03 for your consideration. I think that we need a better mechanism to avoid lame delegations to the AS= 112 servers, given their loosely-coordinated nature. The add/drop problem f= or those servers (the difficulty in requesting zone changes across from a p= otentially wide and unknown population of server administrators, and being = effectively unable to measure whether those changes are complete) is a fund= amental weakness in the 112 project as it is operated today. I like the idea that came up in Qu=E9bec (which I shall attribute to Warren= Kumari since I've seen other people do that, although I was not in the roo= m at the time) that the add/drop problem is a lot simpler if every AS112 no= de hosts the zone $ORIGIN . @ SOA ... NS something NS sensible and answers authoritatively on the addresses corresponding to "something" a= nd "sensible", returning NXDOMAIN for everything in the entire namespace ap= art from . (for which they ought never receive queries anyway). This is ugl= y to some eyes, but it works for domainers and it ought to work for us too.= Any zones that were subsequently delegated to "something" and "sensible" (= e.g. as part of an IANA action) would be immediately supported with no need= for changes on any of the nodes offering service for "something" and "sens= ible". Given the installed base of AS112 servers, and again given their loosely-co= ordinated nature, I would suggest assigning one new IPv4 /24 and one new IP= v6 /48 prefix, with both "something" and "special" getting one address out = of each. We could then encourage AS112 operators to host the empty root zon= e on nameserver listening to the appropriate addresses, originating the new= prefixes from AS 112, using the mailing list and associated resources main= ly managed by William. Once by some measure the new prefixes are propagating and nameservers are a= nswering, we could redelegate the zones currently delegated to blackhole-1.= iana.org and blackhole-2.iana.org to the new servers, and retire 192.175.48= .0/24. I think renumbering is worthwhile since we have no way of measuring the ext= ent to which AS112 servers are actually deployed (e.g. there may be many de= ployed for private use inside ASes that we can't easily see.) Enough public= AS112 server operators are responsive on William's list that I don't see a= problem in getting sufficient buy-in to a new scheme such as this to make = it viable quickly, however. I think the work to be done in dnsop could be summarised as: - update RFC 6304 and 6305 as necessary - write something that cleans up and unifies the various registries that c= urrently contain RFC 6303-like names, with appropriate IANA actions (ipv4-c= ull contains some references in section 2, see also draft-cheshire-dnsext-s= pecial-names)=20 - write something that provides guidance for future document authors on wh= en they should specify an IANA action to add a new zone to the grand unifie= d as112 registry and cause a delegation to "something" and "sensible" to ha= ppen. This document (as112-cull) attempts to do some of this work, but I don't se= e a reason to bite off small mouthfuls if we can expend a small amount of e= xtra effort and eat the whole sandwich at once. I am very happy to spend time on this. Joe= From paul@redbarn.org Wed Apr 4 07:53:57 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532521F8672 for ; Wed, 4 Apr 2012 07:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia8OZ-RMF4V1 for ; Wed, 4 Apr 2012 07:53:57 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 08E7021F866D for ; Wed, 4 Apr 2012 07:53:56 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:34b7:444e:bd84:ecf1] (unknown [IPv6:2001:559:8000:cb:34b7:444e:bd84:ecf1]) by ss.vix.com (Postfix) with ESMTP id C02D0EBC8D; Wed, 4 Apr 2012 14:53:55 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F7C6082.1030004@redbarn.org> Date: Wed, 04 Apr 2012 14:53:54 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: wmaton@ryouko.imsb.nrc.ca References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:53:57 -0000 On 2012-04-04 12:20 PM, William F. Maton Sotomayor wrote: > > It seems that after delivering my presentation on subsequent AS112 > delegations in Quebec City, I hadn't recalled what the group thought > about adopting this work as a dnsop item. So, I'm soliciting feedback > on this request. I have posted version 03 for your consideration. i think it should be adopted, but i have no time to work on it, so my vote may not count. From fanf2@hermes.cam.ac.uk Wed Apr 4 08:31:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088D821F8850 for ; Wed, 4 Apr 2012 08:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFBK0xsHYaec for ; Wed, 4 Apr 2012 08:31:09 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C121F883E for ; Wed, 4 Apr 2012 08:31:09 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39770) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SFSAm-0006ps-q4 (Exim 4.72) (return-path ); Wed, 04 Apr 2012 16:31:00 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SFSAm-0000tR-3W (Exim 4.67) (return-path ); Wed, 04 Apr 2012 16:31:00 +0100 Date: Wed, 4 Apr 2012 16:31:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Joe Abley In-Reply-To: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> Message-ID: References: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:31:10 -0000 Joe Abley wrote: > > the add/drop problem is a lot simpler if every AS112 node hosts the zone > > $ORIGIN . > @ SOA ... > NS something > NS sensible > > and answers authoritatively on the addresses corresponding to > "something" and "sensible", returning NXDOMAIN for everything in the > entire namespace apart from . (for which they ought never receive > queries anyway). This is ugly to some eyes, but it works for domainers > and it ought to work for us too. I think BIND treats NXDOMAIN replies with the wrong authority as a FORMERR. Domainers are returning positive replies which BIND does not subject to a SOA sanity check. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Northerly 5 to 7, occasionally 4 at first, increasing gale 8 later in north Fitzroy. Moderate or rough, becoming very rough later in north Fitzroy. Showers. Moderate or good. From joe.abley@icann.org Wed Apr 4 09:23:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A434621F8772 for ; Wed, 4 Apr 2012 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.79 X-Spam-Level: X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsqAQZ1qb2Lm for ; Wed, 4 Apr 2012 09:23:33 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 06FA421F866C for ; Wed, 4 Apr 2012 09:23:33 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 4 Apr 2012 09:23:32 -0700 From: Joe Abley To: Tony Finch Date: Wed, 4 Apr 2012 09:23:31 -0700 Thread-Topic: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item Thread-Index: Ac0Sf0bJwndzgE74QNWwGerqe+41zg== Message-ID: <1EFF6E68-27F0-4CE2-97C0-C468724743A4@icann.org> References: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:23:33 -0000 On 2012-04-04, at 11:31, Tony Finch wrote: > I think BIND treats NXDOMAIN replies with the wrong authority as a > FORMERR. Domainers are returning positive replies which BIND does not > subject to a SOA sanity check. monster.hopcount.ca is serving the fake (empty apart from apex SOA/NS and g= lue) root zone (and nothing else). hopcount.ca. has delegation empty.hopcount.ca. NS monster.hopcount.ca. I tested unbound 1.4.9 unbound 1.4.13 BIND 9.8.1-P1 Google DNS OpenDNS by sending queries "EMPTY.HOPCOUNT.CA/IN/A" and "EMPTY.HOPCOUNT.CA/IN/PTR". OpenDNS lied about the answer when I asked for an A, but that's to be expec= ted with their public service (and I guess suggests that there's nothing re= markable about empty.hopcount.ca as far as it is concerned). All other name= servers gave a prompt NXDOMAIN. I think the observation that this is not actually the same as what the doma= iners do (since these are negative responses, and domainers return answer s= ection data) is a good one, but I don't see the problem you mention in the = wild. Admittedly I only tested a small set of servers. Joe= From fanf2@hermes.cam.ac.uk Wed Apr 4 10:05:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A5B21F863C for ; Wed, 4 Apr 2012 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ1kWzwmplsk for ; Wed, 4 Apr 2012 10:05:36 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1403221F8468 for ; Wed, 4 Apr 2012 10:05:36 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40296) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SFTeA-0002Du-RC (Exim 4.72) (return-path ); Wed, 04 Apr 2012 18:05:26 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SFTeA-00062u-Bc (Exim 4.67) (return-path ); Wed, 04 Apr 2012 18:05:26 +0100 Date: Wed, 4 Apr 2012 18:05:26 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Joe Abley In-Reply-To: <1EFF6E68-27F0-4CE2-97C0-C468724743A4@icann.org> Message-ID: References: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> <1EFF6E68-27F0-4CE2-97C0-C468724743A4@icann.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:05:38 -0000 Joe Abley wrote: > On 2012-04-04, at 11:31, Tony Finch wrote: > > > I think BIND treats NXDOMAIN replies with the wrong authority as a > > FORMERR. Domainers are returning positive replies which BIND does not > > subject to a SOA sanity check. > > [real test] > All other nameservers gave a prompt NXDOMAIN. Thanks for checking that. I obviously mis-remembered the exact way in which BIND is pedantic. Sorry. Tony. -- f.anthony.n.finch http://dotat.at/ Plymouth: Cyclonic mainly northerly, becoming northeasterly, 4 at first in east, otherwise 5 to 7, but occasionally gale 8 in west. Very rough at first in northwest, otherwise moderate or rough. Showers. Moderate or good. From paul@redbarn.org Wed Apr 4 11:31:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E255A21F84F6 for ; Wed, 4 Apr 2012 11:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HI5X7SXVxM5 for ; Wed, 4 Apr 2012 11:31:54 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6321121F84F5 for ; Wed, 4 Apr 2012 11:31:54 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:650c:719d:a729:124] (unknown [IPv6:2001:559:8000:cb:650c:719d:a729:124]) by ss.vix.com (Postfix) with ESMTP id C5CA0EBC93; Wed, 4 Apr 2012 18:31:53 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F7C9398.1060104@redbarn.org> Date: Wed, 04 Apr 2012 18:31:52 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Tony Finch References: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> <1EFF6E68-27F0-4CE2-97C0-C468724743A4@icann.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dnsop@ietf.org" , Joe Abley Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 18:31:55 -0000 On 2012-04-04 5:05 PM, Tony Finch wrote: > Joe Abley wrote: >> On 2012-04-04, at 11:31, Tony Finch wrote: >> >>> I think BIND treats NXDOMAIN replies with the wrong authority as a >>> FORMERR. Domainers are returning positive replies which BIND does not >>> subject to a SOA sanity check. >> [real test] >> All other nameservers gave a prompt NXDOMAIN. > Thanks for checking that. I obviously mis-remembered the exact way in > which BIND is pedantic. Sorry. bind has a lot of non-pedantic behaviour available as options, but rarely as the default. if it's important to be able to pass through an incoherent nxdomain then please say why? From A.Hoenes@TR-Sys.de Wed Apr 4 15:42:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC1611E811D for ; Wed, 4 Apr 2012 15:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.849 X-Spam-Level: X-Spam-Status: No, score=-93.849 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymRJaRkRtkn5 for ; Wed, 4 Apr 2012 15:42:19 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id A260211E809A for ; Wed, 4 Apr 2012 15:42:17 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA019559264; Thu, 5 Apr 2012 00:41:04 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA29406; Thu, 5 Apr 2012 00:41:02 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204042241.AAA29406@TR-Sys.de> To: olaf@nlnetlabs.nl, matthijs@nlnetlabs.nl Date: Thu, 5 Apr 2012 00:41:02 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:42:21 -0000 After a long delay, I have revisited the "DNSSEC Operational Practices, Version 2" I-D and performed a full review from scratch for the most recent draft version, draft-ietf-dnsop-rfc4641bis-10. For convenience, and to accommodate message size limitations, I have split my review comments into 3 parts: (A) Technical flaws, (B) Editorial flaws, and (C) Editorial nits Only the first two parts will be sent to the dnsop list, the bulky third part is given as fodder to the authors only. Here we go with part (A); please consider to provide feedback for the items below on the list. (A) Technical flaws ++++++++++++++++++++ (A.1) Normative set of documents defining DNSSEC In Section 1, 1st para, the draft says: This document describes how to run a DNS Security (DNSSEC)-enabled environment. It is intended for operators who have knowledge of the | DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to | deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 | [RFC4035]). [...] However, the DNSSEC WG once has made the decision to include some other documents into the list of what should be regarded as the integral set of "core" documents defining DNSSEC[bis]. IIRC, that decision has been made in late 2009, and consequentially it has been recorded in the AXFR RFC (see section 2, page 7 of RFC 5936). These additions are: - RFC 4509 , - RFC 5155 , - RFC 5702 , and - draft-ietf-dnsext-dnssec-bis-updates (now at draft version -16 and expected to be submitted to the IESG very soon, likely in parallel to this memo). Therefore, I suggest to amend the above "see" list in the draft by adding these four documents, and accordingly to promote the References to them to Normative (the dnssec-bis-updates I-D needs to be added to the References). (A.2) Section 1.1 -- improper/imprecise description of key usage Section 1.1 improperly talks about public key usage in _key exchanges_. However, in the context of DNSSEC, the public part of asymmetric key pairs are used for _signature verification_ , and only that usage is relevant for this document. So please change: OLD: [...] It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the | public part that is used in key exchanges. ^^^^^^^^^^^^^ NEW: [...] It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the | public part that is used in signature verification. ^^^^^^^^^^^^^^^^^^^^^^ (A.3) Section 3.4.1 -- improved section title In Section 3.4, | 3.4. Cryptographic Considerations ... I suggest to make the title of Section 3.4.1 more precise. OLD: | 3.4.1. Key Algorithm NEW: | 3.4.1. Signature Algorithm or: | 3.4.1. Digital Signature Algorithm or: | 3.4.1. Digital Signature and Hash Algorithms (A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA Given the pressure by important governmental/international stakeholders in support of Elliptic Curve (EC) cryptography and the large amount of DNS response packet space consumed by RSA (and DSA) keys and signatures, I strongly recommend to give the reader a glimpse of perspective on ECDSA usage with DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor queue in state "RFC-Editor" and already supported by major DNS implementations. For instance, it would IMO make sense to add at the end of Section 3.4.1 or 3.4.2 a new paragraph like this: | Operators concerned with performance and key/signature size issues | related to RSA and DSA usage with DNSSEC should follow the ongoing | standardization -- and consequential implementation -- progress for | the use of digital signature algorithms based on Elliptic Curve (EC) | Cryptography with DNSSEC, which promises much shorter key and | signature sizes than RSA/DSA for equivalent cryptographic strenght. | In particular, the use of ECDSA with DNSSEC is now specified | [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in | the foreseeable future. (A.5) Section 4.1.1.2, 2nd bullet below Figure 3 and 2nd-to-last para For completeness and consistency with other parts of the document, I strongly recommend to expand on the present text and explicitly mention the propagation delay that needs to be taken into consideration, beyond the TTL-based cache expiry period. (See also the dnsop-dnssec-key-timing draft.) a) 2nd bullet OLD: new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY_Z_11 is introduced into the key set and all the data in the zone is signed with DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need | to continue until all data from version 0 of the zone has expired from remote caches. This will take at least the Maximum Zone TTL of version 0 of the zone. NEW: new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY_Z_11 is introduced into the key set and all the data in the zone is signed with DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need | to continue until all data from version 0 of the zone has been ^^^^^ | replaced in all secondary servers and then has expired from remote ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ caches. This will take at least the Maximum Zone TTL of version 0 of the zone. b) 2nd-to-last paragraph OLD: At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRset from the current version and vice- versa. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the Maximum Zone TTL of the previous | version of the zone. NEW: At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRset from the current version and vice- versa. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the Maximum Zone TTL of the previous | version of the zone plus the maximum propagation delay to secondary | servers. (A.6) Section 4.1.3 -- wrong key designators in text In the last two paragraphs of this section (below Figure 5), text apparently has been borrowed from Section 4.1.4 without being properly adjusted for the new context: In all instances of "DNSKEY_S_n" and "DS_S_n" (where "n" is "1" or "2"), "_S_" needs to be replaced by "_K_" (9 instances total). The revised paragraphs then should read (including a comma added on the 1st line of the final paragraph): NEW: When the child zone wants to roll, it notifies the parent during the "new DS" phase and submits the new key (or the corresponding DS) to | the parent. The parent publishes DS_K_1 and DS_K_2, pointing to | DNSKEY_K_1 and DNSKEY_K_2, respectively. During the rollover ("new DNSKEY" phase), which can take place as soon as the new DS set | propagated through the DNS, the child replaces DNSKEY_K_1 with | DNSKEY_K_2. Immediately after that ("DS/DNSKEY removal" phase), it can notify the parent that the old DS record can be deleted. | The drawbacks of this scheme are that during the "new DS" phase, the | parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 | using the DNS -- as DNSKEY_K_2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.3.3). Finally, the child-parent interaction consists of two steps. The "Double Signature" method only needs one interaction. (A.7) Section 4.1.5, Figure 7 -- wrong parent SOA serial In the second part of Figure 7 (stage "new DS"), the parent SOA serial needs to be incremented from the previous stage, which is the "initial" stage for that zone. So please correct: OLD: ---------------------------------------------------------------- new DS DNSKEY removal RRSIGs removal ---------------------------------------------------------------- Parent: | SOA_0 -------------------------------------------------------> RRSIG_par(SOA) ----------------------------------------------> DS_K_2 ------------------------------------------------------> RRSIG_par(DS_K_2) -------------------------------------------> NEW: ---------------------------------------------------------------- new DS DNSKEY removal RRSIGs removal ---------------------------------------------------------------- Parent: | SOA_1 -------------------------------------------------------> RRSIG_par(SOA) ----------------------------------------------> DS_K_2 ------------------------------------------------------> RRSIG_par(DS_K_2) -------------------------------------------> (A.8) Section 4.3.5.1, Figure 9 -- wrong child SOA serials? According to the prose in this section, as far as I understand it, the "redelegation" phase should happen with stable client zone data at both the old (A) and new (B) DNS operator and only change the parent zone -- or have I missed something important there? If these considerations apply, the client SOA serial increment shown in the redelegation phase in Figure 9 seems to be inappropriate and need to be decremented (to the values shown for the "pre-publish" phase; if so, the next client SOA serial in the "post migration" phase needs to be decremented as well. Further, for consistency in style, the phase name "redelegation" should be shown in lowercase, like all other phases in the figure. To sum up, I suggest the following changes: OLD: ------------------------------------------------------------ | Redelegation | post migration | ------------------------------------------------------------ Parent: NS_B NS_B DS_B DS_B ------------------------------------------------------------ Child at A: Child at B: Child at B: | SOA_A2 SOA_B1 SOA_B2 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) [...] NEW: ------------------------------------------------------------ | redelegation | post migration | ------------------------------------------------------------ Parent: NS_B NS_B DS_B DS_B ------------------------------------------------------------ Child at A: Child at B: Child at B: | SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) [...] (A.9) Section 4.4 -- technical clarification Since RFC 2308 specified the caching behavior for negative responses, which arguably do not deliver "data", the text in Section 4.4 needs a small addition to properly represent the negative caching behavior as well: OLD: Without DNSSEC, all times in the DNS are relative. The SOA fields REFRESH, RETRY, and EXPIRATION are timers used to determine the time | elapsed after a slave server synchronized with a master server. The | Time to Live (TTL) value and the SOA RR minimum TTL parameter | [RFC2308] are used to determine how long a forwarder should cache | data after it has been fetched from an authoritative server. By ^^^^ using a signature validity period, DNSSEC introduces the notion of an absolute time in the DNS. Signatures in DNSSEC have an expiration date after which the signature is marked as invalid and the signed data is to be considered Bogus. NEW: Without DNSSEC, all times in the DNS are relative. The SOA fields REFRESH, RETRY, and EXPIRATION are timers used to determine the time elapsed after a slave server synchronized with a master server. The Time to Live (TTL) value and the SOA RR minimum TTL parameter [RFC2308] are used to determine how long a forwarder should cache | data after it has been fetched from an authoritative server or ^^^ | negative responses, respectively. By using a signature validity ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ period, DNSSEC introduces the notion of an absolute time in the DNS. Signatures in DNSSEC have an expiration date after which the signature is marked as invalid and the signed data is to be considered Bogus. (A.10) Section 5.1, ff. -- term "RRlabel" needs clarification I have trouble understanding what the term "RRlabel" means and what precisely the draft wants to state in the text passages where it is used. This term, used as a single word, is very uncommon and has not been used in published RFCs so far, and it is nowhere formally defined in this memo; yet it recurs for a total of 8 instances in Sections 5.2, 5.3.1, and 5.3.3. The first occurrence is in the first sentence of the last para of Section 5.1, which says: | The NSEC3 record uses a hashing method of the requested RRlabel. If the draft wants to introduce a new term, it should precisely define it upon first usage (or in a terminology section). I also do not fully understand what "requested" means here -- a QNAME in a DNS query? (that's not a 'label' in the sense of STD 13, but a FQDN); subsequent text in Section 5.2 (3rd para): | For large zones where there is an implication of "not readily | available" RRlabels, such as those where one has to sign a non- | disclosure agreement before obtaining it, NSEC3 is preferred. [...] ... might even be understood as indicating 'request for registration' (via a registrar into a zone that has restrictive policies on what relative domain names can be registered). That needs clarification. But, firstly, back to the last para of Section 5.1! Upon further investigation: what's hashed for NSEC3 aren't single labels, but the fully qualified domain names registered in the zone -- the details are specified in Section 7.1 of RFC 5155, and also quoted shortly in Section 5.3.1 of the draft. And these are not the domain names "requested" in DNS queries (QNAMEs) -- unless these happen to match FQDNs for which RFC 5155 has made mandatory the generation of NSECe RRs (in particular, for secure delegations and for wildcards), or for which the Opt-out policy in force has chosen to generate NSEC3 records. Thus, as long as there is no sensical definition of the term, maybe "the requested RRlabels" might better be replaced by "the names registered in the zone". Note that the subsequent instances of "RRlabel" in Sections 5.2 (1st and 3rd para, 1x each), 5.3.1 (1st para, 2x), and 5.3.3 (2nd para, 3x) will likely need text adjustments as well. (A.11) Appendix C, Figures 12 and 13 -- wrong parent SOA serial The change for Figure 7 shown above in item (A.7) applies literally to Figure 12 in Appendix C, and again to Figure 13 in Appendix C -- with the caveat that the key designations are for "_S_" keys as in Figure 11, not for "_K_" keys as in Figures 7 and 12. (A.12) Appendix D, Figure 14 -- wrong child SOA serials? The changes for Figure 9 shown above in item (A.8) applies literally to Figure 14 in Appendix D as well. Part (B) will follow quickly in a subsequent message. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Wed Apr 4 15:49:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865E511E8120 for ; Wed, 4 Apr 2012 15:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.999 X-Spam-Level: X-Spam-Status: No, score=-94.999 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU8ZLVmeCwXX for ; Wed, 4 Apr 2012 15:49:34 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAD011E8098 for ; Wed, 4 Apr 2012 15:49:32 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA019629700; Thu, 5 Apr 2012 00:48:20 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA29446; Thu, 5 Apr 2012 00:48:19 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204042248.AAA29446@TR-Sys.de> To: olaf@nlnetlabs.nl, matthijs@nlnetlabs.nl Date: Thu, 5 Apr 2012 00:48:19 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:49:35 -0000 As indicated in the previous message, I have revisited the "DNSSEC Operational Practices, Version 2" I-D and performed a full review from scratch for the most recent draft version, draft-ietf-dnsop-rfc4641bis-10. For convenience, and to accommodate message size limitations, I have split my review comments into 3 parts: (A) Technical flaws, (B) Editorial flaws, and (C) Editorial nits Only the first two parts are being sent to the dnsop list, the bulky third part is given as fodder to the authors only. Here we go with part (B); if deemed necessary, please consider to provide feedback for the items below on the list. (B) Editorial flaws ++++++++++++++++++++ (B.1) general -- terminology The draft should make more consistent use of signature timing terms. (B.1.1) "signature validity period" et al. The draft mostly uses "signature validity period" (or shortly "validity period" [of a signature]) to indicate the (non-recurring) time interval defined by the Signature Inception and Signature Expiration fields in the RRSIG RDATA, but it also uses "signature validity interval" in several instances, and it uses the partially capitalized forms "Signature Validity period" and "Signature Validity interval" in Section 4.4.2.2 and "Validity Period" in Figure 10. With two big caveats (see below), I recommend to harmonize on the term "signature validity period", as introduced in Section 2, "Time Definitions", and to always use the lowercase version. Further, the title of Section 4.4.2, "Signature Validation Period", is not used anywhere else and should be altered to "Signature Validity Period". * Caveat #1: From a mathematical/metrological perspective, the term "signature validity *period*" is a bad misnomer since it is used to indicate a single (non-recurring), closed (inclusive), time *interval*, [ Signature_Inception, Signature_Expiration ] . Ironically, the primary definition in Section 3 (2nd para) of RFC 4034 uses the proper term, "signature validity interval", but Section 3.1.5 of RFC 4034 says "signature validity period", as does RFC 4033 in Section 2, 6, 8, and 8.1. To add even more inconsistency into the terminology used, Section 2 of RFC 4033 also uses one instance of "validity lifetime". So it looks like we are stuck with the improper term "validity period" for consistence and uniformity with RFCs 4033/4034. * Caveat #2: Other timing parameters are (mostly) spelled in headline case throughout the memo. Hint for the document editor: The instances of "[signature] validity interval" I found are in: - Section 4.2.1.1, bullet 5. - Section 4.3.4, 2nd paragraph (2x) - Section 4.4.1, last paragraph - Section 4.4.2.2, 4th paragraph (use lowercase, as noted above!) - Section 4.4.2.3, 3rd paragraph (2x) In Section 4.3.5.2, 1st paragraph, for uniformity "signature validity" should be amended to say "signature validity period" as well. (B.1.2) "Re-Sign Period" and "Refresh Period" et al. The draft mostly uses these terms in headline case, but also a few instances of mixed case, and a single instance of an unnecessary variation, "refresh interval" appear in the draft. The draft should better uniformly use the headline case spelling for the defined terms. (See the editing hints below.) These terms are defined in Appendix A, "Terminology"; however, there the variant "Re-Signing frequency" is used as a key word and "Re-Signing Period" is used in the definition, both of which do no occur anywhere else in the draft. Therefore, I suggest to alter that definition in Appendix B to properly introduce the term used throughout the draft: OLD: Re-Signing frequency: Frequency with which a signing pass on the zone is performed. Alternatively expressed as "Re-Signing Period". It defines when the zone is exposed to the signer. During a signing pass, not all signatures in the zone may be regenerated: that depends on the refresh period. NEW (with change tags): | Re-Sign Period: This refers to the (reciprocal of the) frequency ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | with which a signing pass on the zone is performed. The Re-Sign ^^^^^^^^^^^ | Period defines when the zone is exposed to the signer. During a ^^^ signing pass, not all signatures in the zone may be regenerated: | that depends on the Refresh Period. ^ ^ Hints to the document editor: - Section 4.4.1, 2nd bullet, 2nd para: s/refresh interval/Refresh Period/ - Section 4.4.1, 2nd bullet, 3rd para: s/Refresh period/Refresh Period/ - Section 4.4.1, last bullet, 5th para: s/Refresh period/Refresh Period/ (B.2) Section 1 -- outdated text The 2nd paragraph of Section 1 says: During workshops and early operational deployment, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these experiences into a set of practices for zone administrators. At the | time of writing -the root has just been signed and the first secure | delegations are provisioned- there exists relatively little experience with DNSSEC in production environments below the top-level domain (TLD) level; this document should therefore explicitly not be seen as representing 'Best Current Practices'. Instead, ... The tagged phrase seems to be outdated now and should be updated to reflect te successful deployment of DNSSEC in the Root zone and many TLDs. As of today, the ICANN TLD DNSSEC Report (2012-04-03) ( ) says: | Summary | | * 313 TLDs in the root zone in total | * 91 TLDs are signed; | * 85 TLDs have trust anchors published as DS records in the root zone; | * 4 TLDs have trust anchors published in the ISC DLV Repository. So I suggest to modify the dangling sentence in the above quote to say: During workshops and early operational deployment, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these | experiences into a set of practices for zone administrators. Although | the DNS Root has been signed since July 15, 2010 and now more than 80 | secure delegations are provisioned in the root, at the time of writing there still exists relatively little experience with DNSSEC in production environments below the top-level domain (TLD) level; this document should therefore explicitly not be seen as representing 'Best Current Practices'. Instead, ... (B.3) Section 1.2 -- clarification With respect to item (B.1) above, I suggest to even better clarify the definition of "Signature validity period" in Section 1.2 (1st bullet): OLD: | o "Signature validity period" The period that a signature is valid. | It starts at the time specified in the signature inception field | of the RRSIG RR and ends at the time specified in the expiration | field of the RRSIG RR. NEW: | o "Signature validity period" The time interval during which a | signature is valid. It starts at the (absolute) time specified in | the signature inception field of the RRSIG RR and ends at the | (absolute) time specified in the expiration field of the RRSIG RR. (Regarding the list style here, I'll supply an editorial nit.) (B.4) Section 3.1, 7th para -- language improvement / clarification I suggest to improve the language in the first part of the last sentence in the 7th paragraph of Section 3.1: [...]. Since for all practical purposes X will somewhere of the order of 10 to 100, the associated key sizes will vary only about a byte in size for symmetric keys. When translated to asymmetric | keys, is still too insignificant a size difference to warrant a key- split; it only marginally affects the packet size and signing speed. --- [...]. Since for all practical purposes X will somewhere of the order of 10 to 100, the associated key sizes will vary only about a byte in size for symmetric keys. When translated to asymmetric | keys, the size difference is still too insignificant to warrant a key split; it only marginally affects the packet size and signing speed. (B.5) Section 4.1.1.1 -- clarifications a) The preamble to Figure 1 says: | Pre-Publish key rollover involves four stages as follows: For clarity on first reading, I suggest to make this clause a bit more precise, in mentioning the role of the ZSKs in the figure: vvvvvvvvvvvvvvvvvvvvvvv | Pre-Publish key rollover from key 10 to key 11 involves four stages | as follows: IMHO, there is no need to repeat a similar addition for subsequent figures because a sequential reader of the memo will take note of the elaborations below Figure 1 and not need to be made aware of similar context in the other rollover figures. (B.6) Section 4.1.5, list items below Figure 5 -- clarifications (a) In the 1st list item below Figure 7, the draft says: initial: Describes state of the zone before any transition is done. | The number of the keys may vary, but the algorithm of keys in the | zone is same for all DNSKEY records. This is hard to parse and understand. I suggest to change the wording to say: initial: Describes state of the zone before any transition is done. | The number of the keys may vary, but all keys (in DNSKEY records) | for the zone use the same algorithm. If this change is not accepted, at least s/is same/is the same/ . (b) In the 2nd list item, the draft says: new RRSIGs: The signatures made with the new key over all records in the zone are added, but the key itself is not. This step is needed to propagate the signatures created with the new algorithm to the caches. If this is not done, it is possible for a resolver to retrieve the new DNSKEY RRset (containing the new algorithm) | but to have a RRsets in cache with signatures created by the old DNSKEY RRset (i.e. without the new algorithm). The tagged line should be clarified to say: | but to have RRsets in its cache with signatures created by the old (c) In subsequent list items, I suggest to clarify the text -- where becessary -- by making the distinction between "old" and newer data more explicit, and -- in two instances -- an indication of the possibility of more than one DNSKEY RR (as in the Figure, due to the split KSK/ZSK scheme used) should be indicated by talking about the "DNSKEY RRset": | new DNSKEY: After the cache data has expired, the new key can be added to the zone. --- vvvvv | new DNSKEY: After the old cache data has expired, the new key can be added to the zone. | new DS: After the cache data for the DNSKEY has expired, the DS record for the new key can be added to the parent zone and the DS record for the old key can be removed in the same step. --- vvvvv vvvvvvv | new DS: After the cache data for the old DNSKEY RRset has expired, the DS record for the new key can be added to the parent zone and the DS record for the old key can be removed in the same step. | DNSKEY removal: After the cache data for the DS has expired, the old | algorithm can be removed. This time the key needs to be removed | first, before removing the signatures. --- vvvvv | DNSKEY removal: After the cache data for the old DS has expired, the | old algorithm can be removed. This time the old key needs to be vvvvv ^^^^^ | removed first, before removing the old signatures. | RRSIGs removal: After the cache data for the DNSKEY has expired, the | signatures can also be removed during this step. --- vvvvv vvvvvvv | RRSIGs removal: After the cache data for the old DNSKEY RRset has | expired, the old signatures can also be removed during this step. ^^^^^ (B.7) Section 4.1.5.3, 1st para -- wrong pointer The draft text refers to Figure 12 where it should refer to Figure 13: Combining the Single Signing Type Scheme Algorithm Rollover and | RFC5011 style rollovers is not trivial, see Figure 12 in Appendix C. --- ^^ Combining the Single Signing Type Scheme Algorithm Rollover and | RFC 5011 style rollovers is not trivial, see Figure 13 in Appendix C. ^ ^^ (Note that Figure 11 details the 'normal' Single Signing Type Scheme, Figure 12 details the RFC 5011 style rollover with split KSK/ZSK, and Figure 13 actually details the single key, RFC 5011 style variant.) (B.8) Section 4.2.1.x -- disambiguation/clarification in title & text The superordinate section titles only set context insufficiently and so the section titles and leading text of both Sections 4.1.2.1 and 4.2.1.2 might cause misunderstanding of what the intended advice is (even indicating malicious intent!). I suggest to add precision to both in expanding on the key rollover scenario described there. (a) Section 4.2.1.1 OLD: |4.2.1.1. Keeping the Chain of Trust Intact | | If we follow this advice, the timing of the replacement of the KSK is | somewhat critical. The goal is ... NEW: |4.2.1.1. Emergency Key Rollover Keeping the Chain of Trust Intact | | If we follow this advice to perform emergency key rollover in a | manner that keeps the chain of trust intact, the timing of the replacement of the KSK is somewhat critical. The goal is ... (b) Section 4.2.1.2 OLD: |4.2.1.2. Breaking the Chain of Trust | | There are two methods to break the chain of trust. The first method causes the child zone to appear 'Bogus' to validating resolvers. The other causes the child zone to appear 'insecure'. These are described below. NEW: |4.2.1.2. Emergency Key Rollover Breaking the Chain of Trust | | There are two methods to perform an emergency key rollover in a | manner that breaks the chain of trust. The first method causes the child zone to appear 'Bogus' to validating resolvers. The other causes the child zone to appear 'insecure'. These are described below. (B.9) Section 4.2.3 -- IETF terminology In the last line of the second paragraph of Section 4.2.3, the draft should prefer to say "Transport Layer Security (TLS)" in favor of "secure sockets (TLS)" . Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From wjhns1@hardakers.net Thu Apr 5 07:40:36 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1247721F85C9 for ; Thu, 5 Apr 2012 07:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w1UhW4apaY7 for ; Thu, 5 Apr 2012 07:40:35 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A09921F85C0 for ; Thu, 5 Apr 2012 07:40:35 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id E75E65B1; Thu, 5 Apr 2012 07:40:34 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: Date: Thu, 05 Apr 2012 07:40:34 -0700 In-Reply-To: (Edward Lewis's message of "Thu\, 29 Mar 2012 11\:17\:28 +0200") Message-ID: <0l62dejl7h.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Want this to be a WG doc? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:40:36 -0000 >>>>> On Thu, 29 Mar 2012 11:17:28 +0200, Edward Lewis said: EL> Any thoughts on whether the following would be a DNSOP document? I'm EL> asking DNSEXT too. My initial reaction, after reading the title, was "yes, it looks like a good thing". Then I read the document and realized you were pseudo-documenting recent allocated types that may or may not exist in the future and may or may not change in RDATA content before final publication (if any) in the first place. Because of all the unknowns in that list, it doesn't seem wise to formally document a questionable list. In particular, one of the whole reasons behind relaxing the RRTYPE allocation system was to allow more rapid creation of new data types without requiring they be documented (fully). So... I'm leaning toward "no" with a decent chance of being pushed toward "yes" with even a fairly small logic-I-missed shove. -- Wes Hardaker SPARTA, Inc. From A.Hoenes@TR-Sys.de Mon Apr 9 14:14:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEB721F8810 for ; Mon, 9 Apr 2012 14:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.57 X-Spam-Level: X-Spam-Status: No, score=-96.57 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2erYdG31WZm for ; Mon, 9 Apr 2012 14:14:35 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF821F880F for ; Mon, 9 Apr 2012 14:14:30 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA043235998; Mon, 9 Apr 2012 23:13:18 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA03306; Mon, 9 Apr 2012 23:13:17 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204092113.XAA03306@TR-Sys.de> To: dnsop@ietf.org Date: Mon, 9 Apr 2012 23:13:16 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [DNSOP] a review of draft-ietf-dnsop-dnssec-dps-framework-06 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:14:35 -0000 Hello, in my attempt to catch up with DNS related work in the IETF, I now also have reviewed the most recent version of the DNSSEC DPS draft, draft-ietf-dnsop-dnssec-dps-framework-06. I did not find any serious issues or inconsistencies in the memo, and in general, it looks almost ready for bringing it to the IESG for publication as an Informational RFC. However, I found a couple of editorial nits and opportunities to make the language and use of terminology more precise and consistent within the memo and among existing DNS[SEC] related IETF documents, and just sent a report on these editorials to the draft authors. They might want to sum up the resulting changes on the list, but I did not want to bother list readers with the details. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From shane@isc.org Tue Apr 10 07:07:14 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FEF21F8643 for ; Tue, 10 Apr 2012 07:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abZKab+aX2Xq for ; Tue, 10 Apr 2012 07:07:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C921F8671 for ; Tue, 10 Apr 2012 07:07:13 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id ED6155F984C; Tue, 10 Apr 2012 14:06:58 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:610:719:1:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6742D216C33; Tue, 10 Apr 2012 14:06:56 +0000 (UTC) (envelope-from shane@isc.org) Date: Tue, 10 Apr 2012 16:06:44 +0200 From: Shane Kerr To: "Livingood, Jason" Message-ID: <20120410160644.457bc56b@shane-eeepc.home.time-travellers.org> In-Reply-To: References: <04482A48-AA10-4907-8AF0-41389E7F4EBE@sidn.nl> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dnsop Subject: [DNSOP] Limiting duration for Negative Trust Anchors, was Re: New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:07:14 -0000 Jason, On Tuesday, 2012-03-27 15:19:23 +0000, "Livingood, Jason" wrote: > I posted a =E2=80=9301 a short time ago > (http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01) > and listed this in open items for the next version. I may have some > questions on the best way to include that. I like this idea; it was something I planned on including in BIND 10 for a while, although we've got other higher-priority things to add first (like DNSSEC validation). ;) One tiny bit: Furthermore, a Negative Trust Anchor should be used only for a short duration, perhaps for a day or less. While for larger ISPs a top-100 approach makes sense, and so a 1 day fix is= reasonable to expect, other operators will have other concerns. For exampl= e, you may have a distributor for your business that has a crappy IT depart= ment and simply can't get their zones fixed in a reasonable time, or you ma= y have a department at your university that is literally gone for the summe= r. The approach I had planned on taking is simply to require that an administrator specify the ending time of the Negative Trust Anchor. If they want to, of course they can put 30 years (or perhaps however much time is left until their retirement), but at least they would have had to think about the issue! -- Shane From paul@nohats.ca Tue Apr 10 07:37:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACA121F8685 for ; Tue, 10 Apr 2012 07:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVESVhnTs2+k for ; Tue, 10 Apr 2012 07:37:28 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id A880721F866D for ; Tue, 10 Apr 2012 07:37:21 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 5271580116; Tue, 10 Apr 2012 10:37:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 42D0A8001C; Tue, 10 Apr 2012 10:37:21 -0400 (EDT) Date: Tue, 10 Apr 2012 10:37:21 -0400 (EDT) From: Paul Wouters To: Shane Kerr In-Reply-To: <20120410160644.457bc56b@shane-eeepc.home.time-travellers.org> Message-ID: References: <04482A48-AA10-4907-8AF0-41389E7F4EBE@sidn.nl> <20120410160644.457bc56b@shane-eeepc.home.time-travellers.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 10 Apr 2012 08:14:28 -0700 Cc: dnsop , "Livingood, Jason" Subject: Re: [DNSOP] Limiting duration for Negative Trust Anchors, was Re: New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:37:33 -0000 On Tue, 10 Apr 2012, Shane Kerr wrote: > Furthermore, a Negative Trust Anchor should be used only for a short > duration, perhaps for a day or less. > > While for larger ISPs a top-100 approach makes sense, and so a 1 day fix is reasonable to expect, other operators will have other concerns. For example, you may have a distributor for your business that has a crappy IT department and simply can't get their zones fixed in a reasonable time, or you may have a department at your university that is literally gone for the summer. > > The approach I had planned on taking is simply to require that an > administrator specify the ending time of the Negative Trust Anchor. If > they want to, of course they can put 30 years (or perhaps however much > time is left until their retirement), but at least they would have had > to think about the issue! What's wrong with the proven method of exponential back-off ? Paul From wjhns1@hardakers.net Tue Apr 10 17:11:19 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE0911E8129 for ; Tue, 10 Apr 2012 17:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceMTzLYLqwnY for ; Tue, 10 Apr 2012 17:11:18 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EE511E80F8 for ; Tue, 10 Apr 2012 17:11:17 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id E45BF64E; Tue, 10 Apr 2012 17:11:15 -0700 (PDT) From: Wes Hardaker To: "Livingood\, Jason" References: Date: Tue, 10 Apr 2012 17:11:15 -0700 In-Reply-To: (Jason Livingood's message of "Mon, 26 Mar 2012 07:57:59 +0000") Message-ID: <0lk41nqg9o.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:11:19 -0000 >>>>> On Mon, 26 Mar 2012 07:57:59 +0000, "Livingood, Jason" said: LJ> http://www.ietf.org/id/draft-livingood-negative-trust-anchors-00.txt LJ> Feel free to share any other questions or feedback. I too like the idea behind it, and have the following suggestions to support it: 1) In addition to the following statement: Furthermore, a Negative Trust Anchor should be used only for a short duration, perhaps for a day or less. I'd go ahead and insert MUST/SHOULD/MAY language as well (realizing that if there is a document people will ignore it in, this is likely to be one). And then add some timing constraints too [reading the rest of the thread after typing this, I note that Shane also suggested an end time, but the proposal below also imposes a maximum end-time allowable]. Suggested rewrite: Furthermore, a Negative Trust Anchor MUST only be used for a short duration, perhaps for a day or less. Implementations MUST require an end-time configuration associated with any negative trust anchor. Implementations SHOULD limit the maximum time into the future to one day. In other words, the configuration directive will be invalid if it is missing an end-time or if the end time is greater than "now" plus 86400 seconds. 2) I also suggest you rename the concept to "Negative Anchors of Trust" and then sprinkle the document with statements like the following: NATs are not an appropriate long-term solution and if they need to be used, they MUST be used only for short periods of time. (it's the two-birds-with-one-stone theory of RFC writing) -- Wes Hardaker SPARTA, Inc. From chris_griffiths@cable.comcast.com Tue Apr 10 19:37:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DD721F84F1 for ; Tue, 10 Apr 2012 19:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.897 X-Spam-Level: X-Spam-Status: No, score=-100.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYiqx73WmAkv for ; Tue, 10 Apr 2012 19:37:05 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5C47521F84EF for ; Tue, 10 Apr 2012 19:37:05 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.8838205; Tue, 10 Apr 2012 22:30:20 -0400 Received: from PACDCEXMB03.cable.comcast.com ([fe80::c9c:28ac:e945:214f]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 22:37:00 -0400 From: "Griffiths, Chris" To: Wes Hardaker Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5aU2PwIgABrs4A= Date: Wed, 11 Apr 2012 02:36:59 +0000 Message-ID: <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> References: <0lk41nqg9o.fsf@wjh.hardakers.net> In-Reply-To: <0lk41nqg9o.fsf@wjh.hardakers.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <52A1B065B3623F4ABBE5D4D7FC8B767F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop , "Livingood, Jason" Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 02:37:06 -0000 On Apr 10, 2012, at 8:11 PM, Wes Hardaker wrote: >>>>>> On Mon, 26 Mar 2012 07:57:59 +0000, "Livingood, Jason" said: >=20 > LJ> http://www.ietf.org/id/draft-livingood-negative-trust-anchors-00.txt >=20 > LJ> Feel free to share any other questions or feedback. >=20 > I too like the idea behind it, and have the following suggestions to > support it: >=20 > 1) In addition to the following statement: >=20 > Furthermore, a Negative Trust Anchor should > be used only for a short duration, perhaps for a day or less. >=20 > I'd go ahead and insert MUST/SHOULD/MAY language as well (realizing > that if there is a document people will ignore it in, this is likely > to be one). And then add some timing constraints too [reading the > rest of the thread after typing this, I note that Shane also > suggested an end time, but the proposal below also imposes a maximum > end-time allowable]. Perhaps a TTL equivalent as previously suggested, I agree we should look to= add the MUST/SHOUD/MAY language for this. > Suggested rewrite: >=20 > Furthermore, a Negative Trust Anchor MUST only be used for a > short duration, perhaps for a day or less. Implementations MUST > require an end-time configuration associated with any negative > trust anchor. Implementations SHOULD limit the maximum time into > the future to one day. In other words, the configuration > directive will be invalid if it is missing an end-time or if the > end time is greater than "now" plus 86400 seconds. Agreed. Maximum time supported makes sense to me. >=20 > 2) I also suggest you rename the concept to "Negative Anchors of Trust" > and then sprinkle the document with statements like the following: >=20 > NATs are not an appropriate long-term solution and if they need to = be > used, they MUST be used only for short periods of time. >=20 > (it's the two-birds-with-one-stone theory of RFC writing) I got a good chuckle on this one. We will have to think hard about this :-= ) Thanks Chris From shane@isc.org Wed Apr 11 03:19:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5537621F870F for ; Wed, 11 Apr 2012 03:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojyyieAMJf8a for ; Wed, 11 Apr 2012 03:19:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1E21F870E for ; Wed, 11 Apr 2012 03:19:02 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id AE2AC5F98E5; Wed, 11 Apr 2012 10:18:46 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:610:719:1:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3B17B216C31; Wed, 11 Apr 2012 10:18:44 +0000 (UTC) (envelope-from shane@isc.org) Date: Wed, 11 Apr 2012 12:18:33 +0200 From: Shane Kerr To: Paul Wouters Message-ID: <20120411121833.79e34382@shane-eeepc.home.time-travellers.org> In-Reply-To: References: <04482A48-AA10-4907-8AF0-41389E7F4EBE@sidn.nl> <20120410160644.457bc56b@shane-eeepc.home.time-travellers.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop Subject: Re: [DNSOP] Limiting duration for Negative Trust Anchors, was Re: New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:19:03 -0000 Paul, On Tuesday, 2012-04-10 10:37:21 -0400, Paul Wouters wrote: > On Tue, 10 Apr 2012, Shane Kerr wrote: > > The approach I had planned on taking is simply to require that an > > administrator specify the ending time of the Negative Trust Anchor. > > If they want to, of course they can put 30 years (or perhaps > > however much time is left until their retirement), but at least > > they would have had to think about the issue! > > What's wrong with the proven method of exponential back-off ? I'm not sure what you mean. This is a manual process. Software could suggest an ending time to an administrator, and even use exponential back-off, but I don't think such an algorithm would be especially helpful. Probably we want more human-oriented suggestions like "3 days" or "2 weeks" rather than "1d 12:24:32.0". -- Shane From shane@isc.org Wed Apr 11 04:40:52 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6EC21F8628 for ; Wed, 11 Apr 2012 04:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLGzKJuxOQaY for ; Wed, 11 Apr 2012 04:40:51 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 34B4721F8623 for ; Wed, 11 Apr 2012 04:40:51 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1748E5F9899 for ; Wed, 11 Apr 2012 11:40:36 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:610:719:1:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4CEF9216C33 for ; Wed, 11 Apr 2012 11:40:34 +0000 (UTC) (envelope-from shane@isc.org) Date: Wed, 11 Apr 2012 13:40:23 +0200 From: Shane Kerr To: dnsop Message-ID: <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> In-Reply-To: <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:40:52 -0000 Chris, On Wednesday, 2012-04-11 02:36:59 +0000, "Griffiths, Chris" wrote: > > > Suggested rewrite: > > > > Furthermore, a Negative Trust Anchor MUST only be used for a > > short duration, perhaps for a day or less. Implementations > > MUST require an end-time configuration associated with any negative > > trust anchor. Implementations SHOULD limit the maximum time > > into the future to one day. In other words, the configuration > > directive will be invalid if it is missing an end-time or if > > the end time is greater than "now" plus 86400 seconds. > > Agreed. Maximum time supported makes sense to me. This seems like an unnecessary limitation to me. For example, I know someone who regularly forgets to re-sign his zones. Yes, he knows he should set BIND up to re-sign them automatically or perhaps use zkt, but that takes time and it's just his own vanity domain. Personally I would like to set a negative trust anchor for his zones until such time as he sets something like this up, since I know that the signatures will expire in a few months and break the zone for me at that time. Plus, I know it is surprising to folks on this list, but some zones do not have full time administrators, and may have to wait until admin staff get back on Monday morning until they are fixed - or perhaps even until the one "computer guy" at a company gets back from vacation. I'm just saying, requiring some maximum time makes sense, but specifying one that works for large, professional ISPs may not work for everyone. Can we just keep it open? -- Shane From Ralf.Weber@nominum.com Wed Apr 11 06:02:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A993821F8621 for ; Wed, 11 Apr 2012 06:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihUmO0Wc2Pxb for ; Wed, 11 Apr 2012 06:02:10 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2BA21F8610 for ; Wed, 11 Apr 2012 06:02:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT4WA0W2YWe5LZNJKL/JNFnUxZc5u8VcO@postini.com; Wed, 11 Apr 2012 06:02:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 01D921B831E for ; Wed, 11 Apr 2012 06:02:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E927319006D; Wed, 11 Apr 2012 06:02:08 -0700 (PDT) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 11 Apr 2012 06:02:09 -0700 From: Ralf Weber To: Wes Hardaker Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNF+NNC4ZRDIQP2kGNIXp5HGuadw== Date: Wed, 11 Apr 2012 13:02:08 +0000 Message-ID: <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> References: <0lk41nqg9o.fsf@wjh.hardakers.net> In-Reply-To: <0lk41nqg9o.fsf@wjh.hardakers.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E0021D7A82BB142BA2DFE55378D3236@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop , "Livingood, Jason" Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:02:11 -0000 Moin! On 11.04.2012, at 02:11, Wes Hardaker wrote: > 1) In addition to the following statement: >=20 > Furthermore, a Negative Trust Anchor should > be used only for a short duration, perhaps for a day or less. >=20 > I'd go ahead and insert MUST/SHOULD/MAY language as well (realizing > that if there is a document people will ignore it in, this is likely > to be one). And then add some timing constraints too [reading the > rest of the thread after typing this, I note that Shane also > suggested an end time, but the proposal below also imposes a maximum > end-time allowable]. >=20 > Suggested rewrite: >=20 > Furthermore, a Negative Trust Anchor MUST only be used for a > short duration, perhaps for a day or less. Implementations MUST > require an end-time configuration associated with any negative > trust anchor. Implementations SHOULD limit the maximum time into > the future to one day. In other words, the configuration > directive will be invalid if it is missing an end-time or if the > end time is greater than "now" plus 86400 seconds. I disagree with that. I have seen misconfigured domains that where misconfi= gured on error for a much longer time. Also process wise if the negative tr= ust anchors automatically get removed from the server and the domain is sti= ll misconfigured it will go off again for the resolver operators customers.= The addition and the removal of a negative trust anchor should be a proces= s in the operators network and not an automation in software. > 2) I also suggest you rename the concept to "Negative Anchors of Trust" > and then sprinkle the document with statements like the following: >=20 > NATs are not an appropriate long-term solution and if they need to = be > used, they MUST be used only for short periods of time. Again I have a problem with the MUST. As above it should be a SHOULD. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From A.Hoenes@TR-Sys.de Wed Apr 11 06:09:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6221F8665 for ; Wed, 11 Apr 2012 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.65 X-Spam-Level: X-Spam-Status: No, score=-96.65 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DxiqFUFCKGg for ; Wed, 11 Apr 2012 06:09:21 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6321F8594 for ; Wed, 11 Apr 2012 06:09:19 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA055259667; Wed, 11 Apr 2012 15:07:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA15429; Wed, 11 Apr 2012 15:07:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204111307.PAA15429@TR-Sys.de> To: dnsop@ietf.org Date: Wed, 11 Apr 2012 15:07:46 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Cc: stephen@isc.org Subject: [DNSOP] two remarks on draft-ietf-dnsop-dnssec-key-timing-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:09:21 -0000 Folks, The key-timing I-D has been discussed over a long time, but has not been refreshed for a significant while. I think we should make progress with this memo now (in line with the rfc4641bis I-D), and have performed a review of the most recent WG draft version, draft-ietf-dnsop-dnssec-key-timing-02. I did not find any major issues with the text and recommend to undertake steps to request publication soon. Below are two small suggestions for improvement. A somewhat more lenghty list of editorials and suggested textual improvements has just been sent to the draft authors. (A) dangling internal pointer In Section 3.2.1, the description of Event 3 contains an, IMHO misleading pointer: | (The case of introducing the first ZSK into the zone is discussed in | Section 3.3.5.) This is not actually correct; Section 3.3.5 most exclusively focusses onto the first *KSK* introduced, which does not apply to the first ZSK in the split (KSK,ZSK) model, to which this subject Section 3.2 on ZSK rollover relates. As experience (e.g. with the root zone) has shown, in the absense of a secure delegation or a trust anchor, in the split (KSK,ZSK) model addressed by this section, the first KSK can be introduced without regard to specific timing considerations. So for simplicity, I propose to just drop the quoted note from this section. (Similar notes in subsequent sections of the I-D however are appropriate.) (B) cross-linkage to rfc4641bis The rfc4641bis draft complements this draft and refers to it, and it contains material that can help a reader starting with this memo. Therefore, I suggest that the key-timing draft should in turn refer (in the appropriate sections) to the descriptions and pictoral representations of the various rollover scenarios in the rfc4641bis document, where the life-cycle of DNSSEC-related RRs during such rollover is depicted, for which the key-timing I-D provides the timing details. Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From nweaver@icsi.berkeley.edu Wed Apr 11 06:28:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1321F8624 for ; Wed, 11 Apr 2012 06:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgKHgmlAWJ2J for ; Wed, 11 Apr 2012 06:28:50 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5C221F86A1 for ; Wed, 11 Apr 2012 06:28:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id EF6102C403D; Wed, 11 Apr 2012 06:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MHoz-Ifjmvie; Wed, 11 Apr 2012 06:28:49 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id AB7562C4003; Wed, 11 Apr 2012 06:28:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> Date: Wed, 11 Apr 2012 06:28:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0lk41nqg9o.fsf@wjh.hardakers.net> <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> To: Ralf Weber X-Mailer: Apple Mail (2.1257) Cc: "Livingood, Jason" , dnsop , Nicholas Weaver , Wes Hardaker Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:28:51 -0000 On Apr 11, 2012, at 6:02 AM, Ralf Weber wrote: >> Suggested rewrite: >>=20 >> Furthermore, a Negative Trust Anchor MUST only be used for a >> short duration, perhaps for a day or less. Implementations MUST >> require an end-time configuration associated with any negative >> trust anchor. Implementations SHOULD limit the maximum time = into >> the future to one day. In other words, the configuration >> directive will be invalid if it is missing an end-time or if the >> end time is greater than "now" plus 86400 seconds. >=20 > I disagree with that. I have seen misconfigured domains that where = misconfigured on error for a much longer time. Also process wise if the = negative trust anchors automatically get removed from the server and the = domain is still misconfigured it will go off again for the resolver = operators customers. The addition and the removal of a negative trust = anchor should be a process in the operators network and not an = automation in software. Two comments: a) If end-time is specified as a date, not an interval, you can set the = date to be 'end of epoch', so you can basically have it 'stay forever', = even if thats not advised: which would make me think the proper approach = is 'it SHOULD/MUST be a warning when a negative trust anchor with = duration longer than 1 day from current time is installed", but allow it = to be installed. If an option allows someone to really shoot themselves in the foot, and = a >1 week negative trust anchor should probably be considered that, even = if allowable it should be warned. b) Actually, I think it should also be auto removed once the condition = is fixed: Continue to attempt to validate the zone in question. When = the zone validates again, the default behavior should be to = automatically remove the negative trust anchor. From matthijs@nlnetlabs.nl Wed Apr 11 06:47:42 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BE011E80A2 for ; Wed, 11 Apr 2012 06:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuRPeczZrwMe for ; Wed, 11 Apr 2012 06:47:41 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BBE11E8141 for ; Wed, 11 Apr 2012 06:47:40 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3BDlYwl088792 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 15:47:35 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334152060; bh=90v9K+AnRs8WnQ8k90zFmfyMyDfGrmxfZN7T9ew6rww=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=g1BEZLqCw3YQqJS6fKu/H9gaKlqKMnnPiMzwqrXPu1kNMDsq4yYTcypXzsyCDqmri atS4VZ2A8VqWKPYptxEyJqtUKUvVwthRj/qOOMoistCBIVVUoKnYQVSN2Goyj4wboG sO71qnWG9OgCY+K9ZrmHUhAcPgq5ZCeicgyzn7YY= Message-ID: <4F858B75.8010909@nlnetlabs.nl> Date: Wed, 11 Apr 2012 15:47:33 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: ah@TR-Sys.de References: <201204042241.AAA29406@TR-Sys.de> In-Reply-To: <201204042241.AAA29406@TR-Sys.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 11 Apr 2012 15:47:35 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:47:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 04/05/2012 12:41 AM, Alfred � wrote: > After a long delay, I have revisited the > "DNSSEC Operational Practices, Version 2" I-D and performed > a full review from scratch for the most recent draft version, > draft-ietf-dnsop-rfc4641bis-10. A very long delay, the wglc ended somewhere last year... > For convenience, and to accommodate message size limitations, > I have split my review comments into 3 parts: > > (A) Technical flaws, > (B) Editorial flaws, and > (C) Editorial nits > > Only the first two parts will be sent to the dnsop list, > the bulky third part is given as fodder to the authors only. > > Here we go with part (A); > please consider to provide feedback for the items below on the list. I have omitted all items that I have adopted without feedback necessary. In other words, all omitted items will make the next version of the document. > (A) Technical flaws > ++++++++++++++++++++ > (A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA > > Given the pressure by important governmental/international > stakeholders in support of Elliptic Curve (EC) cryptography > and the large amount of DNS response packet space consumed > by RSA (and DSA) keys and signatures, I strongly recommend > to give the reader a glimpse of perspective on ECDSA usage with > DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor > queue in state "RFC-Editor" and already supported by major DNS > implementations. A glimpse perhaps, but we (the editors) think your suggested is too strong. Also, we think that there is too little experience with ECDSA to make good observations. Which major DNS implementations are you referring to that have already implemented ECDSA? > For instance, it would IMO make sense to add at the end of Section > 3.4.1 or 3.4.2 a new paragraph like this: > > | Operators concerned with performance and key/signature size issues > | related to RSA and DSA usage with DNSSEC should follow the ongoing > | standardization -- and consequential implementation -- progress for > | the use of digital signature algorithms based on Elliptic Curve (EC) > | Cryptography with DNSSEC, which promises much shorter key and > | signature sizes than RSA/DSA for equivalent cryptographic strenght. > | In particular, the use of ECDSA with DNSSEC is now specified > | [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in > | the foreseeable future. We would like to say that ECDSA is out of scope for Version 2 of DNSSEC Operational Practices. We suggest the following text at the end of 3.4.1, which summarizes ECDSA and will not be discussed here. Also at the moment of publication, digital signature algorithms based on Elliptic Curve (EC) Cryptography with DNSSEC [] are being standardized and implemented. The use of EC has benefits in terms of size. On the other hand, one has to balance that against the amount of validating resolver implementation that will not recognize EC signatures and thus treat the zone as insecure. Beyond the observation of this trade-off, we will not discuss further considerations. > (A.8) Section 4.3.5.1, Figure 9 -- wrong child SOA serials? > > According to the prose in this section, as far as I understand it, > the "redelegation" phase should happen with stable client zone data > at both the old (A) and new (B) DNS operator and only change the > parent zone -- or have I missed something important there? The only client zone data that needs to be stable is the NS and DNSKEY RRsets. So, the serial may be incremented during the pre-publish and redelegation phases. However, for clarity it might indeed be better to take over your suggestion. > (A.9) Section 4.4 -- technical clarification > > Since RFC 2308 specified the caching behavior for negative responses, > which arguably do not deliver "data", the text in Section 4.4 needs > a small addition to properly represent the negative caching behavior > as well: > > OLD: > > Without DNSSEC, all times in the DNS are relative. The SOA fields > REFRESH, RETRY, and EXPIRATION are timers used to determine the time > | elapsed after a slave server synchronized with a master server. The > | Time to Live (TTL) value and the SOA RR minimum TTL parameter > | [RFC2308] are used to determine how long a forwarder should cache > | data after it has been fetched from an authoritative server. By > ^^^^ > using a signature validity period, DNSSEC introduces the notion of an > absolute time in the DNS. Signatures in DNSSEC have an expiration > date after which the signature is marked as invalid and the signed > data is to be considered Bogus. > > NEW: > > Without DNSSEC, all times in the DNS are relative. The SOA fields > REFRESH, RETRY, and EXPIRATION are timers used to determine the time > elapsed after a slave server synchronized with a master server. The > Time to Live (TTL) value and the SOA RR minimum TTL parameter > [RFC2308] are used to determine how long a forwarder should cache > | data after it has been fetched from an authoritative server or > ^^^ > | negative responses, respectively. By using a signature validity > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > period, DNSSEC introduces the notion of an absolute time in the DNS. > Signatures in DNSSEC have an expiration date after which the > signature is marked as invalid and the signed data is to be > considered Bogus. Ok, although I have made it: > | data (or negative responses) after it has been fetched from an > ^^^^^^^^^^^^^^^^^^^^^^^^ > | authoritative server or. By using a signature validity > (A.10) Section 5.1, ff. -- term "RRlabel" needs clarification > > I have trouble understanding what the term "RRlabel" means and > what precisely the draft wants to state in the text passages > where it is used. This term, used as a single word, is very > uncommon and has not been used in published RFCs so far, and > it is nowhere formally defined in this memo; yet it recurs for > a total of 8 instances in Sections 5.2, 5.3.1, and 5.3.3. > > The first occurrence is in the first sentence of the last para > of Section 5.1, which says: > > | The NSEC3 record uses a hashing method of the requested RRlabel. > > If the draft wants to introduce a new term, it should precisely > define it upon first usage (or in a terminology section). > I also do not fully understand what "requested" means here -- > a QNAME in a DNS query? (that's not a 'label' in the sense of > STD 13, but a FQDN); subsequent text in Section 5.2 (3rd para): > > | For large zones where there is an implication of "not readily > | available" RRlabels, such as those where one has to sign a non- > | disclosure agreement before obtaining it, NSEC3 is preferred. [...] > > ... might even be understood as indicating 'request for registration' > (via a registrar into a zone that has restrictive policies on what > relative domain names can be registered). That needs clarification. > > But, firstly, back to the last para of Section 5.1! > > Upon further investigation: what's hashed for NSEC3 aren't single > labels, but the fully qualified domain names registered in the zone > -- the details are specified in Section 7.1 of RFC 5155, and also > quoted shortly in Section 5.3.1 of the draft. And these are not > the domain names "requested" in DNS queries (QNAMEs) -- unless these > happen to match FQDNs for which RFC 5155 has made mandatory the > generation of NSECe RRs (in particular, for secure delegations > and for wildcards), or for which the Opt-out policy in force has > chosen to generate NSEC3 records. > Thus, as long as there is no sensical definition of the term, maybe > "the requested RRlabels" might better be replaced by > "the names registered in the zone". > > Note that the subsequent instances of "RRlabel" in Sections 5.2 > (1st and 3rd para, 1x each), 5.3.1 (1st para, 2x), and 5.3.3 > (2nd para, 3x) will likely need text adjustments as well. I have replaced all occurrences by "name". Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhYt1AAoJEA8yVCPsQCW5CoAH/1sThiCyT78pXdfORyAXe6NB lQnpJttZh2Uw9V7Ab80mUwgS1SpMnUwmv+UGhsOza22qiW1Cx8PnKkoh5n4MyhB/ gm29+yKoCz32Ie/4RqvfQ5ZzYmMmrdKOU0KbMFE9t+6xmfdjqiIGoh/8YEhb45ve LRF5Pmw/aKUwTESsC2PG7jycL3sFVr28ufM7rH+WqVreKcc7Jm49KV4rSA8H2nE5 FRP9O/W3EtcXLoJz0qOQ74EZlAcLKDbrIJGtlHgJwq6BR3bKnpJ0HpeVzT4Fo2dx CkAQtRZtLTYyc1pJzD9723gzrZoccuO6g93HHNBlxvu+1r9CSuP07EQqFp2EhEk= =Au1p -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Apr 11 06:48:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8DA11E815D for ; Wed, 11 Apr 2012 06:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LylSUqchOWE8 for ; Wed, 11 Apr 2012 06:48:29 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9468711E8141 for ; Wed, 11 Apr 2012 06:48:28 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3BDmQlN088856 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 15:48:27 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334152108; bh=1Q4WjFhoFqkyGVatgqEZ6eoSnjty9tTFlQqrJo+ITTI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=FUi1kNfFjgqUJ4rlNT0+ZwYw3nl9uER3jBXmnycblbuABzBRo+FeaS4iZ25bkYlzQ qLJw6Ngw/mrIdliJibCdPJgCVqzMFmcHL7nI4Lseveh8vtG9E/55aKmBVVSLkMWHLQ y9I10FiEVWiKWeu58ru6TxvNUvKZQX7XIac75vRs= Message-ID: <4F858BAA.10602@nlnetlabs.nl> Date: Wed, 11 Apr 2012 15:48:26 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: ah@TR-Sys.de References: <201204042248.AAA29446@TR-Sys.de> In-Reply-To: <201204042248.AAA29446@TR-Sys.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 11 Apr 2012 15:48:27 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:48:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2012 12:48 AM, Alfred � wrote: > Here we go with part (B); if deemed necessary, please consider > to provide feedback for the items below on the list. Again, all items that are adopted without feedback necessary have been omitted from this reply. > (B) Editorial flaws > ++++++++++++++++++++ > > (B.1) general -- terminology > > The draft should make more consistent use of signature timing terms. Adopted your suggestions. > (B.2) Section 1 -- outdated text > > The 2nd paragraph of Section 1 says: > > During workshops and early operational deployment, operators and > system administrators have gained experience about operating the DNS > with security extensions (DNSSEC). This document translates these > experiences into a set of practices for zone administrators. At the > | time of writing -the root has just been signed and the first secure > | delegations are provisioned- there exists relatively little > experience with DNSSEC in production environments below the top-level > domain (TLD) level; this document should therefore explicitly not be > seen as representing 'Best Current Practices'. Instead, ... > > The tagged phrase seems to be outdated now and should be updated > to reflect te successful deployment of DNSSEC in the Root zone and > many TLDs. As of today, the ICANN TLD DNSSEC Report (2012-04-03) > ( ) says: > > | Summary > | > | * 313 TLDs in the root zone in total > | * 91 TLDs are signed; > | * 85 TLDs have trust anchors published as DS records in the root zone; > | * 4 TLDs have trust anchors published in the ISC DLV Repository. > > So I suggest to modify the dangling sentence in the above quote to say: > > During workshops and early operational deployment, operators and > system administrators have gained experience about operating the DNS > with security extensions (DNSSEC). This document translates these > | experiences into a set of practices for zone administrators. Although > | the DNS Root has been signed since July 15, 2010 and now more than 80 > | secure delegations are provisioned in the root, at the time of writing > there still exists relatively little experience with DNSSEC in > production environments below the top-level domain (TLD) level; this > document should therefore explicitly not be seen as representing > 'Best Current Practices'. Instead, ... Yes, that's what you get when a document is laying around for so long. It used to be "the root is being signed" ;). But I have adopted your change. > (B.3) Section 1.2 -- clarification > > With respect to item (B.1) above, I suggest to even better clarify the > definition of "Signature validity period" in Section 1.2 (1st bullet): > > OLD: > | o "Signature validity period" The period that a signature is valid. > | It starts at the time specified in the signature inception field > | of the RRSIG RR and ends at the time specified in the expiration > | field of the RRSIG RR. > > NEW: > | o "Signature validity period" The time interval during which a > | signature is valid. It starts at the (absolute) time specified in > | the signature inception field of the RRSIG RR and ends at the > | (absolute) time specified in the expiration field of the RRSIG RR. I don't see why this should be changed. Do you prefer interval over period? Do you want the clarify that the times are absolute? This is a non-issue in my opinion. > (B.5) Section 4.1.1.1 -- clarifications > > a) The preamble to Figure 1 says: > > | Pre-Publish key rollover involves four stages as follows: > > For clarity on first reading, I suggest to make this clause a bit > more precise, in mentioning the role of the ZSKs in the figure: > > vvvvvvvvvvvvvvvvvvvvvvv > | Pre-Publish key rollover from key 10 to key 11 involves four stages > | as follows: > > IMHO, there is no need to repeat a similar addition for subsequent > figures because a sequential reader of the memo will take note of > the elaborations below Figure 1 and not need to be made aware of > similar context in the other rollover figures. Or Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves... > (B.6) Section 4.1.5, list items below Figure 5 -- clarifications > > (c) > In subsequent list items, I suggest to clarify the text -- where > becessary -- by making the distinction between "old" and newer data > more explicit, and -- in two instances -- an indication of the > possibility of more than one DNSKEY RR (as in the Figure, due to the > split KSK/ZSK scheme used) should be indicated by talking about the > "DNSKEY RRset": > > | new DNSKEY: After the cache data has expired, the new key can be > added to the zone. > --- vvvvv > | new DNSKEY: After the old cache data has expired, the new key can be > added to the zone. What is an old cache? I suggest "After the old data has expired from cache" here. > | DNSKEY removal: After the cache data for the DS has expired, the old > | algorithm can be removed. This time the key needs to be removed > | first, before removing the signatures. > --- vvvvv > | DNSKEY removal: After the cache data for the old DS has expired, the "old DS RRset" > | old algorithm can be removed. This time the old key needs to be > vvvvv ^^^^^ > | removed first, before removing the old signatures. > Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhYuqAAoJEA8yVCPsQCW5mXMH/ROOolBIhhyLQqq+8OEbaFxn 1czQaoqxF/O7Uzwe5BID3+3a5aCFBh2RouBwkdSdFHurLPTnjEH0L1vOM76rKduM QfOZlgk96LT3wAAQUYD63fMonT40q+erxqfgYNKfDrDMlwcsTeQDQkVgoTJX6xyR y9CJaWyvHaybfDT04mSkzYvOXuUukfUJEfwD+ErCuSifGluD40OacnZk0s9euxvn iK2fnZMhu81OXpztSEuDlk6XyWgeIfZZUsPHi4YpJorTT6f/fgMibYOvZFQwd1AW JufSOMEthXiyXUldZf4Fg4A6RoUVGyigGsBL6TK6x+/721ujE2Va8OXal48LsLo= =Pe21 -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Wed Apr 11 07:16:30 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BD011E80B0 for ; Wed, 11 Apr 2012 07:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dbL0Td6S6mm for ; Wed, 11 Apr 2012 07:16:29 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70211E809C for ; Wed, 11 Apr 2012 07:16:29 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57992) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SHyLR-0005Jj-Sx (Exim 4.72) (return-path ); Wed, 11 Apr 2012 15:16:26 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SHyLR-0005jK-Nm (Exim 4.67) (return-path ); Wed, 11 Apr 2012 15:16:25 +0100 Date: Wed, 11 Apr 2012 15:16:25 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Griffiths, Chris" In-Reply-To: <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> Message-ID: References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop , "Livingood, Jason" , Wes Hardaker Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:16:30 -0000 Griffiths, Chris wrote: > On Apr 10, 2012, at 8:11 PM, Wes Hardaker wrote: > > > Suggested rewrite: > > > > Furthermore, a Negative Trust Anchor MUST only be used for a > > short duration, perhaps for a day or less. > > Agreed. Maximum time supported makes sense to me. This only makes sense if the negative trust anchor is for a third party domain. There are situations where it makes sense to use negative trust anchors covering your own domains, and these might be necessary for a long period of time (because that would require a difficult upgrade or extensive renaming). There are more use cases than just the NASA screwup scenario. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Southwest Rockall: Northwesterly 5 or 6. Rough or very rough. Rain or showers. Moderate or good. From fanf2@hermes.cam.ac.uk Wed Apr 11 07:20:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7575B11E809C for ; Wed, 11 Apr 2012 07:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyiKmksFsDvh for ; Wed, 11 Apr 2012 07:20:52 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id A3B1D21F8584 for ; Wed, 11 Apr 2012 07:20:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46947) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SHyPi-0004Rx-G3 (Exim 4.72) (return-path ); Wed, 11 Apr 2012 15:20:51 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SHyPi-0006OO-Tp (Exim 4.67) (return-path ); Wed, 11 Apr 2012 15:20:50 +0100 Date: Wed, 11 Apr 2012 15:20:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Shane Kerr In-Reply-To: <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> Message-ID: References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop Subject: Re: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:20:53 -0000 Shane Kerr wrote: > > For example, I know someone who regularly forgets to re-sign his zones. That's just stupid. There are a lot of sensible words in Jason's draft to say that negative trust anchors should not be used as a long-term workaround for some third party's persistent incompetence. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Northwest 3 or 4, increasing 5 or 6. Moderate or rough, but slight in far south for a time. Occasional rain. Moderate or good, occasionally poor later. From shane@isc.org Wed Apr 11 07:33:38 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A5311E8080 for ; Wed, 11 Apr 2012 07:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzAlM-4248qR for ; Wed, 11 Apr 2012 07:33:38 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1847A11E807F for ; Wed, 11 Apr 2012 07:33:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id BCDD25F9899; Wed, 11 Apr 2012 14:33:25 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:610:719:1:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D305C216C31; Wed, 11 Apr 2012 14:33:22 +0000 (UTC) (envelope-from shane@isc.org) Date: Wed, 11 Apr 2012 16:33:11 +0200 From: Shane Kerr To: Nicholas Weaver Message-ID: <20120411163311.3634fa97@shane-eeepc.home.time-travellers.org> In-Reply-To: References: <0lk41nqg9o.fsf@wjh.hardakers.net> <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:33:38 -0000 Nicholas, On Wednesday, 2012-04-11 06:28:49 -0700, Nicholas Weaver wrote: > b) Actually, I think it should also be auto removed once the > condition is fixed: Continue to attempt to validate the zone in > question. When the zone validates again, the default behavior should > be to automatically remove the negative trust anchor. That's a very good idea, at least as an option. (I know some administrators never want anything to happen automatically. Some people love extra work, or at least are paranoid about computers getting stuff wrong.) -- Shane From shane@isc.org Wed Apr 11 07:48:50 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EB611E80B2 for ; Wed, 11 Apr 2012 07:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4qqT0XPtHS6 for ; Wed, 11 Apr 2012 07:48:49 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BD80E11E8074 for ; Wed, 11 Apr 2012 07:48:49 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 056DC5F98AF; Wed, 11 Apr 2012 14:48:34 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:610:719:1:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 24CF9216C33; Wed, 11 Apr 2012 14:48:30 +0000 (UTC) (envelope-from shane@isc.org) Date: Wed, 11 Apr 2012 16:48:20 +0200 From: Shane Kerr To: Tony Finch Message-ID: <20120411164820.678bcf96@shane-eeepc.home.time-travellers.org> In-Reply-To: References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop Subject: Re: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:48:50 -0000 Tony, On Wednesday, 2012-04-11 15:20:50 +0100, Tony Finch wrote: > Shane Kerr wrote: > > > > For example, I know someone who regularly forgets to re-sign his > > zones. > > That's just stupid. There are a lot of sensible words in Jason's draft > to say that negative trust anchors should not be used as a long-term > workaround for some third party's persistent incompetence. Okay, that was an extreme example, but nevertheless if your customers want service to a domain that works if DNSSEC is disabled, what choice do you have? What the ISP experiences: Customer: "I can't get to supercute.newtld!!!! WHINE!!!" ISP: "Yes, sorry, they have a technical problem with their domain and it is not secure." Customer: "But it works from the office!!!" ISP: "Your office does not have DNSSEC validation enabled, and is not protecting you." Customer: "You suck! I'm going to EvilCompetitor, Inc.!!!" What the customer experiences: Customer: "Sorry to disturb you, but my most loved people in the world can't get to the one web site that brings joy into their lives." ISP: "The dilithium crystals in the Heisenberg compensators of that PADD are misaligned." Customer: "Okay... but I tried it from work and it is okay." ISP: "HAHAHA!! Trust us, we know what we're talking about and nobody else does. You can't really see this site from work, it is an evil impostor!!!" Customer: "Riiiight..." Disabling DNSSEC validation for broken domains seems completely rational, at least for some types of brokenness. -- Shane From jim@rfc1035.com Wed Apr 11 07:59:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0311E8122 for ; Wed, 11 Apr 2012 07:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im8cRq8ha3bX for ; Wed, 11 Apr 2012 07:59:37 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C44211E80E3 for ; Wed, 11 Apr 2012 07:59:36 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id B5708CBC451; Wed, 11 Apr 2012 15:59:34 +0100 (BST) Message-Id: <7445B3B2-71EF-4300-9A79-BD527EB395C8@rfc1035.com> From: Jim Reid To: Shane Kerr In-Reply-To: <20120411164820.678bcf96@shane-eeepc.home.time-travellers.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Apr 2012 15:59:34 +0100 References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> <20120411164820.678bcf96@shane-eeepc.home.time-travellers.org> X-Mailer: Apple Mail (2.936) Cc: Tony Finch , dnsop Subject: [DNSOP] when dnssec validation fails X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:59:37 -0000 On 11 Apr 2012, at 15:48, Shane Kerr wrote: > Disabling DNSSEC validation for broken domains seems completely > rational, at least for some types of brokenness. +1 The problem here is this becomes a local policy/configuration matter and the experience you outlined still occurs Shane. Sometimes things will work (for some definition of work) even if DNSSEC validation fails, sometimes they won't. I don't see any easy answers. It would be nice if browsers (say) popped up a dialogue box which said "I'm not sure about this IP address, do you feel lucky?" when a validation failed so the end user could decide how to proceed. But this would be unpopular and almost certainly get ignored or switched off. And of course it does nothing for all the other application software that might like to know if they're handling validated DNS data or not. From fanf2@hermes.cam.ac.uk Wed Apr 11 08:21:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4DD21F855F for ; Wed, 11 Apr 2012 08:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pANrarOgsbFQ for ; Wed, 11 Apr 2012 08:21:34 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id F07F321F8566 for ; Wed, 11 Apr 2012 08:21:33 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56324) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SHzMR-0003oj-qg (Exim 4.72) (return-path ); Wed, 11 Apr 2012 16:21:31 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SHzMR-0007Da-9C (Exim 4.67) (return-path ); Wed, 11 Apr 2012 16:21:31 +0100 Date: Wed, 11 Apr 2012 16:21:31 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Jim Reid In-Reply-To: <7445B3B2-71EF-4300-9A79-BD527EB395C8@rfc1035.com> Message-ID: References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> <20120411164820.678bcf96@shane-eeepc.home.time-travellers.org> <7445B3B2-71EF-4300-9A79-BD527EB395C8@rfc1035.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop , Shane Kerr Subject: Re: [DNSOP] when dnssec validation fails X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:21:35 -0000 Jim Reid wrote: > On 11 Apr 2012, at 15:48, Shane Kerr wrote: > > > Disabling DNSSEC validation for broken domains seems completely > > rational, at least for some types of brokenness. > > +1 I agree, and this is what the draft says. I suppose this sub-argument is over where to draw the line, which indicates to me that the draft should not go into detail about policy since this will depend a lot on the relative bloody-mindedness of operators and their user bases. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Southwest Rockall: Northwesterly 5 or 6. Rough or very rough. Rain or showers. Moderate or good. From wjhns1@hardakers.net Wed Apr 11 09:09:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC64C21F853B for ; Wed, 11 Apr 2012 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8HUjVGBoPjj for ; Wed, 11 Apr 2012 09:09:17 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED83121F853A for ; Wed, 11 Apr 2012 09:09:16 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 8EB0C469; Wed, 11 Apr 2012 09:09:15 -0700 (PDT) From: Wes Hardaker To: Nicholas Weaver References: <0lk41nqg9o.fsf@wjh.hardakers.net> <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> Date: Wed, 11 Apr 2012 09:09:15 -0700 In-Reply-To: (Nicholas Weaver's message of "Wed, 11 Apr 2012 06:28:49 -0700") Message-ID: <0laa2i6yj8.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: Ralf Weber , "Livingood, Jason" , dnsop , Wes Hardaker Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:09:18 -0000 >>>>> On Wed, 11 Apr 2012 06:28:49 -0700, Nicholas Weaver said: NW> a) If end-time is specified as a date, not an interval, you can set NW> the date to be 'end of epoch', so you can basically have it 'stay NW> forever', even if thats not advised That's why I suggested the upper limit, and the config would need to be time based. IE: NTA example.com Thu Apr 12 09:06:42 PDT 2012 Note that if you really need to keep some trust anchors around for a long time, it's still very hackable via a cron script: rm /etc/long-ntas.conf for i in example.com other.example.com ; do echo "NTA $i `date -d '+1 day'`" >> /etc/long-ntas.conf done # restart/reconf/etc here [btw, I said "one day" based on the original wording in the draft that implied that was a reasonable upper limit. I'm not sure that one day is the right period actually] [btw2, I'd expect many (most?) implementations to ignore the SHOULD :-( ] -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Wed Apr 11 09:14:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1421F855B for ; Wed, 11 Apr 2012 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlf3clXCBfQl for ; Wed, 11 Apr 2012 09:14:28 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A58B21F8564 for ; Wed, 11 Apr 2012 09:14:28 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 4431266A; Wed, 11 Apr 2012 09:14:28 -0700 (PDT) From: Wes Hardaker To: Shane Kerr References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> Date: Wed, 11 Apr 2012 09:14:27 -0700 In-Reply-To: <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> (Shane Kerr's message of "Wed, 11 Apr 2012 13:40:23 +0200") Message-ID: <0l62d66yak.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop Subject: Re: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:14:29 -0000 >>>>> On Wed, 11 Apr 2012 13:40:23 +0200, Shane Kerr said: SK> For example, I know someone who regularly forgets to re-sign his zones. SK> Yes, he knows he should set BIND up to re-sign them automatically or SK> perhaps use zkt, but that takes time and it's just his own vanity SK> domain. Personally I would like to set a negative trust anchor for his SK> zones until such time as he sets something like this up, since I know SK> that the signatures will expire in a few months and break the zone for SK> me at that time. I'm sure ISC could stand up a helpful service to the world called DLNV that could keep your friends zone permanently registered in it. If we're going down the broken-trust-anchor road, we might as well consider a dynamic-lookup mechanism. You know it's coming. SK> Plus, I know it is surprising to folks on this list, but some zones do SK> not have full time administrators, and may have to wait until admin SK> staff get back on Monday morning until they are fixed - or perhaps even SK> until the one "computer guy" at a company gets back from vacation. I'm not sure that installing a permanent "don't ever validate this" configuration token is a good thing for that situation. If a zone is signed and fails validation because of lack of responsibility then the zone needs to be broken. We don't, for example, provide a "for this zone, the real name servers are actually somewhere.else.example.com because the zone operator is on vacation and didn't update the registry". We could. We could offer "use this instead for A, AAAA, MX, DS, ...". A slippery slope this way comes. -- Wes Hardaker SPARTA, Inc. From warren@kumari.net Wed Apr 11 09:32:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7295B21F8594 for ; Wed, 11 Apr 2012 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qrZgqmCkP8d for ; Wed, 11 Apr 2012 09:32:20 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A3E3321F84F3 for ; Wed, 11 Apr 2012 09:32:17 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4EACC1B40046; Wed, 11 Apr 2012 12:32:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> Date: Wed, 11 Apr 2012 12:32:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4640D044-31F2-435D-9F9C-9E3F883801F0@kumari.net> References: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> To: Joe Abley X-Mailer: Apple Mail (2.1084) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:32:21 -0000 On Apr 4, 2012, at 8:41 AM, Joe Abley wrote: >=20 > On 2012-04-04, at 08:20, William F. Maton Sotomayor wrote: >=20 >> It seems that after delivering my presentation on subsequent = AS112=20 >> delegations in Quebec City, I hadn't recalled what the group thought = about=20 >> adopting this work as a dnsop item. So, I'm soliciting feedback on = this=20 >> request. I have posted version 03 for your consideration. >=20 > I think that we need a better mechanism to avoid lame delegations to = the AS112 servers, given their loosely-coordinated nature. The add/drop = problem for those servers (the difficulty in requesting zone changes = across from a potentially wide and unknown population of server = administrators, and being effectively unable to measure whether those = changes are complete) is a fundamental weakness in the 112 project as it = is operated today. >=20 > I like the idea that came up in Qu=E9bec (which I shall attribute to = Warren Kumari since I've seen other people do that, although I was not = in the room at the time) that the add/drop problem is a lot simpler if = every AS112 node hosts the zone Yah, guilty as charged, although you may be thinking that I had thought = this through more / wasn't just spouting the first thing that came into = ma heid... >=20 > $ORIGIN . > @ SOA ... > NS something > NS sensible >=20 > and answers authoritatively on the addresses corresponding to = "something" and "sensible", returning NXDOMAIN for everything in the = entire namespace apart from . (for which they ought never receive = queries anyway). This is ugly to some eyes, but it works for domainers = and it ought to work for us too. Any zones that were subsequently = delegated to "something" and "sensible" (e.g. as part of an IANA action) = would be immediately supported with no need for changes on any of the = nodes offering service for "something" and "sensible". And after some though I posted this on the as112 list: = https://lists.dns-oarc.net/pipermail/as112-ops/2011-July/000212.html A number of the operators seemed supportive (and I'm fairly sure I = threatened to write it up as a draft but then got sidetracked)... >=20 > Given the installed base of AS112 servers, and again given their = loosely-coordinated nature, I would suggest assigning one new IPv4 /24 = and one new IPv6 /48 prefix, with both "something" and "special" getting = one address out of each. We could then encourage AS112 operators to host = the empty root zone on nameserver listening to the appropriate = addresses, originating the new prefixes from AS 112, using the mailing = list and associated resources mainly managed by William. >=20 > Once by some measure the new prefixes are propagating and nameservers = are answering, we could redelegate the zones currently delegated to = blackhole-1.iana.org and blackhole-2.iana.org to the new servers, and = retire 192.175.48.0/24. >=20 > I think renumbering is worthwhile since we have no way of measuring = the extent to which AS112 servers are actually deployed (e.g. there may = be many deployed for private use inside ASes that we can't easily see.) = Enough public AS112 server operators are responsive on William's list = that I don't see a problem in getting sufficient buy-in to a new scheme = such as this to make it viable quickly, however. >=20 > I think the work to be done in dnsop could be summarised as: >=20 > - update RFC 6304 and 6305 as necessary > - write something that cleans up and unifies the various registries = that currently contain RFC 6303-like names, with appropriate IANA = actions (ipv4-cull contains some references in section 2, see also = draft-cheshire-dnsext-special-names)=20 > - write something that provides guidance for future document authors = on when they should specify an IANA action to add a new zone to the = grand unified as112 registry and cause a delegation to "something" and = "sensible" to happen. >=20 > This document (as112-cull) attempts to do some of this work, but I = don't see a reason to bite off small mouthfuls if we can expend a small = amount of extra effort and eat the whole sandwich at once. >=20 > I am very happy to spend time on this. Me too. This seems both interesting *and* useful... W >=20 >=20 > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 From joe.abley@icann.org Wed Apr 11 09:56:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D021F84D2 for ; Wed, 11 Apr 2012 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZy7vu9Ylkm7 for ; Wed, 11 Apr 2012 09:56:14 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9652221F84CF for ; Wed, 11 Apr 2012 09:56:14 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 11 Apr 2012 09:56:14 -0700 From: Joe Abley To: Wes Hardaker Date: Wed, 11 Apr 2012 09:56:13 -0700 Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: Ac0YBAEMyw4VGANRS3eNBHeQkqjdTw== Message-ID: <90BF4A42-4645-4584-963B-6B1DC9D6DA1C@icann.org> References: <0lk41nqg9o.fsf@wjh.hardakers.net> <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> <0laa2i6yj8.fsf@wjh.hardakers.net> In-Reply-To: <0laa2i6yj8.fsf@wjh.hardakers.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_4F596020-9BE5-4425-8DAF-EA34E21F0FCB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Livingood, Jason" , Ralf Weber , Nicholas Weaver , dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:56:15 -0000 --Apple-Mail=_4F596020-9BE5-4425-8DAF-EA34E21F0FCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-04-11, at 12:09, Wes Hardaker wrote: >>>>>> On Wed, 11 Apr 2012 06:28:49 -0700, Nicholas Weaver = said: >=20 > NW> a) If end-time is specified as a date, not an interval, you can = set > NW> the date to be 'end of epoch', so you can basically have it 'stay > NW> forever', even if thats not advised >=20 > That's why I suggested the upper limit, and the config would need to = be > time based. IE: >=20 > NTA example.com Thu Apr 12 09:06:42 PDT 2012 I realise this is just a thought experiment, but if there are dates to = be specified in the presentation of new RRs then they should probably be = in the same format as those used in RRSIGs. I would have liked to say = RFC3339, but consistency with the rest of the DNSSEC spec (which = unfortunately did not use 3339) is probably more important. I agree that negative trust anchors ideally need an expiration date. I confess I have not been following this thread very closely, and the = discussion of resource records seems like something that has arisen = outside the text being reviewed. I presume that someone has had the idea = is to publish an NTA (or whatever) in a lookaside zone that a resolver = could be configured to use, rather than in a parent zone (since a parent = could just remove a DS RRSet). Such a lookaside zone could be = provisioned using dynamic updates or static data or whatever suits the = administrator. If negative trust anchors (or, more generally, signalling to instruct a = validator to ignore a bad signature) is to be published in the DNS, then = the NTA (or whatever) records SHOULD be signed such that a relying = validator can trust the signalling. =46rom the point of view of troubleshooting, it'd also be nice to have = the option of encoding a reason (e.g. so that NTAs left in a zone beyond = their expiry could be viewed by others for diagnostic purposes). And if = there was an inception date also specified, that would surely also help. ; Hopcount's resolvers are configured to look for NTAs in the zone = nta.hopcount.ca. $ORIGIN nta.hopcount.ca. ; example.com's DNSSEC is broken, let's not use it for a day example.com NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345] = jabley@hopcount.ca" example.com RRSIG ... I might also wonder whether such a record might usefully be returned in = the additional section of a response that is a result of a signature = being ignored. This would allow a stub resolver to tell that signatures = are being deliberately ignored by the validator, without having to know = explicitly what lookaside zone the validator is using. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45786 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN SOA ;; ANSWER SECTION: example.com. 3462 IN SOA dns1.icann.org. hostmaster.icann.org. = 2011063333 7200 3600 1209600 3600 ;; ADDITIONAL SECTION: example.com.nta.hopcount.ca. 3462 IN NTA 20120412162716 20120411162716 = "ticket [HOPCOUNT-12345] jabley@hopcount.ca" Joe --Apple-Mail=_4F596020-9BE5-4425-8DAF-EA34E21F0FCB Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNDExMTY1NjEzWjAjBgkqhkiG9w0BCQQxFgQUv8W+f2ZwlJL9IYOYpzbiwXP1UwAwgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB ALJ3OwA3jpn2TGqX74Zi5JWngQulIDGpSPKLmX3tSPpP8uiq0fFVmy727JPd+ivEBfL8xlrkCisF CnfikIl+3K40t09+B0yx0itDzXeUmhH1gJnq0hsGep5M14OMMs2xAsHEHysgFea794XScDHZjMkR FT0RMUPxY2ZOWMTFI5eDR7XVDfc+s0Vf2YrFllonGwFByDQouiNg14OSqX1D43OTw+/3rJS1yF4d j7gUycuySVpSIOAAguxDwEJZyb9vhQT5zU3R4AdW2/ox3tuJkccVUFlHhOuRwpvr7wyU84aoFjBx /k7G+VMa5XLGszqcyuzu3HMn+AsAqu35uTggSyUAAAAAAAA= --Apple-Mail=_4F596020-9BE5-4425-8DAF-EA34E21F0FCB-- From el@lisse.NA Wed Apr 11 10:45:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF40611E80B6 for ; Wed, 11 Apr 2012 10:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+9AtCLv60KL for ; Wed, 11 Apr 2012 10:45:23 -0700 (PDT) Received: from oshiyapula.omadhina.co.na (oshiyapula.omadhina.co.na [196.216.41.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2D811E809A for ; Wed, 11 Apr 2012 10:45:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by oshiyapula.omadhina.co.na (Postfix) with ESMTP id AE166DD1863; Wed, 11 Apr 2012 18:45:13 +0100 (WAT) X-Virus-Scanned: amavisd-new at omadhina.co.na Received: from oshiyapula.omadhina.co.na ([127.0.0.1]) by localhost (oshiyapula.omadhina.co.na [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L5YSqw5l8rp; Wed, 11 Apr 2012 18:45:13 +0100 (WAT) Received: from [192.168.0.23] (practice [196.1.29.170]) by oshiyapula.omadhina.co.na (Postfix) with ESMTP id 0BAEEDD185C; Wed, 11 Apr 2012 18:45:12 +0100 (WAT) Message-ID: <4F85C328.304@lisse.NA> Date: Wed, 11 Apr 2012 18:45:12 +0100 From: Dr Eberhard Lisse Organization: Dr Eberhard W Lisse User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060308 Thunderbird/1.5.0.2 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: joe.abley@icann.org References: <0lk41nqg9o.fsf@wjh.hardakers.net> <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> <0laa2i6yj8.fsf@wjh.hardakers.net> <90BF4A42-4645-4584-963B-6B1DC9D6DA1C@icann.org> In-Reply-To: <90BF4A42-4645-4584-963B-6B1DC9D6DA1C@icann.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org, el@lisse.NA Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: el@lisse.NA List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:45:24 -0000 Joe on 2012-04-11 17:56 Joe Abley said the following: [...] > ; example.com's DNSSEC is broken, let's not use it for a day > example.com NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345] jabley@hopcount.ca" > example.com RRSIG ... [...] just a tiny nit to pick, would not the '@' in 'jabley@hopcount.ca' be substituted by the "origin" when you dig this? :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el@lisse.NA el108-ARIN / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Please do NOT email to this address Bachbrecht, Namibia ;____/ if it is DNS related in ANY way From joe.abley@icann.org Wed Apr 11 10:53:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65C11E80BB for ; Wed, 11 Apr 2012 10:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6he4Z-xUqbpf for ; Wed, 11 Apr 2012 10:53:47 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7591111E80B3 for ; Wed, 11 Apr 2012 10:53:47 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 11 Apr 2012 10:53:47 -0700 From: Joe Abley To: "el@lisse.NA" Date: Wed, 11 Apr 2012 10:53:45 -0700 Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: Ac0YDAtoauBkMOe9SHW2dCbqf1GEKA== Message-ID: <651D9A8C-9B6C-4305-8D7A-122190611501@icann.org> References: <0lk41nqg9o.fsf@wjh.hardakers.net> <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> <0laa2i6yj8.fsf@wjh.hardakers.net> <90BF4A42-4645-4584-963B-6B1DC9D6DA1C@icann.org> <4F85C328.304@lisse.NA> In-Reply-To: <4F85C328.304@lisse.NA> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_5D00B87E-CAC9-4E50-9561-8D9EB45432FF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:53:48 -0000 --Apple-Mail=_5D00B87E-CAC9-4E50-9561-8D9EB45432FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dr Lisse, On 2012-04-11, at 13:45, Dr Eberhard Lisse wrote: > on 2012-04-11 17:56 Joe Abley said the following: > [...] >> ; example.com's DNSSEC is broken, let's not use it for a day >> example.com NTA 20120412162716 20120411162716 "ticket = [HOPCOUNT-12345] jabley@hopcount.ca" >> example.com RRSIG ... > [...] >=20 > just a tiny nit to pick, would not the '@' in 'jabley@hopcount.ca' be > substituted by the "origin" when you dig this? :-)-O That depends on how you define the RDATA for NTA. Let's say "no". :-) Joe --Apple-Mail=_5D00B87E-CAC9-4E50-9561-8D9EB45432FF Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNDExMTc1MzQ1WjAjBgkqhkiG9w0BCQQxFgQUeslkphkuoEloDREt2Ivs/FRUU30wgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB AKHwxliqJAXm279qUzjs52Omorh/82k/SLinv26NIYMFkaxZXcLWwFPPh2ROXbJAUJATsfD685Uf mtyi/90yVtUf9DljdpVk8dsXtZwTNjGIh0MONqT/La3jbb9AmeTshNkFZAk9j5XGPFW/+EMy7FVN F24oGvlvbV4KvktA8iWYlRF+ZbZVmiB8lzcHL6BTc1ZRtLQyBoMk2hKxs/4NpNNFWP54ds/6x1t1 21WNuKA5BQuEwJdPnJaPr0tKTEb4bpJvDRt8qBZvzUL+NYU0kAQLj1eFUkbZ7co77UbANektQ8YK SrkyKE0SnQcFOLjZKkE6gThAv/TR7KZZ4TA4CuoAAAAAAAA= --Apple-Mail=_5D00B87E-CAC9-4E50-9561-8D9EB45432FF-- From paul@nohats.ca Wed Apr 11 11:00:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73D111E8098 for ; Wed, 11 Apr 2012 11:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucfmwXvkvcWR for ; Wed, 11 Apr 2012 11:00:08 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id EBD9F11E808D for ; Wed, 11 Apr 2012 11:00:07 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id CE08480335; Wed, 11 Apr 2012 14:00:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id C16CE80331; Wed, 11 Apr 2012 14:00:06 -0400 (EDT) Date: Wed, 11 Apr 2012 14:00:06 -0400 (EDT) From: Paul Wouters To: Shane Kerr In-Reply-To: <20120411164820.678bcf96@shane-eeepc.home.time-travellers.org> Message-ID: References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> <20120411164820.678bcf96@shane-eeepc.home.time-travellers.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop Subject: Re: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:00:09 -0000 On Wed, 11 Apr 2012, Shane Kerr wrote: > Disabling DNSSEC validation for broken domains seems completely > rational, at least for some types of brokenness. So someone will make a browser plugin to enable this. Let them. Paul From A.Hoenes@TR-Sys.de Wed Apr 11 12:31:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D95221F84B2 for ; Wed, 11 Apr 2012 12:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.477 X-Spam-Level: X-Spam-Status: No, score=-96.477 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ClS0CN4wdp3 for ; Wed, 11 Apr 2012 12:31:25 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 68AEA21F84AF for ; Wed, 11 Apr 2012 12:31:24 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA057052610; Wed, 11 Apr 2012 21:30:10 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA17405; Wed, 11 Apr 2012 21:30:09 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204111930.VAA17405@TR-Sys.de> To: matthijs@nlnetlabs.nl Date: Wed, 11 Apr 2012 21:30:08 +0200 (MESZ) In-Reply-To: <4F858B75.8010909@nlnetlabs.nl> from Matthijs Mekking at Apr "11, " 2012 "03:47:33" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:31:26 -0000 Matthijs, thanks for dealing with my comments so expeditiously. (This extends to the other review comments as well.) Please see a few follow-up remarks inline below. On 11 Apr 2012 15:47:33 +0200, Matthijs Mekking wrote: > Hi, > > On 04/05/2012 12:41 AM, Alfred HÎnes wrote: >> After a long delay, I have revisited the >> "DNSSEC Operational Practices, Version 2" I-D and performed >> a full review from scratch for the most recent draft version, >> draft-ietf-dnsop-rfc4641bis-10. > > A very long delay, the wglc ended somewhere last year... > >> For convenience, and to accommodate message size limitations, >> I have split my review comments into 3 parts: >> >> (A) Technical flaws, >> (B) Editorial flaws, and >> (C) Editorial nits >> >> Only the first two parts will be sent to the dnsop list, >> the bulky third part is given as fodder to the authors only. >> >> Here we go with part (A); >> please consider to provide feedback for the items below on the list. > > I have omitted all items that I have adopted without feedback necessary. > In other words, all omitted items will make the next version of the > document. So will I, again. >> (A) Technical flaws >> ++++++++++++++++++++ >> >> ... >> >> (A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA >> >> Given the pressure by important governmental/international >> stakeholders in support of Elliptic Curve (EC) cryptography >> and the large amount of DNS response packet space consumed >> by RSA (and DSA) keys and signatures, I strongly recommend >> to give the reader a glimpse of perspective on ECDSA usage with >> DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor >> queue in state "RFC-Editor" and already supported by major DNS >> implementations. > > A glimpse perhaps, but we (the editors) think your suggested is too > strong. Also, we think that there is too little experience with ECDSA > to make good observations. Which major DNS implementations are you > referring to that have already implemented ECDSA? Admittedly, "major DNS implementors" would have been better than "majot DNS implementations" at this stage. However, quoting from NIST SP 800-81r1, "Secure Domain Name System (DNSSEC) Deployment Guide", (April 2010), page 9-4: "[...] The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before Septhember 30th, 2015. ... and from the same document, on page 9-6: "The use of RSA in DNSSEC is approved until the year 2015. By this time, it is expected that Elliptic Curve Cryptigraphy will be specified in the DNSSEC. USG DNSSEC administrations should plan to migrate to the use of ECDSA (or similar) when it becomes available in DNSSEC components." ... one can see that there are strong market forces at work. The commercial pressure to qualify for USG (U.S. Government) use of networking components and software will likely lead to widespread support soon. There's nothing like "(or similar)" in view currently as an alternative. The repeated, IMHO non-rational fear of actual applicability of patent claims is not justified; the EC groups chosen have been selected carefully to make it possible to avoid the specific optimizations for GF(2^n) based EC computations that in fact *might* be covered by some patent claims -- see RFC 6090 for the detailed report that all we need is based on academic publications that predate the said patent applications. > >> For instance, it would IMO make sense to add at the end of Section >> 3.4.1 or 3.4.2 a new paragraph like this: >> >> | Operators concerned with performance and key/signature size issues >> | related to RSA and DSA usage with DNSSEC should follow the ongoing >> | standardization -- and consequential implementation -- progress for >> | the use of digital signature algorithms based on Elliptic Curve (EC) >> | Cryptography with DNSSEC, which promises much shorter key and >> | signature sizes than RSA/DSA for equivalent cryptographic strenght. >> | In particular, the use of ECDSA with DNSSEC is now specified >> | [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in >> | the foreseeable future. > > We would like to say that ECDSA is out of scope for Version 2 of DNSSEC > Operational Practices. We suggest the following text at the end of > 3.4.1, which summarizes ECDSA and will not be discussed here. > > Also at the moment of publication, digital signature algorithms > based on Elliptic Curve (EC) Cryptography with DNSSEC [] are being > standardized and implemented. The use of EC has benefits in terms > of size. On the other hand, one has to balance that against the > amount of validating resolver implementation that will not > recognize EC signatures and thus treat the zone as insecure. Beyond > the observation of this trade-off, we will not discuss further > considerations. Agreed. The idea was to raise awareness among the reader community for upcoming important developments, not to perform an evaluation, and this aim is achieved with that text. >> ... >> >> (A.10) Section 5.1, ff. -- term "RRlabel" needs clarification >> >> I have trouble understanding what the term "RRlabel" means and >> what precisely the draft wants to state in the text passages >> where it is used. This term, used as a single word, is very >> uncommon and has not been used in published RFCs so far, and >> it is nowhere formally defined in this memo; yet it recurs for >> a total of 8 instances in Sections 5.2, 5.3.1, and 5.3.3. >> >> The first occurrence is in the first sentence of the last para >> of Section 5.1, which says: >> >> | The NSEC3 record uses a hashing method of the requested RRlabel. >> >> If the draft wants to introduce a new term, it should precisely >> define it upon first usage (or in a terminology section). >> I also do not fully understand what "requested" means here -- >> a QNAME in a DNS query? (that's not a 'label' in the sense of >> STD 13, but a FQDN); subsequent text in Section 5.2 (3rd para): >> >> | For large zones where there is an implication of "not readily >> | available" RRlabels, such as those where one has to sign a non- >> | disclosure agreement before obtaining it, NSEC3 is preferred. [...] >> >> ... might even be understood as indicating 'request for registration' >> (via a registrar into a zone that has restrictive policies on what >> relative domain names can be registered). That needs clarification. >> >> But, firstly, back to the last para of Section 5.1! >> >> Upon further investigation: what's hashed for NSEC3 aren't single >> labels, but the fully qualified domain names registered in the zone >> -- the details are specified in Section 7.1 of RFC 5155, and also >> quoted shortly in Section 5.3.1 of the draft. And these are not >> the domain names "requested" in DNS queries (QNAMEs) -- unless these >> happen to match FQDNs for which RFC 5155 has made mandatory the >> generation of NSECe RRs (in particular, for secure delegations >> and for wildcards), or for which the Opt-out policy in force has >> chosen to generate NSEC3 records. >> Thus, as long as there is no sensical definition of the term, maybe >> "the requested RRlabels" might better be replaced by >> "the names registered in the zone". >> >> Note that the subsequent instances of "RRlabel" in Sections 5.2 >> (1st and 3rd para, 1x each), 5.3.1 (1st para, 2x), and 5.3.3 >> (2nd para, 3x) will likely need text adjustments as well. > > I have replaced all occurrences by "name". That's a clever choice; "name" is more neutral, and together with "FQDN" (where applicable) looks/sounds much better in the context of the I-D. > > Best regards, > Matthijs Best regards, Alfred. From A.Hoenes@TR-Sys.de Wed Apr 11 13:09:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2613E11E80BB for ; Wed, 11 Apr 2012 13:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.623 X-Spam-Level: X-Spam-Status: No, score=-97.623 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSD5taKjKmsk for ; Wed, 11 Apr 2012 13:09:50 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 80CE311E8075 for ; Wed, 11 Apr 2012 13:09:49 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA057184916; Wed, 11 Apr 2012 22:08:36 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA17550; Wed, 11 Apr 2012 22:08:34 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204112008.WAA17550@TR-Sys.de> To: matthijs@nlnetlabs.nl Date: Wed, 11 Apr 2012 22:08:34 +0200 (MESZ) In-Reply-To: <4F858BAA.10602@nlnetlabs.nl> from Matthijs Mekking at Apr "11, " 2012 "03:48:26" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 20:09:51 -0000 Matthijs, again thanks for your quick and detailed response and action. A few selected follow-up remark can be found inline below. On 11 Apr 2012 15:48:26 +0200, Matthijs Mekking wrote: > On 04/05/2012 12:48 AM, Alfred HÎnes wrote: >> Here we go with part (B); if deemed necessary, please consider >> to provide feedback for the items below on the list. > > Again, all items that are adopted without feedback necessary have > been omitted from this reply. And I additionally dropped those items where I'm satisfied with your response and do not see the need to add more thoughts. >> (B) Editorial flaws >> ++++++++++++++++++++ >> >> ... >> >> (B.3) Section 1.2 -- clarification >> >> With respect to item (B.1) above, I suggest to even better clarify the >> definition of "Signature validity period" in Section 1.2 (1st bullet): >> >> OLD: >> | o "Signature validity period" The period that a signature is valid. >> | It starts at the time specified in the signature inception field >> | of the RRSIG RR and ends at the time specified in the expiration >> | field of the RRSIG RR. >> >> NEW: >> | o "Signature validity period" The time interval during which a >> | signature is valid. It starts at the (absolute) time specified in >> | the signature inception field of the RRSIG RR and ends at the >> | (absolute) time specified in the expiration field of the RRSIG RR. > > I don't see why this should be changed. Do you prefer interval over > period? Do you want the clarify that the times are absolute? This is a > non-issue in my opinion. Well, the issue is that RFCs 4033 and 4034, after initially using the precise term, "signature validity interval", have switched to use the misnomer "signature validity period", and we are stuck with that unfortunate usage for consistency with RFCs 4033/4034. "Period" is used in "Re-Sign Period" "Refresh Period" in this draft in the proper sense of a period - a recurring, floating interval that relates to the reciprocal value, a frequency. Therefore I still believe that it is worth emphasizing here, early in the document, that "period" in "signature validity period" is different, actually being a fixed time interval that, once passed, will not recur. The suggested two additions of parenthetical "absolute" [time] seem to be a suitable way to do that with a very small textual footprint. >> ... >> >> (B.6) Section 4.1.5, list items below Figure 5 -- clarifications >> >> (c) >> In subsequent list items, I suggest to clarify the text -- where >> becessary -- by making the distinction between "old" and newer data >> more explicit, and -- in two instances -- an indication of the >> possibility of more than one DNSKEY RR (as in the Figure, due to the >> split KSK/ZSK scheme used) should be indicated by talking about the >> "DNSKEY RRset": >> >> | new DNSKEY: After the cache data has expired, the new key can be >> added to the zone. >> --- vvvvv >> | new DNSKEY: After the old cache data has expired, the new key can be >> added to the zone. > > What is an old cache? I suggest "After the old data has expired from > cache" here. The proposed text did say "old cache data", not "old cache". :-) But the wording you suggest is fine as well; I just tried to a change with a smaller footprint. > >> | DNSKEY removal: After the cache data for the DS has expired, the old >> | algorithm can be removed. This time the key needs to be removed >> | first, before removing the signatures. >> --- vvvvv >> | DNSKEY removal: After the cache data for the old DS has expired, the > > "old DS RRset" Agreed. > >> | old algorithm can be removed. This time the old key needs to be >> vvvvv ^^^^^ >> | removed first, before removing the old signatures. >> >> ... > > Best regards, > Matthijs Best regards, Alfred. From ggm+ietf@apnic.net Wed Apr 11 15:48:56 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12BE11E80EA for ; Wed, 11 Apr 2012 15:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN6hVS1lhhXB for ; Wed, 11 Apr 2012 15:48:56 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6911E80D9 for ; Wed, 11 Apr 2012 15:48:53 -0700 (PDT) Received: from dynamic191.apnic.net (dynamic191.apnic.net [203.119.42.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A3987B6769 for ; Thu, 12 Apr 2012 08:48:51 +1000 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: George Michaelson In-Reply-To: <4640D044-31F2-435D-9F9C-9E3F883801F0@kumari.net> Date: Thu, 12 Apr 2012 08:48:53 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <21FC4152-2A98-46F8-B21C-F2454DD2D004@apnic.net> References: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> <4640D044-31F2-435D-9F9C-9E3F883801F0@kumari.net> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:48:56 -0000 +1. I think a cleaner, simpler coordination framework for how to get things = added AND REMOVED from AS112 makes a lot of sense. I say removed, because at least some discussion has revolved around = people wanting domains on there that others believe they have future use = of. So de-delegation from AS112 is really important. I would also like to re-iterate that I think this complements = local-delegations. The two techniques should co-exist. -G= From rwfranks@gmail.com Wed Apr 11 15:53:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D279911E80EA for ; Wed, 11 Apr 2012 15:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqZeZUhcBd9Y for ; Wed, 11 Apr 2012 15:53:32 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7711E80D9 for ; Wed, 11 Apr 2012 15:53:32 -0700 (PDT) Received: by qaea16 with SMTP id a16so1115923qae.10 for ; Wed, 11 Apr 2012 15:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=GhhwguREuJkmOAwxkvVxbe6ml7+tmAmoSWZLjc3Cn0M=; b=wLNQ8/SWvbK+pttbOrWYNNA5+PFPUHZZpREAmuNLQsiihJY7PrRSQFy50qRajsViGK VN0Ihtj9CBWyEXIXvus0fnqbgEdgB79G2Q4sAqZ52/lpoRLdNIGa9htU91cW2JlzmT5O ZiWkrRaRP3tE/RnmRp59NJy41KqjnexcEd3tq2boK65F6eXKTv4eMDOplwEQ9Ct7J9oo HI70O5Z5thxg/epgO6b4KbgKiQlu4Z/vLFu/AUG/5ROGETVzK7NB1UYfFuAzrQGplW3L cQKad5L1dnOKFdr1lVYGhlii5f8WF4G7r+2xVootL0DSVKhMxuDAS1p6zUAqNsT6s+Kh Z9mw== Received: by 10.229.135.140 with SMTP id n12mr105398qct.12.1334184811576; Wed, 11 Apr 2012 15:53:31 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.229.144.197 with HTTP; Wed, 11 Apr 2012 15:53:11 -0700 (PDT) In-Reply-To: <4F858BAA.10602@nlnetlabs.nl> References: <201204042248.AAA29446@TR-Sys.de> <4F858BAA.10602@nlnetlabs.nl> From: Dick Franks Date: Wed, 11 Apr 2012 23:53:11 +0100 X-Google-Sender-Auth: 8mFnZ7I0EOkBqThpj_zGQetgcKs Message-ID: To: Matthijs Mekking Content-Type: multipart/alternative; boundary=00248c70fdc9c23e4004bd6f1ba2 Cc: ah@tr-sys.de, dnsop@ietf.org Subject: Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:53:32 -0000 --00248c70fdc9c23e4004bd6f1ba2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 April 2012 14:48, Matthijs Mekking wrote: > > > On 04/05/2012 12:48 AM, Alfred =EF=BF=BD wrote: > > > > | o "Signature validity period" The time interval during which a > > | signature is valid. It starts at the (absolute) time specified i= n > > | the signature inception field of the RRSIG RR and ends at the > > | (absolute) time specified in the expiration field of the RRSIG RR= . > > I don't see why this should be changed. Do you prefer interval over > period? Do you want the clarify that the times are absolute? This is a > non-issue in my opinion. > > > The word 'period' means the (constant) interval between events in a sequence; for example, the orbital period of a satellite. The time elapsed between aperiodic events occurring at times t1 and t2 is best described as an interval of duration (t2-t1). Absolute time was deprecated in 1905. --Dick --00248c70fdc9c23e4004bd6f1ba2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 April 2012 14:48, Matthijs Mekking <matthijs@nlnetl= abs.nl> wrote:


On 04/05/2012 12:48 AM, Alfred =EF=BF=BD wrote:
>
> | =C2=A0o =C2=A0"Signature validity period" The time interva= l during which a
> | =C2=A0 =C2=A0 signature is valid. =C2=A0It starts at the (absolute) = time specified in
> | =C2=A0 =C2=A0 the signature inception field of the RRSIG RR and ends= at the
> | =C2=A0 =C2=A0 (absolute) time specified in the expiration field of t= he RRSIG RR.

I don't see why this should be changed. Do you prefer interval ov= er
period? Do you want the clarify that the times are absolute? This is a
non-issue in my opinion.


The word 'period'= ; means the (constant) interval between events in a sequence; for example, = the orbital period of a satellite.

The time elapsed between aperiodi= c events occurring at times t1 and t2 is best described as an interval of d= uration (t2-t1).

Absolute time was deprecated in 1905.

--Dick
--00248c70fdc9c23e4004bd6f1ba2-- From matthijs@nlnetlabs.nl Thu Apr 12 01:19:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4004321F85E1 for ; Thu, 12 Apr 2012 01:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEt-Yp+yx3Bl for ; Thu, 12 Apr 2012 01:19:19 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 062BD21F85E4 for ; Thu, 12 Apr 2012 01:19:17 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3C8JEba023122; Thu, 12 Apr 2012 10:19:14 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334218756; bh=/phJdeIpNQ7lwRHRI6KfI1AE7dnnHQqyo5fn3+Gf2bk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=zZaeMsZmUF9OrH5R46WbexNbmXi88f8/1WrAXd/cYc6cFuE8Tig6RUslx2WQZyCJ6 ab4n5XmDgGFDVBP22wpdYWpCyjxoz5zBUlMo1WXRtG65ZL84lIGGHVN1pjjpsMDQqH OKnYTr/BiKA4fKcLi55mB6fSlDErVygrn/YQq058= Message-ID: <4F869001.1000602@nlnetlabs.nl> Date: Thu, 12 Apr 2012 10:19:13 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201204112008.WAA17550@TR-Sys.de> In-Reply-To: <201204112008.WAA17550@TR-Sys.de> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 12 Apr 2012 10:19:15 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (B) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 08:19:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alfred, I have no further comments on part (A). I have also adopted the leftovers in part (B), with explanation in between lines. Best regards, Matthijs On 04/11/2012 10:08 PM, Alfred � wrote: > Matthijs, again thanks for your quick and detailed response and > action. > > A few selected follow-up remark can be found inline below. > > > On 11 Apr 2012 15:48:26 +0200, Matthijs Mekking wrote: >> On 04/05/2012 12:48 AM, Alfred H�nes wrote: >>> Here we go with part (B); if deemed necessary, please consider >>> to provide feedback for the items below on the list. >> >> Again, all items that are adopted without feedback necessary >> have been omitted from this reply. > > And I additionally dropped those items where I'm satisfied with > your response and do not see the need to add more thoughts. > > >>> (B) Editorial flaws ++++++++++++++++++++ >>> >>> ... >>> >>> (B.3) Section 1.2 -- clarification >>> >>> With respect to item (B.1) above, I suggest to even better >>> clarify the definition of "Signature validity period" in >>> Section 1.2 (1st bullet): >>> >>> OLD: | o "Signature validity period" The period that a >>> signature is valid. | It starts at the time specified in >>> the signature inception field | of the RRSIG RR and ends at >>> the time specified in the expiration | field of the RRSIG >>> RR. >>> >>> NEW: | o "Signature validity period" The time interval during >>> which a | signature is valid. It starts at the (absolute) >>> time specified in | the signature inception field of the >>> RRSIG RR and ends at the | (absolute) time specified in the >>> expiration field of the RRSIG RR. >> >> I don't see why this should be changed. Do you prefer interval >> over period? Do you want the clarify that the times are absolute? >> This is a non-issue in my opinion. > > Well, the issue is that RFCs 4033 and 4034, after initially using > the precise term, "signature validity interval", have switched to > use the misnomer "signature validity period", and we are stuck with > that unfortunate usage for consistency with RFCs 4033/4034. > > "Period" is used in "Re-Sign Period" "Refresh Period" in this > draft in the proper sense of a period - a recurring, floating > interval that relates to the reciprocal value, a frequency. > > Therefore I still believe that it is worth emphasizing here, early > in the document, that "period" in "signature validity period" is > different, actually being a fixed time interval that, once passed, > will not recur. The suggested two additions of parenthetical > "absolute" [time] seem to be a suitable way to do that with a very > small textual footprint. Ok, with that explanation I at least understand why you suggested this change. Adopted. >>> ... >>> >>> (B.6) Section 4.1.5, list items below Figure 5 -- >>> clarifications >>> >>> (c) In subsequent list items, I suggest to clarify the text -- >>> where becessary -- by making the distinction between "old" and >>> newer data more explicit, and -- in two instances -- an >>> indication of the possibility of more than one DNSKEY RR (as in >>> the Figure, due to the split KSK/ZSK scheme used) should be >>> indicated by talking about the "DNSKEY RRset": >>> >>> | new DNSKEY: After the cache data has expired, the new key >>> can be added to the zone. --- vvvvv | new >>> DNSKEY: After the old cache data has expired, the new key can >>> be added to the zone. >> >> What is an old cache? I suggest "After the old data has expired >> from cache" here. > > The proposed text did say "old cache data", not "old cache". :-) > But the wording you suggest is fine as well; I just tried to a > change with a smaller footprint. But it was ambiguous (at least to me), so I suggested the other wording. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhpABAAoJEA8yVCPsQCW5yVsH/jSUiaExz5hP7s5sscxXOIaz UmP2r3KLOWnG6f46I3inkRSv2LcDfLnI0OFkWnjhoy2bR0QbRfTeEMWRkFfJBSAc 2cOMoKgcF+ytRQl2PBkEUiRsnoe+9ExRQHD2HnnyrNHdYyj3Lt445x0XoDF4NnAw P2KZugLbxW15LHkfQ4ng/kwExw9bIVCAkk75zn2DtQx3YomSa7APdZreDhrTYrJL GRY53vEsdhxXo4wPJxp+PqSzVG5YlhCgEwMAjucWNOy74JKq1PS75B7KfKwpMAhj +EXNulnmf8zevkobrWA7J8f8SCrzVUbquqiytk6+/hRVxt3XVnVl1ccFSjT88o4= =uGVH -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Thu Apr 12 01:54:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECE721F861D for ; Thu, 12 Apr 2012 01:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYLowJW8WzRb for ; Thu, 12 Apr 2012 01:54:27 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0239121F85AF for ; Thu, 12 Apr 2012 01:54:26 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3C8qZQP065138; Thu, 12 Apr 2012 10:52:35 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334220758; bh=1nsjlc9Iug28JTV6ED1KB8KkNtexIKL4/4EGOkG8bBE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Z25uvNdoC4Fgll01L/MwYhSubNQyViGTUU4TLBIEtLpCgDvYglLSW+DxdGbC01s/o Q8MteBasvmY/lw/Y59FiamJvqwynS/ssyhFrcnYeRUqkDQlWTe8eufw16nKSi4/8fk 62oQRbulILW5fEWLwk24w7oOJAU7CYF8nEQbEv74= Message-ID: <4F8697D2.7010809@nlnetlabs.nl> Date: Thu, 12 Apr 2012 10:52:34 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Lampo References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> <4F7AB67F.6020603@nlnetlabs.nl> <008501cd1179$ce4cd830$6ae68890$@lampo@eurid.eu> In-Reply-To: <008501cd1179$ce4cd830$6ae68890$@lampo@eurid.eu> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 12 Apr 2012 10:52:36 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 08:54:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marc, Coming back to your review items, I only think point 1 is not decided on yet. But I don't think this should stop progress. You can find my responses in between lines. Best regards, Matthijs On 04/03/2012 11:11 AM, Marc Lampo wrote: > Hello again, > > About 1) If the document is for the authoritative side, why not > simply state so. Instead of this confusing statement about > relationship between authoritative and validating NS's ? I believe it does state so, without confusion: The first sentence says the document is aimed for people that are active at the authoritative side. The second sentence says that we consider no relationship with the people running the recursive side. You think the document can do without the latter sentence. I think it is a fair assumption. > About 2) So it is "two" steps ? I made it three stages. ;) > About 3) I forgot the word "corresponding", my fault there. As such > the text is not wrong, please don't misunderstand me. But the > parent the only way, for a parent, to known/verify that DS > information is correct, is by querying for the DNSKEY RRset and > check if the corresponding ( ;-) DNSKEY is indeed present. If it is > not, there is no way the parent can distinguish between a child > zone administrator performing a double-DS rollover or making an > error ... The text is not wrong, so we do not need action for 4641bis here. My point of view on this topic: As long as there is a valid DS with corresponding DNSKEY, adding another DS is no error. Maybe you are afraid what happens if the child zone operator removes the old DNSKEY and replaces it with the new (mismatched) one. Now you have encountered the error. But such things are not specific to Double-DS rollover, it can happen also without being in a rollover: I could remove my DNSKEYs from my zone, and it would go bogus. Same thing. My point is, as long as the zone is able to be validated, there is no error made (in terms of DNSSEC). > About 4) I can agree with the present text. Ok. > About 5) Me too, I think published signatures should never be > expired. Consequently, every key rollover will make signatures > disappear that are, as such, not expired yet. From that point of > view it makes little difference if signature validity period is a > couple of weeks or months or years. > > But if the zone administrator uses long validity time with the > intention not to recalculate regularly, this implies that the ZSK > cannot rollover either. (and this is practice - out there, right > now ! There is one TLD that has signatures valid till "the end of > the current year", and never did any key rollover since it started > with DNSSEC) > > To conclude : I can "just" agree with the present text. Ok. > > > > Kind regards, > > Marc Lampo EURid (for .eu) > > -----Original Message----- From: Matthijs Mekking > [mailto:matthijs@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: > Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-rfc4641bis-10.txt > > Hi, > > On 04/02/2012 04:35 PM, Marc Lampo wrote: >> Hello to the list, > >> Nice piece of work ! > >> Some remarks - nothing spectacular : 1) Last sentence in the >> first paragraph - Introduction (about : "no direct relation >> between ... and validating caching name servers.") > >> Isn't this sentence superfluous ? I fail to see where a possible >> relation would indeed change something to these guidelines. > >> But by including the sentence about no relationship, one starts >> to wonder if something escapes me ... > > The document just tries to make it very clear that it is targeted > to the authoritative side of the DNS equation. > > >> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence >> states there are three steps. I think this is an error : There >> are three states, yes; but there are only two manipulations to >> perform. (to me it seems logical to interpret "step" as : >> "operation to perform") > > Sure. More important is the fact that it is one step/stage shorter > than Pre-publish ZSK rollover. > >> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security >> Lameness > >> (actually, 4.1.3 introduces another way of KSK rollover. In that >> respect the title of the section is confusing !) > >> In 4.1.3 the text suggest to publish a DS record in the parent >> for which there is no DNSKEY record in the child zone. > > It suggests to publish a DS record for which there is no > *corresponding* DNSKEY record in the child zone, next to an > existing chain of trust between parent and child. That is different > from "no DNSKEY record in the child zone". > >> In 4.3.3 the text suggest the parent could verify that the DNSKEY >> is actually published by the child. > >> --> 4.3.3 could explicitly state that, if a parent performs this >> kind of checking, then the "double DS method" of 4.1.3 is not >> possible. > > There is already a forward reference in section 4.1.3 to 4.3.3. > >> Furthermore : as registry (for .eu) we think that it is important >> to assist our registrars in setting DNSSEC up correctly. >> Consequently, we do verification when a registrar sends us DNSSEC >> information. So we cannot distinguish between a DNS Operator >> that performs double DS KSK rollover and an operator making a >> mistake ... > > I think you might have a false negative there: If a DNS operator > requests for a second DS to be published, it does not break the > chain of trust. Why classify it as a mistake? Double-DS rollover is > perfectly acceptable within the boundaries of DNSSEC. > >> 4) 4.3.4 DS Signature Validity Period The last paragraph holds a >> sentence that states : "Shortening the TTL reduces the damage of >> a successful replay attack." > >> I don't think this is correct (or relevant). For me, the chances >> for a replay attack increase with the signature validity period, >> not with the value of the TTL. The value of the paragraph lays, >> for me, in the propagation of updated DS RRsets (cfr the >> presentation on low TTL's, last week). > > You are right that the chances for a replay attack increase with > the validity period, but the damage depends on how long that data > will be in the cache. That depends on TTL. > >> 5) 4.4.2.1 Maximum value (for Signature Validation Period) > >> I think this paragraph should make a reference to Key Rollover ! >> Motivation : no matter how long a signature is valid, in order >> for it to be used, the corresponding Key must be available. (so : >> if the reason for long RRSIG validity is not to recalculate them, >> then ...) > >> I do admit that none of the Key Rollover scenario's take into >> account the signature validity time (but the TTL). And indeed, >> nothing prevents to generate a signature, valid for 1 year, with >> TTL of 1 day, and perform key rollover every three months : the >> still valid signature simply times out of the cache, to be >> replaced by a new one, valid for a new year. > > Hence, I don't think this paragraph should make a reference to key > rollover. > > Best regards, Matthijs > > >> Kind regards, > >> Marc Lampo EURid (for .eu) > > >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 AM >> To: i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] >> I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt > > >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> Domain Name System Operations Working Group of the IETF. > >> Title : DNSSEC Operational Practices, Version 2 >> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename >> : draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date : >> 2012-03-30 > >> This document describes a set of practices for operating the DNS >> with security extensions (DNSSEC). The target audience is zone >> administrators deploying DNSSEC. > >> The document discusses operational aspects of using keys and >> signatures in the DNS. It discusses issues of key generation, >> key storage, signature generation, key rollover, and related >> policies. > >> This document obsoletes RFC 4641 as it covers more operational >> ground and gives more up-to-date requirements with respect to key >> sizes and the DNSSEC operations. > > >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > >> > > >> _______________________________________________ DNSOP mailing >> list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhpfSAAoJEA8yVCPsQCW52YUH/0eUw4cd20SZSbD79E//K1eo UwauNqTKZT+r1GuGSqFUXpCTgBrZVLvALmdVzGrK8dA6WuifNSU6aimZvf9csgWO bpRS1ty3xWMA88BFZ7sLFT4rYT9FT7S7jBgpZ8BfYWgZRGPvqIQpXn9EKT6Y8r8g blI0QUbFRxd+WUagSAZNK+QEWLlm8EdXWKA4sn/TlVAx/jYImQt7nRGCZj+MHG8W mnSDr1p8w16J3DYOqUSlmvj/YfgSF0yS+WPMusEWmAPJSiYpmx8G4/3OAXqKWF9t 11FZySeN0eqBuFIr1fYwpITLFHpxzgc9F0aEdST/7vJpZDFMfNk66ScRHxs6rvU= =oMto -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Thu Apr 12 03:49:02 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DEA21F8656 for ; Thu, 12 Apr 2012 03:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYo1UjStJotx for ; Thu, 12 Apr 2012 03:49:01 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4321F8646 for ; Thu, 12 Apr 2012 03:49:00 -0700 (PDT) X-ASG-Debug-ID: 1334228234-0369490e9c93040001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id umXUgCTdUlDXLPvA; Thu, 12 Apr 2012 12:57:14 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 62833E408C; Thu, 12 Apr 2012 12:48:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdn-k7EGLx4q; Thu, 12 Apr 2012 12:48:58 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 46A4CE4050; Thu, 12 Apr 2012 12:48:58 +0200 (CEST) From: "Marc Lampo" To: "'Matthijs Mekking'" References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> <4F7AB67F.6020603@nlnetlabs.nl> <008501cd1179$ce4cd830$6ae68890$@lampo@eurid.eu> <4F8697D2.7010809@nlnetlabs.nl> In-Reply-To: <4F8697D2.7010809@nlnetlabs.nl> Date: Thu, 12 Apr 2012 12:48:58 +0200 (CEST) X-ASG-Orig-Subj: RE: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Message-ID: <000a01cd1899$dcf418e0$96dc4aa0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0YidzxYDXjWz/VRgqN+AGZVh+xlAADzIoQ Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1334228234 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:49:02 -0000 Hello Matthijs, Regarding 1 - "... no relationship ... validating ... " Suggestion (a phrase that does not hint at any possible "relationship") : This document holds no information that applies to the configuration of validating recursive name servers (validators). Ok regarding 2 : three stages OK regarding 3 : consequences for validation by parents (as a matter of fact, we're going to check if we adapt our present validation ourselves) For 4 and 5 there was already an OK. Kind regards, Marc -----Original Message----- From: Matthijs Mekking [mailto:matthijs@nlnetlabs.nl] Sent: 12 April 2012 10:53 AM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marc, Coming back to your review items, I only think point 1 is not decided on yet. But I don't think this should stop progress. You can find my responses in between lines. Best regards, Matthijs On 04/03/2012 11:11 AM, Marc Lampo wrote: > Hello again, > > About 1) If the document is for the authoritative side, why not simply > state so. Instead of this confusing statement about relationship > between authoritative and validating NS's ? I believe it does state so, without confusion: The first sentence says the document is aimed for people that are active at the authoritative side. The second sentence says that we consider no relationship with the people running the recursive side. You think the document can do without the latter sentence. I think it is a fair assumption. > About 2) So it is "two" steps ? I made it three stages. ;) > About 3) I forgot the word "corresponding", my fault there. As such > the text is not wrong, please don't misunderstand me. But the parent > the only way, for a parent, to known/verify that DS information is > correct, is by querying for the DNSKEY RRset and check if the > corresponding ( ;-) DNSKEY is indeed present. If it is not, there is > no way the parent can distinguish between a child zone administrator > performing a double-DS rollover or making an error ... The text is not wrong, so we do not need action for 4641bis here. My point of view on this topic: As long as there is a valid DS with corresponding DNSKEY, adding another DS is no error. Maybe you are afraid what happens if the child zone operator removes the old DNSKEY and replaces it with the new (mismatched) one. Now you have encountered the error. But such things are not specific to Double-DS rollover, it can happen also without being in a rollover: I could remove my DNSKEYs from my zone, and it would go bogus. Same thing. My point is, as long as the zone is able to be validated, there is no error made (in terms of DNSSEC). > About 4) I can agree with the present text. Ok. > About 5) Me too, I think published signatures should never be expired. > Consequently, every key rollover will make signatures disappear that > are, as such, not expired yet. From that point of view it makes little > difference if signature validity period is a couple of weeks or months > or years. > > But if the zone administrator uses long validity time with the > intention not to recalculate regularly, this implies that the ZSK > cannot rollover either. (and this is practice - out there, right now ! > There is one TLD that has signatures valid till "the end of the > current year", and never did any key rollover since it started with > DNSSEC) > > To conclude : I can "just" agree with the present text. Ok. > > > > Kind regards, > > Marc Lampo EURid (for .eu) > > -----Original Message----- From: Matthijs Mekking > [mailto:matthijs@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: > Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-rfc4641bis-10.txt > > Hi, > > On 04/02/2012 04:35 PM, Marc Lampo wrote: >> Hello to the list, > >> Nice piece of work ! > >> Some remarks - nothing spectacular : 1) Last sentence in the first >> paragraph - Introduction (about : "no direct relation between ... and >> validating caching name servers.") > >> Isn't this sentence superfluous ? I fail to see where a possible >> relation would indeed change something to these guidelines. > >> But by including the sentence about no relationship, one starts to >> wonder if something escapes me ... > > The document just tries to make it very clear that it is targeted to > the authoritative side of the DNS equation. > > >> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states >> there are three steps. I think this is an error : There are three >> states, yes; but there are only two manipulations to perform. (to me >> it seems logical to interpret "step" as : >> "operation to perform") > > Sure. More important is the fact that it is one step/stage shorter > than Pre-publish ZSK rollover. > >> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security >> Lameness > >> (actually, 4.1.3 introduces another way of KSK rollover. In that >> respect the title of the section is confusing !) > >> In 4.1.3 the text suggest to publish a DS record in the parent for >> which there is no DNSKEY record in the child zone. > > It suggests to publish a DS record for which there is no > *corresponding* DNSKEY record in the child zone, next to an existing > chain of trust between parent and child. That is different from "no > DNSKEY record in the child zone". > >> In 4.3.3 the text suggest the parent could verify that the DNSKEY is >> actually published by the child. > >> --> 4.3.3 could explicitly state that, if a parent performs this >> kind of checking, then the "double DS method" of 4.1.3 is not >> possible. > > There is already a forward reference in section 4.1.3 to 4.3.3. > >> Furthermore : as registry (for .eu) we think that it is important to >> assist our registrars in setting DNSSEC up correctly. >> Consequently, we do verification when a registrar sends us DNSSEC >> information. So we cannot distinguish between a DNS Operator that >> performs double DS KSK rollover and an operator making a mistake ... > > I think you might have a false negative there: If a DNS operator > requests for a second DS to be published, it does not break the chain > of trust. Why classify it as a mistake? Double-DS rollover is > perfectly acceptable within the boundaries of DNSSEC. > >> 4) 4.3.4 DS Signature Validity Period The last paragraph holds a >> sentence that states : "Shortening the TTL reduces the damage of a >> successful replay attack." > >> I don't think this is correct (or relevant). For me, the chances for >> a replay attack increase with the signature validity period, not with >> the value of the TTL. The value of the paragraph lays, for me, in the >> propagation of updated DS RRsets (cfr the presentation on low TTL's, >> last week). > > You are right that the chances for a replay attack increase with the > validity period, but the damage depends on how long that data will be > in the cache. That depends on TTL. > >> 5) 4.4.2.1 Maximum value (for Signature Validation Period) > >> I think this paragraph should make a reference to Key Rollover ! >> Motivation : no matter how long a signature is valid, in order for >> it to be used, the corresponding Key must be available. (so : >> if the reason for long RRSIG validity is not to recalculate them, >> then ...) > >> I do admit that none of the Key Rollover scenario's take into account >> the signature validity time (but the TTL). And indeed, nothing >> prevents to generate a signature, valid for 1 year, with TTL of 1 >> day, and perform key rollover every three months : the still valid >> signature simply times out of the cache, to be replaced by a new one, >> valid for a new year. > > Hence, I don't think this paragraph should make a reference to key > rollover. > > Best regards, Matthijs > > >> Kind regards, > >> Marc Lampo EURid (for .eu) > > >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 AM >> To: i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] I-D >> Action: draft-ietf-dnsop-rfc4641bis-10.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Domain Name System >> Operations Working Group of the IETF. > >> Title : DNSSEC Operational Practices, Version 2 >> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename >> : draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date : >> 2012-03-30 > >> This document describes a set of practices for operating the DNS with >> security extensions (DNSSEC). The target audience is zone >> administrators deploying DNSSEC. > >> The document discusses operational aspects of using keys and >> signatures in the DNS. It discusses issues of key generation, key >> storage, signature generation, key rollover, and related policies. > >> This document obsoletes RFC 4641 as it covers more operational ground >> and gives more up-to-date requirements with respect to key sizes and >> the DNSSEC operations. > > >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.tx >> t > >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > >> > > >> _______________________________________________ DNSOP mailing list >> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhpfSAAoJEA8yVCPsQCW52YUH/0eUw4cd20SZSbD79E//K1eo UwauNqTKZT+r1GuGSqFUXpCTgBrZVLvALmdVzGrK8dA6WuifNSU6aimZvf9csgWO bpRS1ty3xWMA88BFZ7sLFT4rYT9FT7S7jBgpZ8BfYWgZRGPvqIQpXn9EKT6Y8r8g blI0QUbFRxd+WUagSAZNK+QEWLlm8EdXWKA4sn/TlVAx/jYImQt7nRGCZj+MHG8W mnSDr1p8w16J3DYOqUSlmvj/YfgSF0yS+WPMusEWmAPJSiYpmx8G4/3OAXqKWF9t 11FZySeN0eqBuFIr1fYwpITLFHpxzgc9F0aEdST/7vJpZDFMfNk66ScRHxs6rvU= =oMto -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Thu Apr 12 04:05:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE1221F864C for ; Thu, 12 Apr 2012 04:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5A+zTTGHkAY for ; Thu, 12 Apr 2012 04:05:50 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8587A21F861A for ; Thu, 12 Apr 2012 04:05:49 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3CB3w8G021003; Thu, 12 Apr 2012 13:03:59 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334228641; bh=gWkt4IgVmnOwi78GMUbssJ6TOX61GK04ZkAN9PeCJRc=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=F5piWEo6SJC4bQ0Loimiue2jdtRcq1JLfJs/u+n1k6jro/FJm8wkUyBGDv102V4nd 8labsY3kYY76YeZwWNBt0OlPDjEGqeEzUsa6bDi3PBXZ+HjXGF2iTE92RlLLMlpiyo lbLcxFoU0xSrk6DBlC6JvA5/gkM2mSP+lRe6ap3A= Message-ID: <4F86B69E.8070004@nlnetlabs.nl> Date: Thu, 12 Apr 2012 13:03:58 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Lampo References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> <4F7AB67F.6020603@nlnetlabs.nl> <008501cd1179$ce4cd830$6ae68890$@lampo@eurid.eu> <4F8697D2.7010809@nlnetlabs.nl> <000a01cd1899$dcf418e0$96dc4aa0$@lampo@eurid.eu> In-Reply-To: <000a01cd1899$dcf418e0$96dc4aa0$@lampo@eurid.eu> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 12 Apr 2012 13:04:00 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 11:05:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2012 12:48 PM, Marc Lampo wrote: > Hello Matthijs, > > Regarding 1 - "... no relationship ... validating ... " > > Suggestion (a phrase that does not hint at any possible > "relationship") : This document holds no information that applies > to the configuration of validating recursive name servers > (validators). Not only that, also the entities on the authoritative side don't have influence on the entities on the recursive side. > > Ok regarding 2 : three stages > > OK regarding 3 : consequences for validation by parents > > (as a matter of fact, we're going to check if we adapt our present > validation ourselves) > > For 4 and 5 there was already an OK. > > Kind regards, > > Marc > > > -----Original Message----- From: Matthijs Mekking > [mailto:matthijs@nlnetlabs.nl] Sent: 12 April 2012 10:53 AM To: > Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-rfc4641bis-10.txt > > Hi Marc, > > Coming back to your review items, I only think point 1 is not > decided on yet. But I don't think this should stop progress. > > You can find my responses in between lines. > > Best regards, Matthijs > > On 04/03/2012 11:11 AM, Marc Lampo wrote: >> Hello again, > >> About 1) If the document is for the authoritative side, why not >> simply state so. Instead of this confusing statement about >> relationship between authoritative and validating NS's ? > > I believe it does state so, without confusion: The first sentence > says the document is aimed for people that are active at the > authoritative side. The second sentence says that we consider no > relationship with the people running the recursive side. You think > the document can do without the latter sentence. I think it is a > fair assumption. > >> About 2) So it is "two" steps ? > > I made it three stages. ;) > >> About 3) I forgot the word "corresponding", my fault there. As >> such the text is not wrong, please don't misunderstand me. But >> the parent the only way, for a parent, to known/verify that DS >> information is correct, is by querying for the DNSKEY RRset and >> check if the corresponding ( ;-) DNSKEY is indeed present. If it >> is not, there is no way the parent can distinguish between a >> child zone administrator performing a double-DS rollover or >> making an error ... > > The text is not wrong, so we do not need action for 4641bis here. > > My point of view on this topic: > > As long as there is a valid DS with corresponding DNSKEY, adding > another DS is no error. Maybe you are afraid what happens if the > child zone operator removes the old DNSKEY and replaces it with the > new (mismatched) one. Now you have encountered the error. But such > things are not specific to Double-DS rollover, it can happen also > without being in a rollover: I could remove my DNSKEYs from my > zone, and it would go bogus. Same thing. > > My point is, as long as the zone is able to be validated, there is > no error made (in terms of DNSSEC). > >> About 4) I can agree with the present text. > > Ok. > >> About 5) Me too, I think published signatures should never be >> expired. Consequently, every key rollover will make signatures >> disappear that are, as such, not expired yet. From that point of >> view it makes little difference if signature validity period is a >> couple of weeks or months or years. > >> But if the zone administrator uses long validity time with the >> intention not to recalculate regularly, this implies that the ZSK >> cannot rollover either. (and this is practice - out there, right >> now ! There is one TLD that has signatures valid till "the end of >> the current year", and never did any key rollover since it >> started with DNSSEC) > >> To conclude : I can "just" agree with the present text. > > Ok. > > > > > >> Kind regards, > >> Marc Lampo EURid (for .eu) > >> -----Original Message----- From: Matthijs Mekking >> [mailto:matthijs@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: >> Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: >> draft-ietf-dnsop-rfc4641bis-10.txt > >> Hi, > >> On 04/02/2012 04:35 PM, Marc Lampo wrote: >>> Hello to the list, > >>> Nice piece of work ! > >>> Some remarks - nothing spectacular : 1) Last sentence in the >>> first paragraph - Introduction (about : "no direct relation >>> between ... and validating caching name servers.") > >>> Isn't this sentence superfluous ? I fail to see where a >>> possible relation would indeed change something to these >>> guidelines. > >>> But by including the sentence about no relationship, one starts >>> to wonder if something escapes me ... > >> The document just tries to make it very clear that it is targeted >> to the authoritative side of the DNS equation. > > >>> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence >>> states there are three steps. I think this is an error : There >>> are three states, yes; but there are only two manipulations to >>> perform. (to me it seems logical to interpret "step" as : >>> "operation to perform") > >> Sure. More important is the fact that it is one step/stage >> shorter than Pre-publish ZSK rollover. > >>> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 >>> Security Lameness > >>> (actually, 4.1.3 introduces another way of KSK rollover. In >>> that respect the title of the section is confusing !) > >>> In 4.1.3 the text suggest to publish a DS record in the parent >>> for which there is no DNSKEY record in the child zone. > >> It suggests to publish a DS record for which there is no >> *corresponding* DNSKEY record in the child zone, next to an >> existing chain of trust between parent and child. That is >> different from "no DNSKEY record in the child zone". > >>> In 4.3.3 the text suggest the parent could verify that the >>> DNSKEY is actually published by the child. > >>> --> 4.3.3 could explicitly state that, if a parent performs >>> this kind of checking, then the "double DS method" of 4.1.3 is >>> not possible. > >> There is already a forward reference in section 4.1.3 to 4.3.3. > >>> Furthermore : as registry (for .eu) we think that it is >>> important to assist our registrars in setting DNSSEC up >>> correctly. Consequently, we do verification when a registrar >>> sends us DNSSEC information. So we cannot distinguish between >>> a DNS Operator that performs double DS KSK rollover and an >>> operator making a mistake ... > >> I think you might have a false negative there: If a DNS operator >> requests for a second DS to be published, it does not break the >> chain of trust. Why classify it as a mistake? Double-DS rollover >> is perfectly acceptable within the boundaries of DNSSEC. > >>> 4) 4.3.4 DS Signature Validity Period The last paragraph holds >>> a sentence that states : "Shortening the TTL reduces the damage >>> of a successful replay attack." > >>> I don't think this is correct (or relevant). For me, the >>> chances for a replay attack increase with the signature >>> validity period, not with the value of the TTL. The value of >>> the paragraph lays, for me, in the propagation of updated DS >>> RRsets (cfr the presentation on low TTL's, last week). > >> You are right that the chances for a replay attack increase with >> the validity period, but the damage depends on how long that data >> will be in the cache. That depends on TTL. > >>> 5) 4.4.2.1 Maximum value (for Signature Validation Period) > >>> I think this paragraph should make a reference to Key Rollover >>> ! Motivation : no matter how long a signature is valid, in >>> order for it to be used, the corresponding Key must be >>> available. (so : if the reason for long RRSIG validity is not >>> to recalculate them, then ...) > >>> I do admit that none of the Key Rollover scenario's take into >>> account the signature validity time (but the TTL). And indeed, >>> nothing prevents to generate a signature, valid for 1 year, >>> with TTL of 1 day, and perform key rollover every three months >>> : the still valid signature simply times out of the cache, to >>> be replaced by a new one, valid for a new year. > >> Hence, I don't think this paragraph should make a reference to >> key rollover. > >> Best regards, Matthijs > > >>> Kind regards, > >>> Marc Lampo EURid (for .eu) > > >>> -----Original Message----- From: internet-drafts@ietf.org >>> [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 AM >>> To: i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] >>> I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt > > >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> Domain Name System Operations Working Group of the IETF. > >>> Title : DNSSEC Operational Practices, Version 2 >>> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename : >>> draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date : >>> 2012-03-30 > >>> This document describes a set of practices for operating the >>> DNS with security extensions (DNSSEC). The target audience is >>> zone administrators deploying DNSSEC. > >>> The document discusses operational aspects of using keys and >>> signatures in the DNS. It discusses issues of key generation, >>> key storage, signature generation, key rollover, and related >>> policies. > >>> This document obsoletes RFC 4641 as it covers more operational >>> ground and gives more up-to-date requirements with respect to >>> key sizes and the DNSSEC operations. > > >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.tx >>> >>> t > >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ > >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > >>> >>> > > >>> _______________________________________________ DNSOP mailing >>> list DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop > >> _______________________________________________ DNSOP mailing >> list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhraeAAoJEA8yVCPsQCW5t54IANHgx1Kb01ifNjkFKn5eUaUd ku9oS8d7JdW+7Bt2ps+vTQeec4oUqZ4x6HcFJj38TRxFwHXoyTVL06UVtzLV8btG KQbAlTgYPbuxS5uE/BqAUXFeqtItLqbSvKHmD2GLMtKBm8/hRYpNYIfwn184Svmi /BHJxu0FQrRB0wCF5FCEsYasXRrd/JISaiNqGlyzBETQbCZl02RMUpvCu4RdLNy0 kz2EiBrxkkpvqoMlWRKv6ejR5MfhX07otzPTWWBTTu/ugIjcVxqCojjv299Mj1Oq nmjzrpm3C6hBFPhoYen6HXcpJQziZ5wM/c6hZqoJIAXUmhCyh/DGHNbCMcEaCJk= =2548 -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Thu Apr 12 05:09:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A699F21F865A for ; Thu, 12 Apr 2012 05:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rcKxoxuhmsK for ; Thu, 12 Apr 2012 05:09:34 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1062E21F85C2 for ; Thu, 12 Apr 2012 05:09:33 -0700 (PDT) X-ASG-Debug-ID: 1334233069-0369490e9c936c0001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id EDdQkyUocqIlOILA; Thu, 12 Apr 2012 14:17:49 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 566ABE408D; Thu, 12 Apr 2012 14:09:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9tN-WXQoaRF; Thu, 12 Apr 2012 14:09:32 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 3770AE4052; Thu, 12 Apr 2012 14:09:32 +0200 (CEST) From: "Marc Lampo" To: "'Matthijs Mekking'" References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> <4F7AB67F.6020603@nlnetlabs.nl> <008501cd1179$ce4cd830$6ae68890$@lampo@eurid.eu> <4F8697D2.7010809@nlnetlabs.nl> <000a01cd1899$dcf418e0$96dc4aa0$@lampo@eurid.eu> <4F86B69E.8070004@nlnetlabs.nl> In-Reply-To: <4F86B69E.8070004@nlnetlabs.nl> Date: Thu, 12 Apr 2012 14:09:32 +0200 (CEST) X-ASG-Orig-Subj: RE: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt Message-ID: <002d01cd18a5$1e389eb0$5aa9dc10$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0YnDeTqGyo0D1+SyWU3ePtb4yCBgABg0tg Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1334233069 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:09:35 -0000 Hello all, (This also concerns the other discussion about "Negative Trust Anchors", I'll post with that subject as well) -----Original Message----- From: Matthijs Mekking [mailto:matthijs@nlnetlabs.nl] ... > Not only that, also the entities on the authoritative side > don't have influence on the entities on the recursive side. Actually, there is something that influences the recursive side ! (I'm referring to 4.3.3 "Security lameness", where is state "removing a DS RR") Since this document is about "DNSSEC Operational Practices", perhaps include a suggestion that parents regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information they find published. If the parent detects "security lameness" its possible reaction could be to remove the DS information. While my company, as registry for .eu, does not do this (yet ?), we do validate DNSSEC information when submitted, prior to publishing it as DS records (only if validation yields success). So, we already decide not to publish wrong information (at one point in time). The suggestion to regularly verify again extends that behaviour from "not publishing if wrong" (at submission time) to "stop publishing if wrong" (as part of normal operation) (the contract with registrars states that information provided by registrars must be correct. If not, the contract allows for some reactions (like blocking a domain in case of fake identities, but - by extension - to correctness of DNSSEC information) The advantage over negative trust anchor would be that this is more centrally managed : the action by the parent (remove DS) is visible (TTL permitted) to any validating name server. (the negative trust anchor needs to be configured by every validating NS, whose administrators bother to do so. And good point for Comcast who is obviously committed here !) I acknowledge that negative trust anchor applies to however the chain-of-trust starts (from the root-zone, or from some DLV). But since the root is DNSSEC'd since close to 2 years, I expect the DLV approach is less important anyway. Kind regards, Marc Lampo Security Officer EURid (for .eu) -----Original Message----- From: Matthijs Mekking [mailto:matthijs@nlnetlabs.nl] Sent: 12 April 2012 01:04 PM To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2012 12:48 PM, Marc Lampo wrote: > Hello Matthijs, > > Regarding 1 - "... no relationship ... validating ... " > > Suggestion (a phrase that does not hint at any possible > "relationship") : This document holds no information that applies to > the configuration of validating recursive name servers (validators). Not only that, also the entities on the authoritative side don't have influence on the entities on the recursive side. > > Ok regarding 2 : three stages > > OK regarding 3 : consequences for validation by parents > > (as a matter of fact, we're going to check if we adapt our present > validation ourselves) > > For 4 and 5 there was already an OK. > > Kind regards, > > Marc > > > -----Original Message----- From: Matthijs Mekking > [mailto:matthijs@nlnetlabs.nl] Sent: 12 April 2012 10:53 AM To: > Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-rfc4641bis-10.txt > > Hi Marc, > > Coming back to your review items, I only think point 1 is not decided > on yet. But I don't think this should stop progress. > > You can find my responses in between lines. > > Best regards, Matthijs > > On 04/03/2012 11:11 AM, Marc Lampo wrote: >> Hello again, > >> About 1) If the document is for the authoritative side, why not >> simply state so. Instead of this confusing statement about >> relationship between authoritative and validating NS's ? > > I believe it does state so, without confusion: The first sentence says > the document is aimed for people that are active at the authoritative > side. The second sentence says that we consider no relationship with > the people running the recursive side. You think the document can do > without the latter sentence. I think it is a fair assumption. > >> About 2) So it is "two" steps ? > > I made it three stages. ;) > >> About 3) I forgot the word "corresponding", my fault there. As such >> the text is not wrong, please don't misunderstand me. But the parent >> the only way, for a parent, to known/verify that DS information is >> correct, is by querying for the DNSKEY RRset and check if the >> corresponding ( ;-) DNSKEY is indeed present. If it is not, there is >> no way the parent can distinguish between a child zone administrator >> performing a double-DS rollover or making an error ... > > The text is not wrong, so we do not need action for 4641bis here. > > My point of view on this topic: > > As long as there is a valid DS with corresponding DNSKEY, adding > another DS is no error. Maybe you are afraid what happens if the child > zone operator removes the old DNSKEY and replaces it with the new > (mismatched) one. Now you have encountered the error. But such things > are not specific to Double-DS rollover, it can happen also without > being in a rollover: I could remove my DNSKEYs from my zone, and it > would go bogus. Same thing. > > My point is, as long as the zone is able to be validated, there is no > error made (in terms of DNSSEC). > >> About 4) I can agree with the present text. > > Ok. > >> About 5) Me too, I think published signatures should never be >> expired. Consequently, every key rollover will make signatures >> disappear that are, as such, not expired yet. From that point of view >> it makes little difference if signature validity period is a couple >> of weeks or months or years. > >> But if the zone administrator uses long validity time with the >> intention not to recalculate regularly, this implies that the ZSK >> cannot rollover either. (and this is practice - out there, right now >> ! There is one TLD that has signatures valid till "the end of the >> current year", and never did any key rollover since it started with >> DNSSEC) > >> To conclude : I can "just" agree with the present text. > > Ok. > > > > > >> Kind regards, > >> Marc Lampo EURid (for .eu) > >> -----Original Message----- From: Matthijs Mekking >> [mailto:matthijs@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: >> Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: >> draft-ietf-dnsop-rfc4641bis-10.txt > >> Hi, > >> On 04/02/2012 04:35 PM, Marc Lampo wrote: >>> Hello to the list, > >>> Nice piece of work ! > >>> Some remarks - nothing spectacular : 1) Last sentence in the first >>> paragraph - Introduction (about : "no direct relation between ... >>> and validating caching name servers.") > >>> Isn't this sentence superfluous ? I fail to see where a possible >>> relation would indeed change something to these guidelines. > >>> But by including the sentence about no relationship, one starts to >>> wonder if something escapes me ... > >> The document just tries to make it very clear that it is targeted to >> the authoritative side of the DNS equation. > > >>> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence states >>> there are three steps. I think this is an error : There are three >>> states, yes; but there are only two manipulations to perform. (to me >>> it seems logical to interpret "step" as : >>> "operation to perform") > >> Sure. More important is the fact that it is one step/stage shorter >> than Pre-publish ZSK rollover. > >>> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security >>> Lameness > >>> (actually, 4.1.3 introduces another way of KSK rollover. In that >>> respect the title of the section is confusing !) > >>> In 4.1.3 the text suggest to publish a DS record in the parent for >>> which there is no DNSKEY record in the child zone. > >> It suggests to publish a DS record for which there is no >> *corresponding* DNSKEY record in the child zone, next to an existing >> chain of trust between parent and child. That is different from "no >> DNSKEY record in the child zone". > >>> In 4.3.3 the text suggest the parent could verify that the DNSKEY is >>> actually published by the child. > >>> --> 4.3.3 could explicitly state that, if a parent performs >>> this kind of checking, then the "double DS method" of 4.1.3 is not >>> possible. > >> There is already a forward reference in section 4.1.3 to 4.3.3. > >>> Furthermore : as registry (for .eu) we think that it is important to >>> assist our registrars in setting DNSSEC up correctly. Consequently, >>> we do verification when a registrar sends us DNSSEC information. So >>> we cannot distinguish between a DNS Operator that performs double DS >>> KSK rollover and an operator making a mistake ... > >> I think you might have a false negative there: If a DNS operator >> requests for a second DS to be published, it does not break the chain >> of trust. Why classify it as a mistake? Double-DS rollover is >> perfectly acceptable within the boundaries of DNSSEC. > >>> 4) 4.3.4 DS Signature Validity Period The last paragraph holds a >>> sentence that states : "Shortening the TTL reduces the damage of a >>> successful replay attack." > >>> I don't think this is correct (or relevant). For me, the chances for >>> a replay attack increase with the signature validity period, not >>> with the value of the TTL. The value of the paragraph lays, for me, >>> in the propagation of updated DS RRsets (cfr the presentation on low >>> TTL's, last week). > >> You are right that the chances for a replay attack increase with the >> validity period, but the damage depends on how long that data will be >> in the cache. That depends on TTL. > >>> 5) 4.4.2.1 Maximum value (for Signature Validation Period) > >>> I think this paragraph should make a reference to Key Rollover ! >>> Motivation : no matter how long a signature is valid, in order for >>> it to be used, the corresponding Key must be available. (so : if the >>> reason for long RRSIG validity is not to recalculate them, then ...) > >>> I do admit that none of the Key Rollover scenario's take into >>> account the signature validity time (but the TTL). And indeed, >>> nothing prevents to generate a signature, valid for 1 year, with TTL >>> of 1 day, and perform key rollover every three months >>> : the still valid signature simply times out of the cache, to be >>> replaced by a new one, valid for a new year. > >> Hence, I don't think this paragraph should make a reference to key >> rollover. > >> Best regards, Matthijs > > >>> Kind regards, > >>> Marc Lampo EURid (for .eu) > > >>> -----Original Message----- From: internet-drafts@ietf.org >>> [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 AM >>> To: i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] I-D >>> Action: draft-ietf-dnsop-rfc4641bis-10.txt > > >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Domain Name System >>> Operations Working Group of the IETF. > >>> Title : DNSSEC Operational Practices, Version 2 >>> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename : >>> draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date : >>> 2012-03-30 > >>> This document describes a set of practices for operating the DNS >>> with security extensions (DNSSEC). The target audience is zone >>> administrators deploying DNSSEC. > >>> The document discusses operational aspects of using keys and >>> signatures in the DNS. It discusses issues of key generation, key >>> storage, signature generation, key rollover, and related policies. > >>> This document obsoletes RFC 4641 as it covers more operational >>> ground and gives more up-to-date requirements with respect to key >>> sizes and the DNSSEC operations. > > >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.t >>> x >>> >>> t > >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ > >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.tx >>> t > >>> >>> > > >>> _______________________________________________ DNSOP mailing list >>> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > >> _______________________________________________ DNSOP mailing list >> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhraeAAoJEA8yVCPsQCW5t54IANHgx1Kb01ifNjkFKn5eUaUd ku9oS8d7JdW+7Bt2ps+vTQeec4oUqZ4x6HcFJj38TRxFwHXoyTVL06UVtzLV8btG KQbAlTgYPbuxS5uE/BqAUXFeqtItLqbSvKHmD2GLMtKBm8/hRYpNYIfwn184Svmi /BHJxu0FQrRB0wCF5FCEsYasXRrd/JISaiNqGlyzBETQbCZl02RMUpvCu4RdLNy0 kz2EiBrxkkpvqoMlWRKv6ejR5MfhX07otzPTWWBTTu/ugIjcVxqCojjv299Mj1Oq nmjzrpm3C6hBFPhoYen6HXcpJQziZ5wM/c6hZqoJIAXUmhCyh/DGHNbCMcEaCJk= =2548 -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Thu Apr 12 05:21:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCF321F8604 for ; Thu, 12 Apr 2012 05:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5nCynn2Eblh for ; Thu, 12 Apr 2012 05:21:14 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 565E921F85FF for ; Thu, 12 Apr 2012 05:21:14 -0700 (PDT) X-ASG-Debug-ID: 1334233768-0369490e9a94100001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id WtjeNwgmJwIaVMCJ; Thu, 12 Apr 2012 14:29:28 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id A1DEDE4062; Thu, 12 Apr 2012 14:21:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRkN4Mm2qjzy; Thu, 12 Apr 2012 14:21:11 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 8E0D2E4050; Thu, 12 Apr 2012 14:21:11 +0200 (CEST) From: "Marc Lampo" To: Date: Thu, 12 Apr 2012 14:21:11 +0200 (CEST) X-ASG-Orig-Subj: Re: on "Negative Trust Anchors" Message-ID: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDA== Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1334233768 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: 'Nicholas Weaver' , ralf.weber@nominum.com, "'Livingood, Jason'" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:21:15 -0000 Hello, this is not a reply to any comment already made on this approach of "negative trust anchors". (I just posted a reply with RFC4641bis in the subject, about this) It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects "security lameness" (term used in RFC4641bis) its possible reaction could be to remove the DS information. The draft of Negative Trust Anchors does not mention anything about informing the operator of the failing domain. But since a parent domain operator should "know" who operates the child domains, they can also actively inform (eg. send email to registered contact person). That way, somebody can start working on correcting the root cause. The advantage over negative trust anchor would be that this is more centrally managed : the action by the parent (remove DS) is visible (TTL permitted) to any validating name server. (the negative trust anchor needs to be configured by every validating NS, whose administrators bother to do so) I acknowledge that negative trust anchor applies to however the chain-of-trust starts (from the root-zone, or from some DLV). But since the root is DNSSEC'd since close to 2 years, I expect the DLV approach is less important anyway. While my company, as registry for .eu, does not do this (yet ?), we do validate DNSSEC information when submitted, prior to publishing it as DS records (only if validation yields success). So, we already decide not to publish wrong information (at one point in time). The suggestion to regularly verify again extends that behaviour from "not publishing if wrong" (at submission time) to "stop publishing if wrong" (as part of normal operation) (the contract with registrars states that information provided by registrars must be correct. If not, the contract allows for some reactions (like blocking a domain in case of fake identities, but - by extension - to correctness of DNSSEC information) Marc Lampo Security Officer EURid (for .eu) From matthijs@nlnetlabs.nl Thu Apr 12 05:34:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE3621F8572 for ; Thu, 12 Apr 2012 05:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U68ch5kQ8QUY for ; Thu, 12 Apr 2012 05:34:09 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD2521F8576 for ; Thu, 12 Apr 2012 05:34:08 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3CCWHRg028761; Thu, 12 Apr 2012 14:32:17 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334233939; bh=xqOD1t8hjMc6RiDUsVPSrDbaR+bbb767wxaTblc4Hnk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Y06RlRh4Bgo43Jb8leq/FqRoYMKYtagKjrNvU8/K7Rw7kBChE5TtzVgRsemDAe291 LcTfZRdFgx6B/QFxGhUeH7+mQtPFsS+IRjB9xgxWho0LctCDyZeYHTc8FIXATfR2ct k6gIerQjL1flLIDbE0W7Jl5IU2Uc0elI/4cUkI8Q= Message-ID: <4F86CB50.7000708@nlnetlabs.nl> Date: Thu, 12 Apr 2012 14:32:16 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Lampo References: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> <002901cd10dd$e79b8bc0$b6d2a340$@lampo@eurid.eu> <4F7AB67F.6020603@nlnetlabs.nl> <008501cd1179$ce4cd830$6ae68890$@lampo@eurid.eu> <4F8697D2.7010809@nlnetlabs.nl> <000a01cd1899$dcf418e0$96dc4aa0$@lampo@eurid.eu> <4F86B69E.8070004@nlnetlabs.nl> <002d01cd18a5$1e389eb0$5aa9dc10$@lampo@eurid.eu> In-Reply-To: <002d01cd18a5$1e389eb0$5aa9dc10$@lampo@eurid.eu> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 12 Apr 2012 14:32:17 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:34:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2012 02:09 PM, Marc Lampo wrote: > Hello all, > > (This also concerns the other discussion about "Negative Trust > Anchors", I'll post with that subject as well) > > -----Original Message----- From: Matthijs Mekking > [mailto:matthijs@nlnetlabs.nl] ... >> Not only that, also the entities on the authoritative side don't >> have influence on the entities on the recursive side. > > Actually, there is something that influences the recursive side ! > (I'm referring to 4.3.3 "Security lameness", where is state > "removing a DS RR") Sorry that I didn't make myself clear, perhaps influence was a bad word here. Of course the changes you make in your zone influences the recursive side. What I (and the document) try to make clear is that entities on the authoritative side do not have influence on *the operations* at the recursive side. Are there more people who think the text in the introduction is confusing? If so, please speak up and preferably suggest other wordings. Furthermore, we are shifting away from your review item (1), which was about the text in the introduction. You are now talking about security lameness. There are already considerations about that topic in 4641bis. Your suggestion is already there, see Section 4.3.3! Best regards, Matthijs > > Since this document is about "DNSSEC Operational Practices", > perhaps include a suggestion that parents regularly (no frequency > defined) check the coherence of DS information they have against > DNSKEY information they find published. If the parent detects > "security lameness" its possible reaction could be to remove the DS > information. > > > While my company, as registry for .eu, does not do this (yet ?), we > do validate DNSSEC information when submitted, prior to publishing > it as DS records (only if validation yields success). So, we > already decide not to publish wrong information (at one point in > time). The suggestion to regularly verify again extends that > behaviour from "not publishing if wrong" (at submission time) to > "stop publishing if wrong" (as part of normal operation) (the > contract with registrars states that information provided by > registrars must be correct. If not, the contract allows for some > reactions (like blocking a domain in case of fake identities, but - > by extension - to correctness of DNSSEC information) > > The advantage over negative trust anchor would be that this is > more centrally managed : the action by the parent (remove DS) is > visible (TTL permitted) to any validating name server. (the > negative trust anchor needs to be configured by every validating > NS, whose administrators bother to do so. And good point for > Comcast who is obviously committed here !) > > I acknowledge that negative trust anchor applies to however the > chain-of-trust starts (from the root-zone, or from some DLV). But > since the root is DNSSEC'd since close to 2 years, I expect the DLV > approach is less important anyway. > > > Kind regards, > > Marc Lampo Security Officer EURid (for .eu) > > > -----Original Message----- From: Matthijs Mekking > [mailto:matthijs@nlnetlabs.nl] Sent: 12 April 2012 01:04 PM To: > Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-rfc4641bis-10.txt > > On 04/12/2012 12:48 PM, Marc Lampo wrote: >> Hello Matthijs, > >> Regarding 1 - "... no relationship ... validating ... " > >> Suggestion (a phrase that does not hint at any possible >> "relationship") : This document holds no information that applies >> to the configuration of validating recursive name servers >> (validators). > > Not only that, also the entities on the authoritative side don't > have influence on the entities on the recursive side. > > >> Ok regarding 2 : three stages > >> OK regarding 3 : consequences for validation by parents > >> (as a matter of fact, we're going to check if we adapt our >> present validation ourselves) > >> For 4 and 5 there was already an OK. > >> Kind regards, > >> Marc > > >> -----Original Message----- From: Matthijs Mekking >> [mailto:matthijs@nlnetlabs.nl] Sent: 12 April 2012 10:53 AM To: >> Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: >> draft-ietf-dnsop-rfc4641bis-10.txt > >> Hi Marc, > >> Coming back to your review items, I only think point 1 is not >> decided on yet. But I don't think this should stop progress. > >> You can find my responses in between lines. > >> Best regards, Matthijs > >> On 04/03/2012 11:11 AM, Marc Lampo wrote: >>> Hello again, > >>> About 1) If the document is for the authoritative side, why not >>> simply state so. Instead of this confusing statement about >>> relationship between authoritative and validating NS's ? > >> I believe it does state so, without confusion: The first sentence >> says the document is aimed for people that are active at the >> authoritative side. The second sentence says that we consider no >> relationship with the people running the recursive side. You >> think the document can do without the latter sentence. I think it >> is a fair assumption. > >>> About 2) So it is "two" steps ? > >> I made it three stages. ;) > >>> About 3) I forgot the word "corresponding", my fault there. As >>> such the text is not wrong, please don't misunderstand me. But >>> the parent the only way, for a parent, to known/verify that DS >>> information is correct, is by querying for the DNSKEY RRset and >>> check if the corresponding ( ;-) DNSKEY is indeed present. If >>> it is not, there is no way the parent can distinguish between a >>> child zone administrator performing a double-DS rollover or >>> making an error ... > >> The text is not wrong, so we do not need action for 4641bis >> here. > >> My point of view on this topic: > >> As long as there is a valid DS with corresponding DNSKEY, adding >> another DS is no error. Maybe you are afraid what happens if the >> child zone operator removes the old DNSKEY and replaces it with >> the new (mismatched) one. Now you have encountered the error. But >> such things are not specific to Double-DS rollover, it can happen >> also without being in a rollover: I could remove my DNSKEYs from >> my zone, and it would go bogus. Same thing. > >> My point is, as long as the zone is able to be validated, there >> is no error made (in terms of DNSSEC). > >>> About 4) I can agree with the present text. > >> Ok. > >>> About 5) Me too, I think published signatures should never be >>> expired. Consequently, every key rollover will make signatures >>> disappear that are, as such, not expired yet. From that point >>> of view it makes little difference if signature validity period >>> is a couple of weeks or months or years. > >>> But if the zone administrator uses long validity time with the >>> intention not to recalculate regularly, this implies that the >>> ZSK cannot rollover either. (and this is practice - out there, >>> right now ! There is one TLD that has signatures valid till >>> "the end of the current year", and never did any key rollover >>> since it started with DNSSEC) > >>> To conclude : I can "just" agree with the present text. > >> Ok. > > > > > >>> Kind regards, > >>> Marc Lampo EURid (for .eu) > >>> -----Original Message----- From: Matthijs Mekking >>> [mailto:matthijs@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM >>> To: Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D >>> Action: draft-ietf-dnsop-rfc4641bis-10.txt > >>> Hi, > >>> On 04/02/2012 04:35 PM, Marc Lampo wrote: >>>> Hello to the list, > >>>> Nice piece of work ! > >>>> Some remarks - nothing spectacular : 1) Last sentence in the >>>> first paragraph - Introduction (about : "no direct relation >>>> between ... and validating caching name servers.") > >>>> Isn't this sentence superfluous ? I fail to see where a >>>> possible relation would indeed change something to these >>>> guidelines. > >>>> But by including the sentence about no relationship, one >>>> starts to wonder if something escapes me ... > >>> The document just tries to make it very clear that it is >>> targeted to the authoritative side of the DNS equation. > > >>>> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence >>>> states there are three steps. I think this is an error : >>>> There are three states, yes; but there are only two >>>> manipulations to perform. (to me it seems logical to >>>> interpret "step" as : "operation to perform") > >>> Sure. More important is the fact that it is one step/stage >>> shorter than Pre-publish ZSK rollover. > >>>> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 >>>> Security Lameness > >>>> (actually, 4.1.3 introduces another way of KSK rollover. In >>>> that respect the title of the section is confusing !) > >>>> In 4.1.3 the text suggest to publish a DS record in the >>>> parent for which there is no DNSKEY record in the child >>>> zone. > >>> It suggests to publish a DS record for which there is no >>> *corresponding* DNSKEY record in the child zone, next to an >>> existing chain of trust between parent and child. That is >>> different from "no DNSKEY record in the child zone". > >>>> In 4.3.3 the text suggest the parent could verify that the >>>> DNSKEY is actually published by the child. > >>>> --> 4.3.3 could explicitly state that, if a parent performs >>>> this kind of checking, then the "double DS method" of 4.1.3 >>>> is not possible. > >>> There is already a forward reference in section 4.1.3 to >>> 4.3.3. > >>>> Furthermore : as registry (for .eu) we think that it is >>>> important to assist our registrars in setting DNSSEC up >>>> correctly. Consequently, we do verification when a registrar >>>> sends us DNSSEC information. So we cannot distinguish >>>> between a DNS Operator that performs double DS KSK rollover >>>> and an operator making a mistake ... > >>> I think you might have a false negative there: If a DNS >>> operator requests for a second DS to be published, it does not >>> break the chain of trust. Why classify it as a mistake? >>> Double-DS rollover is perfectly acceptable within the >>> boundaries of DNSSEC. > >>>> 4) 4.3.4 DS Signature Validity Period The last paragraph >>>> holds a sentence that states : "Shortening the TTL reduces >>>> the damage of a successful replay attack." > >>>> I don't think this is correct (or relevant). For me, the >>>> chances for a replay attack increase with the signature >>>> validity period, not with the value of the TTL. The value of >>>> the paragraph lays, for me, in the propagation of updated DS >>>> RRsets (cfr the presentation on low TTL's, last week). > >>> You are right that the chances for a replay attack increase >>> with the validity period, but the damage depends on how long >>> that data will be in the cache. That depends on TTL. > >>>> 5) 4.4.2.1 Maximum value (for Signature Validation Period) > >>>> I think this paragraph should make a reference to Key >>>> Rollover ! Motivation : no matter how long a signature is >>>> valid, in order for it to be used, the corresponding Key must >>>> be available. (so : if the reason for long RRSIG validity is >>>> not to recalculate them, then ...) > >>>> I do admit that none of the Key Rollover scenario's take into >>>> account the signature validity time (but the TTL). And >>>> indeed, nothing prevents to generate a signature, valid for 1 >>>> year, with TTL of 1 day, and perform key rollover every three >>>> months : the still valid signature simply times out of the >>>> cache, to be replaced by a new one, valid for a new year. > >>> Hence, I don't think this paragraph should make a reference to >>> key rollover. > >>> Best regards, Matthijs > > >>>> Kind regards, > >>>> Marc Lampo EURid (for .eu) > > >>>> -----Original Message----- From: internet-drafts@ietf.org >>>> [mailto:internet-drafts@ietf.org] Sent: 30 March 2012 11:36 >>>> AM To: i-d-announce@ietf.org Cc: dnsop@ietf.org Subject: >>>> [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt > > >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> Domain Name System Operations Working Group of the IETF. > >>>> Title : DNSSEC Operational Practices, Version 2 >>>> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename : >>>> draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date >>>> : 2012-03-30 > >>>> This document describes a set of practices for operating the >>>> DNS with security extensions (DNSSEC). The target audience >>>> is zone administrators deploying DNSSEC. > >>>> The document discusses operational aspects of using keys and >>>> signatures in the DNS. It discusses issues of key >>>> generation, key storage, signature generation, key rollover, >>>> and related policies. > >>>> This document obsoletes RFC 4641 as it covers more >>>> operational ground and gives more up-to-date requirements >>>> with respect to key sizes and the DNSSEC operations. > > >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.t >>>> >>>> x >>>> >>>> > t > >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.tx >>>> >>>> t > >>>> >>>> > > >>>> _______________________________________________ DNSOP mailing >>>> list DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop > >>> _______________________________________________ DNSOP mailing >>> list DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop > >> _______________________________________________ DNSOP mailing >> list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhstQAAoJEA8yVCPsQCW55K0H/1VJWKaDEmA9m3liyJb3aib1 28oC3zy3/PsEHyhz5B4HPN7vwi2Hg8j9EFIgu7UZYyn7nYG5MVvfnUZTgHXYg/zr 5nTFDckITbUk0gRO3IyMhBmXx5GVySot4vBNDH7vi0TQXUQ9QMvpqsnzllCplhTb sRaEtLNku2SzoMCJtkKYsrdsXWUtgU+AQwq3Ik+WwdM2L79FjypKKpwrmL6xbvSM setOYGOeD88wdrR3InQ/PGkYOtpmGBHxRvG6G89vVbnpzeCAbZ4un91pZIcbYfuY FEbwxfbvsC09jrIEWhkQz88T6xyDH0wTi75hkcmcElB4hasfAaTBDmQdjAj+Pdo= =pIOC -----END PGP SIGNATURE----- From Ralf.Weber@nominum.com Thu Apr 12 05:50:18 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9DE21F8653 for ; Thu, 12 Apr 2012 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEfmviy6oUvO for ; Thu, 12 Apr 2012 05:50:17 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6B21F8539 for ; Thu, 12 Apr 2012 05:50:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT4bPiLaW1HaMCXBFVTS5K31eKZbE3hTT@postini.com; Thu, 12 Apr 2012 05:50:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1120C1B833B for ; Thu, 12 Apr 2012 05:50:16 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F3691190071; Thu, 12 Apr 2012 05:50:15 -0700 (PDT) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 12 Apr 2012 05:50:15 -0700 From: Ralf Weber To: Marc Lampo Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiA Date: Thu, 12 Apr 2012 12:50:15 +0000 Message-ID: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> In-Reply-To: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B85B615B1444F48B85700C58BC59F02@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Livingood, Jason" , "" , Nicholas Weaver Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:50:18 -0000 Moin! On 12.04.2012, at 14:21, Marc Lampo wrote: > It holds an alternative possibility to overcome the problem > - for operators of validating name servers - of failing domains > because of DNSSEC. >=20 > The alternative is to have a parent regularly (no frequency defined) > check the coherence of DS information they have against DNSKEY informatio= n > it finds published. > If the parent detects "security lameness" (term used in RFC4641bis) its > possible reaction could be to remove the DS information. It is something completely different and I certainly welcome TLDs doing tha= t. But it's not an alternative it's an addition. Someone who wants to opera= te DNSSEC aware resolvers that validate today must have the ability to depl= oy negative trust anchors IMHO. > The draft of Negative Trust Anchors does not mention anything about > informing the operator of the failing domain. > But since a parent domain operator should "know" who operates the > child domains, they can also actively inform (eg. send email to registere= d > contact person). That way, somebody can start working on correcting > the root cause. Agreed, we should amend section 7 with steps to do when a negative trust an= chor is discovered and that should be one of them. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From stephan.lagerholm@secure64.com Thu Apr 12 07:28:49 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4265721F85D2 for ; Thu, 12 Apr 2012 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv1QxgJVFsI5 for ; Thu, 12 Apr 2012 07:28:48 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77321F85F7 for ; Thu, 12 Apr 2012 07:28:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 45A77B850D; Thu, 12 Apr 2012 08:28:47 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6cWUH6mc8VE; Thu, 12 Apr 2012 08:28:46 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 6F105B84E1; Thu, 12 Apr 2012 08:28:46 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1334240926; bh=M64Axk3IxZiEifY5PeDolfE7sXM9cz+PErcOnbrLh/4=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=scoOBHK7jECMAEKcla wIQiFoqS9Z5vwtZziBrYp4+KpTsEU18CoETBT+x6B1HKEsocyziTDjh2IC0n8+ddKa9 kBuivBxCFqu4qKeRVqCtwO2Nf1ey2Slcp+J67w5MJNBUNAJgI5UBdSsx5eTQeXoA1Xr O1q+Mt8c85o33k8Cm1Q= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 08:27:21 -0600 Message-ID: In-Reply-To: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAAAt3PkA= References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> From: "Stephan Lagerholm" To: "Ralf Weber" , "Marc Lampo" Cc: Nicholas Weaver , dnsop@ietf.org, "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:28:49 -0000 Mark, On 12.04.2012, at 14:21, Marc Lampo wrote: > > It holds an alternative possibility to overcome the problem > > - for operators of validating name servers - of failing domains > > because of DNSSEC. > > > > The alternative is to have a parent regularly (no frequency defined) > > check the coherence of DS information they have against DNSKEY > > information it finds published. > > If the parent detects "security lameness" (term used in RFC4641bis) > > its possible reaction could be to remove the DS information. =3D> From my experience, "active parenting" is not a good practice. Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. /S From ajs@anvilwalrusden.com Thu Apr 12 07:47:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B153B21F859E for ; Thu, 12 Apr 2012 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf6yTx9yGHEW for ; Thu, 12 Apr 2012 07:47:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3531021F8535 for ; Thu, 12 Apr 2012 07:47:10 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5C6E41ECB41C for ; Thu, 12 Apr 2012 14:47:09 +0000 (UTC) Date: Thu, 12 Apr 2012 10:47:07 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20120412144702.GJ40367@mail.yitter.info> References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:47:10 -0000 On Thu, Apr 12, 2012 at 08:27:21AM -0600, Stephan Lagerholm wrote: > Specifically in this case, you are assuming that the parent knows the > algorithms used for the DS record. He would have to in order to > validate. That might not always hold true. Additionally, the record is > not 'yours', it is just parked in your zone by the child. For the parent > to Tamper with either the NS or DS is IMHO not a good practice. The DS is _not_ parked in the parent zone by the child. Unlike the NS record, the DS record is authoritative data at the parent, and never at the child. As I read the RFCs, the DS record is fully and completely parent-side data, and is the parent's assertion of its relationship to the child. I really think we have to get over the idea that the DS record is somehow "the child's data" that is merely represented in the parent side. That way of thinking about this is a good way, IMO, to get failed chains across the zone cut. IMO it is better to think of the DS/DNSKEY pair as a way of expressing accord across a zone cut, with each side contributing a portion of the effort and holding a portion of the responsibility. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From wjhns1@hardakers.net Thu Apr 12 09:23:42 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62FD21F85F8 for ; Thu, 12 Apr 2012 09:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfSSz4lpADRM for ; Thu, 12 Apr 2012 09:23:41 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F0121F853C for ; Thu, 12 Apr 2012 09:23:39 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id D16BECE; Thu, 12 Apr 2012 09:23:38 -0700 (PDT) From: Wes Hardaker To: Joe Abley References: <0lk41nqg9o.fsf@wjh.hardakers.net> <1B8D7D00-2C39-4C62-BB3C-D8F77D936B99@nominum.com> <0laa2i6yj8.fsf@wjh.hardakers.net> <90BF4A42-4645-4584-963B-6B1DC9D6DA1C@icann.org> Date: Thu, 12 Apr 2012 09:23:37 -0700 In-Reply-To: <90BF4A42-4645-4584-963B-6B1DC9D6DA1C@icann.org> (Joe Abley's message of "Wed, 11 Apr 2012 09:56:13 -0700") Message-ID: <0lwr5kor5i.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "Livingood, Jason" , Ralf Weber , Nicholas Weaver , dnsop , Wes Hardaker Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:23:42 -0000 Joe Abley writes: > On 2012-04-11, at 12:09, Wes Hardaker wrote: >> NTA example.com Thu Apr 12 09:06:42 PDT 2012 > > I realise this is just a thought experiment Well, true it certainly is. And in fact the above thought experiment wasn't meant to imply a resource record, but rather a config line. I should have probably written it like this: NTA { example.com Thu Apr 12 09:06:42 PDT 2012; }; Or something. In actuality, I'd expect every implementation to have a different config file structure of couse. -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Thu Apr 12 09:24:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B252821F85F8 for ; Thu, 12 Apr 2012 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2BypQH3DzZ5 for ; Thu, 12 Apr 2012 09:24:25 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3B821F8593 for ; Thu, 12 Apr 2012 09:24:24 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id CA669CE; Thu, 12 Apr 2012 09:24:22 -0700 (PDT) From: Wes Hardaker To: Paul Wouters References: <0lk41nqg9o.fsf@wjh.hardakers.net> <30336D56-6523-4900-8CA5-B870045E4282@cable.comcast.com> <20120411134023.6d52d9c2@shane-eeepc.home.time-travellers.org> <20120411164820.678bcf96@shane-eeepc.home.time-travellers.org> Date: Thu, 12 Apr 2012 09:24:22 -0700 In-Reply-To: (Paul Wouters's message of "Wed, 11 Apr 2012 14:00:06 -0400 (EDT)") Message-ID: <0lsjg8or49.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop , Shane Kerr Subject: Re: [DNSOP] Maximum negative trust anchor duration, was New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:24:26 -0000 Paul Wouters writes: > On Wed, 11 Apr 2012, Shane Kerr wrote: > >> Disabling DNSSEC validation for broken domains seems completely >> rational, at least for some types of brokenness. > > So someone will make a browser plugin to enable this. Let them. In our validation work within firefox we deliberately did *not* put in a "continue anyway" button. -- Wes Hardaker SPARTA, Inc. From marka@isc.org Thu Apr 12 16:10:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72FB21F8738 for ; Thu, 12 Apr 2012 16:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GlCbns0BI2p for ; Thu, 12 Apr 2012 16:10:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3E721F86F6 for ; Thu, 12 Apr 2012 16:10:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9405AC941E; Thu, 12 Apr 2012 23:10:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e400:548e:fd23:2876]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 41F74216C36; Thu, 12 Apr 2012 23:10:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1D98A1FA6BDA; Fri, 13 Apr 2012 09:10:02 +1000 (EST) To: "Stephan Lagerholm" From: Mark Andrews References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> In-reply-to: Your message of "Thu, 12 Apr 2012 08:27:21 CST." Date: Fri, 13 Apr 2012 09:10:01 +1000 Message-Id: <20120412231002.1D98A1FA6BDA@drugs.dv.isc.org> Cc: dnsop@ietf.org, "Livingood, Jason" , Ralf Weber , Nicholas Weaver , Marc Lampo Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 23:10:24 -0000 In message , "Steph an Lagerholm" writes: > Mark, > > On 12.04.2012, at 14:21, Marc Lampo wrote: > > > It holds an alternative possibility to overcome the problem > > > - for operators of validating name servers - of failing domains > > > because of DNSSEC. > > > > > > The alternative is to have a parent regularly (no frequency defined) > > > check the coherence of DS information they have against DNSKEY > > > information it finds published. > > > If the parent detects "security lameness" (term used in RFC4641bis) > > > its possible reaction could be to remove the DS information. > > => From my experience, "active parenting" is not a good practice. > Specifically in this case, you are assuming that the parent knows the > algorithms used for the DS record. He would have to in order to > validate. That might not always hold true. Additionally, the record is > not 'yours', it is just parked in your zone by the child. For the parent > to Tamper with either the NS or DS is IMHO not a good practice. There is a difference between "Tamper" and "Hey, you stuffed up. You need to fix the delegation or we will remove it as it is causing operational problems" and yes there *are* RFCs that permit this to happen. Parents are already REQUIRED to make these sorts of checks of the records involved in the delegation according to RFC 1034. As for not knowing the DS algorithm what is just garbage. For DS records to be useful the algorithms need to be well known. There are no private DS algorithms. Mark > /S > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From stephan.lagerholm@secure64.com Thu Apr 12 18:59:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3468721F872B for ; Thu, 12 Apr 2012 18:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOgkPbxSVSe5 for ; Thu, 12 Apr 2012 18:59:06 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7517821F86C3 for ; Thu, 12 Apr 2012 18:59:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id E3D52B852E; Thu, 12 Apr 2012 19:59:05 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-4tNMAYcZJF; Thu, 12 Apr 2012 19:59:05 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 06EBFB8527; Thu, 12 Apr 2012 19:59:05 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1334282345; bh=tVRRc8F275zXBAJ8/y8rd5XPjuy5OUeJrh6OrMnEQZQ=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=pSizrSmxhFtuS571Gx zrQv8J0TLb2Zt6iR69OsGkyJFj0bWamLRNz7OOYm8Nmj/S+xcyaVasaEr7B9DdtT9dE HVOD9M2s1J81gUzqZ6vyS7LV2/qlQfMy2A7ExVXqjWisr83nf74qetY2YzcPpPtAS77 mRuY77h4i/oTmYOwh4I= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 19:57:35 -0600 Message-ID: In-Reply-To: <20120412231002.1D98A1FA6BDA@drugs.dv.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0ZAXTv8v6Eop4CRx6qh36sQJHSXgAFNOoA References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <20120412231002.1D98A1FA6BDA@drugs.dv.isc.org> From: "Stephan Lagerholm" To: "Mark Andrews" Cc: dnsop@ietf.org, "Livingood, Jason" , Ralf Weber , Nicholas Weaver , Marc Lampo Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:59:07 -0000 Mark Andrews Thursday, April 12, 2012 6:10 PM: > > On 12.04.2012, at 14:21, Marc Lampo wrote: > > > > It holds an alternative possibility to overcome the problem > > > > - for operators of validating name servers - of failing domains > > > > because of DNSSEC. > > > > > > > > The alternative is to have a parent regularly (no frequency > > > > defined) check the coherence of DS information they have against > > > > DNSKEY information it finds published. > > > > If the parent detects "security lameness" (term used in > > > > RFC4641bis) its possible reaction could be to remove the DS > information. > > > > =3D> From my experience, "active parenting" is not a good practice. > > Specifically in this case, you are assuming that the parent knows the > > algorithms used for the DS record. He would have to in order to > > validate. That might not always hold true. Additionally, the record > is > > not 'yours', it is just parked in your zone by the child. For the > > parent to Tamper with either the NS or DS is IMHO not a good > practice. >=20 > There is a difference between "Tamper" and "Hey, you stuffed up. > You need to fix the delegation or we will remove it as it is causing > operational problems" and yes there *are* RFCs that permit this to > happen. Being Insecure is not necessary better than being Bogus. "Hey you got hacked, so we will remove the DS so that people can get to that bogus site" > Parents are already REQUIRED to make these sorts of checks of the > records involved in the delegation according to RFC 1034. If you do an algorithm rollover, then you will have two DS at the parent but only one will correspond to a DNSKEY at the zone. > As for not knowing the DS algorithm what is just garbage. For DS > records to be useful the algorithms need to be well known. There are > no private DS algorithms. That is not how I read RFC 4034, section 5.1.2 and appendix A.1.=20 What am I missing? "The algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the=20 algorithm number types." 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL 255 reserved /S From marka@isc.org Thu Apr 12 21:43:00 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBD221F87B7 for ; Thu, 12 Apr 2012 21:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9uyewokymOl for ; Thu, 12 Apr 2012 21:42:59 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 69FC321F87A2 for ; Thu, 12 Apr 2012 21:42:59 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 368415F98BC; Fri, 13 Apr 2012 04:42:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e400:548e:fd23:2876]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C0040216C36; Fri, 13 Apr 2012 04:42:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 15F491FABD7E; Fri, 13 Apr 2012 14:42:34 +1000 (EST) To: "Stephan Lagerholm" From: Mark Andrews References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <20120412231002.1D98A1FA6BDA@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 12 Apr 2012 19:57:35 CST." Date: Fri, 13 Apr 2012 14:42:34 +1000 Message-Id: <20120413044235.15F491FABD7E@drugs.dv.isc.org> Cc: dnsop@ietf.org, "Livingood, Jason" , Ralf Weber , Nicholas Weaver , Marc Lampo Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 04:43:00 -0000 In message , "Steph an Lagerholm" writes: > Mark Andrews Thursday, April 12, 2012 6:10 PM: > > > > On 12.04.2012, at 14:21, Marc Lampo wrote: > > > > > It holds an alternative possibility to overcome the problem > > > > > - for operators of validating name servers - of failing domains > > > > > because of DNSSEC. > > > > > > > > > > The alternative is to have a parent regularly (no frequency > > > > > defined) check the coherence of DS information they have against > > > > > DNSKEY information it finds published. > > > > > If the parent detects "security lameness" (term used in > > > > > RFC4641bis) its possible reaction could be to remove the DS > > information. > > > > > > =3D> From my experience, "active parenting" is not a good practice. > > > Specifically in this case, you are assuming that the parent knows > the > > > algorithms used for the DS record. He would have to in order to > > > validate. That might not always hold true. Additionally, the record > > is > > > not 'yours', it is just parked in your zone by the child. For the > > > parent to Tamper with either the NS or DS is IMHO not a good > > practice. > >=20 > > There is a difference between "Tamper" and "Hey, you stuffed up. > > You need to fix the delegation or we will remove it as it is causing > > operational problems" and yes there *are* RFCs that permit this to > > happen. > > Being Insecure is not necessary better than being Bogus. "Hey you got > hacked, so we will remove the DS so that people can get to that bogus > site" I said remove the delegation. Get their attention as doing anything else doesn't work. > > Parents are already REQUIRED to make these sorts of checks of the > > records involved in the delegation according to RFC 1034. > > If you do an algorithm rollover, then you will have two DS at the > parent but only one will correspond to a DNSKEY at the zone. Garbage. You don't add DS records until there are DNSKEYs for the algorithm and you remove all DS records for the old algorithm *before* you remove the DNSKEY for the old algorithm. If you fail to do this you will introduce validation failures. You can have DS records that don't correspond to a DNSKEY but the algorithm MUST match one that does correspond to a DNSKEY. This lets you publish a single KSK DNSKEY per algorithm. > > As for not knowing the DS algorithm what is just garbage. For DS > > records to be useful the algorithms need to be well known. There are > > no private DS algorithms. > > That is not how I read RFC 4034, section 5.1.2 and appendix A.1.=20 > What am I missing? > > "The algorithm number used by the DS RR is identical to the algorithm > number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the=20 > algorithm number types." > > 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY > 252 Indirect [INDIRECT] n - > 253 Private [PRIVATEDNS] y see below OPTIONAL > 254 Private [PRIVATEOID] y see below OPTIONAL > 255 reserved DS records have a DNSSEC algorithm which matches the DNSKEY and a DS hash algorithm. You can compute a DS record without knowing the DNSSEC algorithm. You can match DS records to DNSKEY records without knowing the DNSSEC algorithm. You do need to know the DS hash algorithm and there are no private DS hash algorithms. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From shane@castlepoint.net Thu Apr 12 22:56:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40FD21F85EF for ; Thu, 12 Apr 2012 22:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWsH8B3dUqDi for ; Thu, 12 Apr 2012 22:56:46 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 224DD21F85B7 for ; Thu, 12 Apr 2012 22:56:46 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C4548268063; Thu, 12 Apr 2012 23:56:45 -0600 (MDT) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for dnsop@ietf.org; Thu, 12 Apr 2012 23:56:45 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=49768; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 From: Shane Amante Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 23:56:30 -0600 Message-Id: To: dnsop@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [DNSOP] draft-gersch-dnsop-revdns-cidr-01: Alternative Encoding for Names at Octet Boundaries X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 05:56:46 -0000 I think this is a good draft. I do have one comment, based on experimenting with both encoding a /16 = in DNS zone files and the resulting lookups on those IP prefixes = contained under it. As this document progresses I would very much like = to advocate that the WG considers picking a single method for encoding = the prefixes in zone files and, just as importantly, that the only = method be the one outlined in Section 5.3: http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01#section-5.3 Ultimately, I found it somewhat confusing to obey the encoding rules = defined in Section 5.1 wrt octet/nibble-aligned vs. = non-octet/nibble-aligned IP prefixes. As one real-world example, = consider the case of a IPv4 /8, with a variety of octet vs. non-octet = aligned prefixes allocated (for routing) and delegated (for DNS) to = downstream customers. In that case, tools use to encode in the DNS zone = files, as well as look them up (e.g.: dig), must not use "m" notation = for prefixes at /8, /16 and /24 boundaries. However, for prefixes at = non-octet aligned boundaries, (e.g.: /9, /18, /20, etc.), they do need = to use "m" notation. I believe the problem will only get substantially = worse when considering nibble vs. non-nibble boundaries for IPv6 = prefixes being encoded. While the current draft has tried to do a good job prescribing the rules = for encoding & looking up prefixes on octet/nibble vs. = non-octet/non-nibble boundaries in Section 5.1, I've found that it is = substantially more simple using a single naming scheme in Section 5.3 = for all prefix lengths. Thus, I would propose that the WG consider all = IP prefixes be encoded as per what has been defined in Section 5.3. = Ultimately, I think this should result in simpler tools used to encode = the zones and, just as importantly, tools that will be developed to = look-up RRsets in these zones. Lastly, FWIW, I agree with the practical operational considerations = provided in paragraphs 2 - 4 of Section 5.3 as to why having the "m" = sub-domain for holding the IP prefixes is a good thing, hence why I = recommend that be the single approach. I would welcome others thoughts on the matter. -shane= From internet-drafts@ietf.org Fri Apr 13 00:11:34 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B818821F85B4; Fri, 13 Apr 2012 00:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixWK1psaPwlb; Fri, 13 Apr 2012 00:11:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0017421F85B6; Fri, 13 Apr 2012 00:11:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 00:11:33 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 07:11:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Domain Name System Operations Working= Group of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename : draft-ietf-dnsop-rfc4641bis-11.txt Pages : 79 Date : 2012-04-13 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt From matthijs@nlnetlabs.nl Fri Apr 13 00:13:52 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8584F21F8699 for ; Fri, 13 Apr 2012 00:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQsHrxtJicGE for ; Fri, 13 Apr 2012 00:13:50 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7364221F8454 for ; Fri, 13 Apr 2012 00:13:50 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3D7DlhQ021219 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 13 Apr 2012 09:13:48 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334301229; bh=pwKGYSpNazzqEqmxb+/3w8QjPLmB2ro0yxvhvr6rrZk=; h=Date:From:To:Subject:References:In-Reply-To; b=WSlX1LamHO94c30LGv0D/bt9AP+p0baS1HeLWoENbtTZytCa6IMmqRuSVxGnQ19vP isOQJ8BPXHxvxSz0jLj5czN0aF8coj2NcjybPoZnDZUy6MYxGW7VIWRd0BntAU+goM 5mPT9GcWxIb3ZtHcvBOhU5JHWNTImbqm55hJuaec= Message-ID: <4F87D22B.3050709@nlnetlabs.nl> Date: Fri, 13 Apr 2012 09:13:47 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> In-Reply-To: <20120413071133.3506.32267.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 13 Apr 2012 09:13:48 +0200 (CEST) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 07:13:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI: This version adopts the review items from Alfred and Marc. Best regards, Matthijs On 04/13/2012 09:11 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Domain Name System > Operations Working Group of the IETF. > > Title : DNSSEC Operational Practices, Version 2 Author(s) > : Olaf M. Kolkman W. (Matthijs) Mekking Filename : > draft-ietf-dnsop-rfc4641bis-11.txt Pages : 79 Date > : 2012-04-13 > > This document describes a set of practices for operating the DNS > with security extensions (DNSSEC). The target audience is zone > administrators deploying DNSSEC. > > The document discusses operational aspects of using keys and > signatures in the DNS. It discusses issues of key generation, key > storage, signature generation, key rollover, and related policies. > > This document obsoletes RFC 4641 as it covers more operational > ground and gives more up-to-date requirements with respect to key > sizes and the DNSSEC operations. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt > > _______________________________________________ DNSOP mailing > list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPh9IjAAoJEA8yVCPsQCW5ahgH+wehFS/Y3JqQ/5Ii6cmtRtIA aOjO0n+aNG8C0vuyAe4876gm+GdyYeoN8ZEd+BG0O0oy4/djvm6GaExFMLoQoGgz 6h8zqnCA3Gj4KtVBONLMXbl40xWkQxWMPOG3rx3hzjLVxACsQhr2uNg3xczfDqhy oUpER1Cpq90876O+lvd/pqnwcnEzSoXaNz4nZT4Yr0sB6W19OLjVziN0yIAUgjpp +Zafkw4QQGlkh9PLG+8W/bYf2Y3FMtmxdS1ZrZP8SW3RiBVBM00x9rKDtnuHhfDo 8JRfUyfBPiA/Q7+uexah9ivb4K0SPuKfBMpZccQz53nTxAEEGG3/bp99TXkQZzQ= =viD7 -----END PGP SIGNATURE----- From as112-ops@trex.fi Thu Apr 12 07:25:39 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B14A21F85B7 for ; Thu, 12 Apr 2012 07:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4ZINxinXsK5 for ; Thu, 12 Apr 2012 07:25:38 -0700 (PDT) Received: from mail.axu.tm (mail.axu.tm [IPv6:2001:1430:a:4950:a00:3eff:fe66:15]) by ietfa.amsl.com (Postfix) with ESMTP id 45A5A21F85B5 for ; Thu, 12 Apr 2012 07:25:37 -0700 (PDT) Received: from [IPv6:2001:1430:a:40a:20e:cff:fe5d:ef87] (heppa.axu.iki.fi [IPv6:2001:1430:a:40a:20e:cff:fe5d:ef87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "heppa.axu.iki.fi", Issuer "Axu TM CA 2011-2013" (verified OK)) by mail.axu.tm (Postfix) with ESMTPS id BC8C756D0; Thu, 12 Apr 2012 14:25:34 +0000 (UTC) Message-ID: <4F86E5DE.1010205@trex.fi> Date: Thu, 12 Apr 2012 17:25:34 +0300 From: Aleksi Suhonen User-Agent: Mozilla/5.0 (X11; U; Linux sparc64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: dnsop@ietf.org, "as112-ops@mail.dns-oarc.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 13 Apr 2012 00:41:57 -0700 Subject: Re: [DNSOP] [as112-ops] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item (fwd) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:26:03 -0000 Hello, Joe Abley wrote: > I think that we need a better mechanism to avoid lame delegations to the > AS112 servers, given their loosely-coordinated nature. > I like the idea that came up in Québec (which I shall attribute to > Warren Kumari since I've seen other people do that, although I was not > in the room at the time) that the add/drop problem is a lot simpler if > every AS112 node hosts the zone +1 > $ORIGIN . > @ SOA ... > NS something > NS sensible I think the AS112 root zone database could look something like this: $ORIGIN . $TTL 3600000 . IN SOA ( 2012041200 3600 900 604800 86400 ) . IN NS as112-tracker.dns-oarc.net. . IN NS blackhole-1.as112.net. . IN NS blackhole-2.as112.net. as112-tracker.dns-oarc.net. IN A as112-tracker.dns-oarc.net. IN AAAA blackhole-1.as112.net. IN A blackhole-1.as112.net. IN AAAA blackhole-2.as112.net. IN A blackhole-2.as112.net. IN AAAA hostname.as112.net. IN TXT ", " hostname.as112.net. IN TXT "See http://as112.net/ for more information." hostname.as112.net. IN LOC Purpose of this tracker is to allow WfMS et al to know where all the nodes are. The node-fqdn is supposed to be a unicast (as opposed to anycast) address and it should also be configured as the notify-source. > and answers authoritatively on the addresses corresponding to > "something" and "sensible", returning NXDOMAIN for everything in the > entire namespace apart from . (for which they ought never receive > queries anyway). This is ugly to some eyes, but it works for domainers > and it ought to work for us too. Any zones that were subsequently > delegated to "something" and "sensible" (e.g. as part of an IANA action) > would be immediately supported with no need for changes on any of the > nodes offering service for "something" and "sensible". As in my example above, the empty "fake root zone" needs to still have at least hostname.as112.net as well... > This document (as112-cull) attempts to do some of this work, but I don't > see a reason to bite off small mouthfuls if we can expend a small amount > of extra effort and eat the whole sandwich at once. Hear hear. -- Aleksi Suhonen From stephan.lagerholm@secure64.com Fri Apr 13 07:21:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FF021F863F for ; Fri, 13 Apr 2012 07:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91m+O7mOdCo8 for ; Fri, 13 Apr 2012 07:21:54 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 031F621F8620 for ; Fri, 13 Apr 2012 07:21:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id EF243B8531; Fri, 13 Apr 2012 08:21:52 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8zAXZFiRAan; Fri, 13 Apr 2012 08:21:51 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 9C9C0B852E; Fri, 13 Apr 2012 08:21:51 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1334326911; bh=A2wNR7/W3Ao8+ZqlHQuL9SlE2wta1/8PnTQTzYjmDkU=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=gHFJEJJH2I8yOGqhKi LlxDWNyqmsceCgkXi0EmI8X4O6ElFpNx8iBfUiRmOUle5CtNpQXQzzbyK3ZDsvaNXcX lw4aZyyE4hakOPYLNth52HjN3rboqnEUmWmULG6p5XMirxlvRudvJwxlaeeyIunh9Wm mezPodhfQjD6LvJKkOw= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2012 08:20:49 -0600 Message-ID: In-Reply-To: <20120413044235.15F491FABD7E@drugs.dv.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0ZL+zNK8vSLLEdSyKYw1MVeeMUhwATlaXg References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <20120412231002.1D98A1FA6BDA@drugs.dv.isc.org> <20120413044235.15F491FABD7E@drugs.dv.isc.org> From: "Stephan Lagerholm" To: "Mark Andrews" Cc: dnsop@ietf.org, "Livingood, Jason" , Ralf Weber , Nicholas Weaver , Marc Lampo Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 14:21:54 -0000 Mark Andrews, Thursday, April 12, 2012 11:43 PM: > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Thursday, April 12, 2012 11:43 PM > To: Stephan Lagerholm > Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood, > Jason > Subject: Re: [DNSOP] on "Negative Trust Anchors" >=20 > In message > , "Steph > an Lagerholm" writes: > > Mark Andrews Thursday, April 12, 2012 6:10 PM: > > > > > > On 12.04.2012, at 14:21, Marc Lampo wrote: > > > > > > It holds an alternative possibility to overcome the problem > > > > > > - for operators of validating name servers - of failing > > > > > > domains because of DNSSEC. > > > > > > > > > > > > The alternative is to have a parent regularly (no frequency > > > > > > defined) check the coherence of DS information they have > > > > > > against DNSKEY information it finds published. > > > > > > If the parent detects "security lameness" (term used in > > > > > > RFC4641bis) its possible reaction could be to remove the DS > > > information. > > > > > > > > =3D3D> From my experience, "active parenting" is not a good > practice. > > > > Specifically in this case, you are assuming that the parent knows > > the > > > > algorithms used for the DS record. He would have to in order to > > > > validate. That might not always hold true. Additionally, the > > > > record > > > is > > > > not 'yours', it is just parked in your zone by the child. For the > > > > parent to Tamper with either the NS or DS is IMHO not a good > > > practice. > > >=3D20 > > > There is a difference between "Tamper" and "Hey, you stuffed up. > > > You need to fix the delegation or we will remove it as it is > causing > > >operational problems" and yes there *are* RFCs that permit this to > > >happen. > > > > Being Insecure is not necessary better than being Bogus. "Hey you got > > hacked, so we will remove the DS so that people can get to that bogus > > site" >=20 > I said remove the delegation. Get their attention as doing anything > else doesn't work. I have yet to understand how your parent to child DNS probes works. Specifically, if you can explain to me how you are distinguishing between: A) The DS and the DNSKEY does not match because there is an operational error at the child And B) The DS and the DNSKEY does not match because somebody is doing a "man in the middle" on my probes. Going back to the original claim that " alternative is to have a parent regularly check the coherence of DS information and that a possible reaction could be to remove the DS" I'm not supportive of such "active parenting" idea. I find the idea of negative trust anchors useful for recursive resolvers given that the operator of such recursive resolver uses a secure out of band technology to make sure that there is an operational mistake.=20 =20 From marc.lampo@eurid.eu Fri Apr 13 07:42:06 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80121F84B3 for ; Fri, 13 Apr 2012 07:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifsNHier-PPJ for ; Fri, 13 Apr 2012 07:42:05 -0700 (PDT) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id 88C3621F84AE for ; Fri, 13 Apr 2012 07:42:04 -0700 (PDT) X-ASG-Debug-ID: 1334328123-02dadd06672e15a0001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id DFcXHD10iOiOCe2q; Fri, 13 Apr 2012 16:42:03 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id EFD9EE408B; Fri, 13 Apr 2012 16:42:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxV1VQq5Q5wi; Fri, 13 Apr 2012 16:42:02 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id D9628E4050; Fri, 13 Apr 2012 16:42:02 +0200 (CEST) From: "Marc Lampo" To: "'Stephan Lagerholm'" , "'Mark Andrews'" References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <20120412231002.1D98A1FA6BDA@drugs.dv.isc.org> <20120413044235.15F491FABD7E@drugs.dv.isc.org> In-Reply-To: Date: Fri, 13 Apr 2012 16:42:02 +0200 (CEST) X-ASG-Orig-Subj: RE: [DNSOP] on "Negative Trust Anchors" Message-ID: <018e01cd1983$96ca6870$c45f3950$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0ZL+zNK8vSLLEdSyKYw1MVeeMUhwATlaXgAAEGJdA= Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1334328123 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: "'Livingood, Jason'" , 'Ralf Weber' , 'Nicholas Weaver' , dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 14:42:06 -0000 Stephan, An interesting approach : "if a parent removes DS information for a child, if it finds the child to be in error, then, can an attacker make the check fail (in order to get the DS removed) ?" At least one thing : Unlike the "Dan Kaminsky" flavour of cache poisoning attach, there is no way that attacker could trigger the verification of the parent, nor can the attacker know when the parent actually does the verificiation. The draw back of negative trust anchors seems that it must be implemented on the validating name server side --> not "centrally" like the DS record. (and what if, to overcome the "not centrally managed" observation, there is a demand for some "blacklist of domains that should not be validated" ?) Otherwise, "active parenting" and "negative trust anchors" are two approaches to cope with the same problem. And they are not mutually exclusive. Kind regards, Marc -----Original Message----- From: Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com] Sent: 13 April 2012 04:21 PM To: Mark Andrews Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood, Jason Subject: RE: [DNSOP] on "Negative Trust Anchors" Mark Andrews, Thursday, April 12, 2012 11:43 PM: > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Thursday, April 12, 2012 11:43 PM > To: Stephan Lagerholm > Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood, > Jason > Subject: Re: [DNSOP] on "Negative Trust Anchors" > > In message > , "Steph > an Lagerholm" writes: > > Mark Andrews Thursday, April 12, 2012 6:10 PM: > > > > > > On 12.04.2012, at 14:21, Marc Lampo wrote: > > > > > > It holds an alternative possibility to overcome the problem > > > > > > - for operators of validating name servers - of failing > > > > > > domains because of DNSSEC. > > > > > > > > > > > > The alternative is to have a parent regularly (no frequency > > > > > > defined) check the coherence of DS information they have > > > > > > against DNSKEY information it finds published. > > > > > > If the parent detects "security lameness" (term used in > > > > > > RFC4641bis) its possible reaction could be to remove the DS > > > information. > > > > > > > > =3D> From my experience, "active parenting" is not a good > practice. > > > > Specifically in this case, you are assuming that the parent knows > > the > > > > algorithms used for the DS record. He would have to in order to > > > > validate. That might not always hold true. Additionally, the > > > > record > > > is > > > > not 'yours', it is just parked in your zone by the child. For the > > > > parent to Tamper with either the NS or DS is IMHO not a good > > > practice. > > >=20 > > > There is a difference between "Tamper" and "Hey, you stuffed up. > > > You need to fix the delegation or we will remove it as it is > causing > > >operational problems" and yes there *are* RFCs that permit this to > > >happen. > > > > Being Insecure is not necessary better than being Bogus. "Hey you got > > hacked, so we will remove the DS so that people can get to that bogus > > site" > > I said remove the delegation. Get their attention as doing anything > else doesn't work. I have yet to understand how your parent to child DNS probes works. Specifically, if you can explain to me how you are distinguishing between: A) The DS and the DNSKEY does not match because there is an operational error at the child And B) The DS and the DNSKEY does not match because somebody is doing a "man in the middle" on my probes. Going back to the original claim that " alternative is to have a parent regularly check the coherence of DS information and that a possible reaction could be to remove the DS" I'm not supportive of such "active parenting" idea. I find the idea of negative trust anchors useful for recursive resolvers given that the operator of such recursive resolver uses a secure out of band technology to make sure that there is an operational mistake. From dougb@dougbarton.us Fri Apr 13 09:18:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2B721F87FF for ; Fri, 13 Apr 2012 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-2.316, BAYES_00=-2.599, FRT_SOMA=1.664, FRT_SOMA2=2.199, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmMuTsexqjXT for ; Fri, 13 Apr 2012 09:18:27 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id B626E21F861A for ; Fri, 13 Apr 2012 09:18:26 -0700 (PDT) Received: (qmail 15688 invoked by uid 399); 13 Apr 2012 16:18:24 -0000 Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 13 Apr 2012 16:18:24 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F8851CF.2020807@dougbarton.us> Date: Fri, 13 Apr 2012 09:18:23 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> In-Reply-To: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:18:28 -0000 Responding to a message at random ... I skimmed the draft, and with respect to the authors this is a terrible idea. DNSSEC is pointless if it's not used as designed. Providing an easy way to bypass validation makes many things worse instead of better ... not the least of which is that if an attacker has actually compromised the authoritative name servers for the domain you've just made their job 100% easier (and thereby removed all the protection that DNSSEC is supposed to provide). Furthermore, the mechanism is not necessary, since if you somehow had knowledge that it was safe to use the data even if it doesn't validate you can temporarily set up a forward zone that points to a non-validating resolver. The mentality that we need to provide crutches and bandages to paper over the mistakes by DNS admins is exactly what has perpetuated the long history of bad habits and "zomg I can't believe that something so badly configured ever actually worked" that is one of the reasons DNSSEC rollouts are failing in the first place. Providing more crutches and bandages is not the answer. Doug -- If you're never wrong, you're not trying hard enough From fanf2@hermes.cam.ac.uk Fri Apr 13 10:28:36 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1E21F8670 for ; Fri, 13 Apr 2012 10:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffwgs8hfS453 for ; Fri, 13 Apr 2012 10:28:35 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 67A4B21F8631 for ; Fri, 13 Apr 2012 10:28:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56967) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SIkIT-00046D-QR (Exim 4.72) (return-path ); Fri, 13 Apr 2012 18:28:33 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SIkIT-0006wH-58 (Exim 4.67) (return-path ); Fri, 13 Apr 2012 18:28:33 +0100 Date: Fri, 13 Apr 2012 18:28:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Doug Barton In-Reply-To: <4F8851CF.2020807@dougbarton.us> Message-ID: References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "" , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:28:36 -0000 Doug Barton wrote: > > Furthermore, the mechanism is not necessary, since if you somehow had > knowledge that it was safe to use the data even if it doesn't validate > you can temporarily set up a forward zone that points to a > non-validating resolver. AFAIK that doesn't work in BIND. Tony. -- f.anthony.n.finch http://dotat.at/ Northwest Forties, Cromarty, Forth: Northerly or northeasterly 5 or 6, occasionally 7 at first. Moderate or rough. Showers, becoming wintry. Good, occasionally moderate. From paul@redbarn.org Fri Apr 13 10:43:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ECD21F8694 for ; Fri, 13 Apr 2012 10:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjh1x0aHLXY5 for ; Fri, 13 Apr 2012 10:43:46 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0574921F865D for ; Fri, 13 Apr 2012 10:43:46 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DB750A1037; Fri, 13 Apr 2012 17:43:44 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [IPv6:2001:4f8:3:30:9070:1d0d:eff0:900f] (unknown [IPv6:2001:4f8:3:30:9070:1d0d:eff0:900f]) by nsa.vix.com (Postfix) with ESMTP id B1875A1031; Fri, 13 Apr 2012 17:43:44 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F8865CE.80203@redbarn.org> Date: Fri, 13 Apr 2012 17:43:42 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tony Finch References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "" , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:43:46 -0000 the information economics of this draft are all wrong. with all possible respect for the comcast team who is actually validating signatures for 18 million subscribers and is therefore way ahead of the rest of the industry and is encountering the problems of pioneers... this is not supposed to be comcast's problem. if someone that comcast's customers want to reach, blows their dnssec out by using the wrong keys or using expired signatures or whatever, then the problem ownership should rest with whosoever blows their dnssec -- not with comcast. it's only because comcast is first that comcast has to watch out for the deleterious effects of OPM (other people's mistakes) on comcast's own customers. comcast can't afford the help desk call volume that would come from another wrong-key failure at the social security administration's domain. but that doesn't make it comcast's problem. it would remain the social security administration's problem. we need to move quickly to the point where lots of large eyeball-facing network operators are validating, such that any failure to properly maintain signatures and keys and DS records, is felt most severely by whomever's domain is thus rendered unreachable. if everyone interested in working on this draft would take the time to turn on validation, then we could avoid inverting the information economics here. people who can't manage their keys and signatures properly (and i include my own vanity zones in that, since i'm not yet converted to the bind 9.9 way of doing things) should either expect trouble or uplevel their game or stay out of the game. i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. paul From each@isc.org Fri Apr 13 13:09:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F5A21F859E for ; Fri, 13 Apr 2012 13:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBSQx7RpsEjk for ; Fri, 13 Apr 2012 13:09:22 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 334CF21F859A for ; Fri, 13 Apr 2012 13:09:22 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 75B51C941E; Fri, 13 Apr 2012 20:09:07 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 5200F216C33; Fri, 13 Apr 2012 20:09:07 +0000 (UTC) Date: Fri, 13 Apr 2012 20:09:07 +0000 From: Evan Hunt To: Paul Vixie Message-ID: <20120413200907.GA86915@isc.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8865CE.80203@redbarn.org> User-Agent: Mutt/1.4.2.3i Cc: Tony Finch , "" , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:09:23 -0000 On Fri, Apr 13, 2012 at 05:43:42PM +0000, Paul Vixie wrote: > i'm opposed to negative trust anchors, both for their security > implications if there were secure applications in existence, and for > their information economics implications. +1 -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From paf@frobbit.se Fri Apr 13 13:24:43 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD0211E80AF for ; Fri, 13 Apr 2012 13:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xslwH+uMLYvT for ; Fri, 13 Apr 2012 13:24:42 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4111E80A5 for ; Fri, 13 Apr 2012 13:24:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 6544A138EB18B; Fri, 13 Apr 2012 22:24:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byLkjjo9D7Eu; Fri, 13 Apr 2012 22:24:37 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 3C2F7138EB184; Fri, 13 Apr 2012 22:24:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120413200907.GA86915@isc.org> Date: Fri, 13 Apr 2012 22:24:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1257) Cc: Tony Finch , "Livingood, Jason" , "" , Paul Vixie Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:24:43 -0000 On 13 apr 2012, at 22:09, Evan Hunt wrote: > On Fri, Apr 13, 2012 at 05:43:42PM +0000, Paul Vixie wrote: >> i'm opposed to negative trust anchors, both for their security >> implications if there were secure applications in existence, and for >> their information economics implications. > > +1 +1 Patrik From nweaver@icsi.berkeley.edu Fri Apr 13 13:43:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9548E21F86D3 for ; Fri, 13 Apr 2012 13:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwi2RQkjkcKL for ; Fri, 13 Apr 2012 13:43:46 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 07D6321F8539 for ; Fri, 13 Apr 2012 13:43:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id D77AE2C4029; Fri, 13 Apr 2012 13:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WY3bFkk6XM7M; Fri, 13 Apr 2012 13:43:45 -0700 (PDT) Received: from [10.0.1.7] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 64BCC2C401E; Fri, 13 Apr 2012 13:43:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Fri, 13 Apr 2012 13:44:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: Nicholas Weaver , Tony Finch , "" , Paul Vixie , Evan Hunt , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:43:46 -0000 On Apr 13, 2012, at 1:24 PM, Patrik F=E4ltstr=F6m wrote: >=20 > On 13 apr 2012, at 22:09, Evan Hunt wrote: >=20 >> On Fri, Apr 13, 2012 at 05:43:42PM +0000, Paul Vixie wrote: >>> i'm opposed to negative trust anchors, both for their security >>> implications if there were secure applications in existence, and for >>> their information economics implications. >>=20 >> +1 >=20 > +1 -1 Simply put, I'm not a huge believer of recursive resolver (rather than = client) validation. But if you are going to do it... There are a few cases where it is valuable [1], but for every 'validate = is the right answer', there are hundreds of cases, like the NASA case, = where the authority is just screwing up. And in those cases, the = economics are that DNSSEC is creating a DOS, and it is the one who's = validating that's at least partially responsible because it is both = validating and deciding that its clients should suffer. This is especially true for ISPs. If you want any other ISP to validate = DNSSEC, they need a mechanism like this so they don't suffer through the = problems that Comcast has already experienced. Because practice has shown that it is the recursive resolver, not the = authority, that gets blamed. Lurk on the Google Public DNS mailing = list, and you realize that even without DNSSEC, the resolver operator = faces the blame for brokenness. Thus, at least for DNSSEC, resolver = operators need to be able to override validation easily and efficiently. [1] And these cases require 'listen until you can get something that = validates': Just accept then validate gives the wrong answer in these = cases. From paf@frobbit.se Fri Apr 13 14:00:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8791321F8748 for ; Fri, 13 Apr 2012 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM2GFUsDZSYN for ; Fri, 13 Apr 2012 14:00:15 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id C125B21F86E1 for ; Fri, 13 Apr 2012 14:00:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id A6282138EB9E3; Fri, 13 Apr 2012 23:00:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNEH3cNGi+r6; Fri, 13 Apr 2012 23:00:13 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 6B9ED138EB9D9; Fri, 13 Apr 2012 23:00:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Fri, 13 Apr 2012 23:00:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1257) Cc: Tony Finch , Paul Vixie , "" , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:00:15 -0000 On 13 apr 2012, at 22:24, Patrik F=E4ltstr=F6m wrote: > +1 In a private chat I am asked to explain my "+1". Let me explain why. Today, before negative trust anchors, the responsibility for whether a = the resolution that is basis for a connection establishment is with the = zone owner. If the signature fails, it fails, resolution fails, and the = connection can not be established. Now, if we have negative trust anchors that the validator is = controlling, then I interpret it as if this choice of ability to resolve = a name moves from the zone owner to the validator (or as in the case of = X.509 certs to the client). What I am against is this *CHANGE* in who is responsible. Further, I think for .COM (and in the US) we are extremely unlucky that = more or less only one large validator started validating, and then one = zone owner made mistakes with their DNSSEC data. This made the press and = community blame the one that did right, the validator, when in fact the = one that validated and rejected some RRs did the right thing. In Sweden, where we also had such "incidents" we did not "give up" that = easy. But, we succeeded because of a I think two things: - We managed to have more than one major ISP/Resolver to start = validating on the same date, so as far as I know, no incident, = regardless of how bad it was, was ever one that blamed the validator. - We managed to educate press and whoever that could help put a wet = blanket over all rumors that the validator was the one to blame when = validating did not work. Of course this was MUCH easier in Sweden that is a much smaller country = than "the group of entities that uses .COM". But, all of this thinking leads me to think about DNSSEC validation = "risks" are very similar to the risk with deploying IPv6? We have an = IPv6 day, but why not a DNSSEC day? One day where *many* players at the = same time turn on DNSSEC validation? If we did, then maybe it would be easier for parties to turn on = validation, because it could be easier for them to explain that it is = not whoever that is validating that is making mistakes at failures, but = instead the zone owner? And to go back to the "+1", I say strongly "+1" because alternatives = (like what I just described) to changing who is responsible for making a = decision of whether validation should work or not are not explored = enough. Definitely not. I am not giving up yet, although after my work in a role being = responsible for many products at an ISP 1996-2000 I definitely = understand what the cost is with negative press and increased number of = calls to customer service. Patrik From paf@frobbit.se Fri Apr 13 14:18:59 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C130721F8646 for ; Fri, 13 Apr 2012 14:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dznHwvBZ+vS for ; Fri, 13 Apr 2012 14:18:59 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 261D721F8615 for ; Fri, 13 Apr 2012 14:18:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 80D09138EC003; Fri, 13 Apr 2012 23:18:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02BvmSxfN4Je; Fri, 13 Apr 2012 23:18:58 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 514B5138EBFFC; Fri, 13 Apr 2012 23:18:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> Date: Fri, 13 Apr 2012 23:18:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1257) Cc: Evan Hunt , Tony Finch , "" , "Livingood, Jason" , Paul Vixie Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:18:59 -0000 On 13 apr 2012, at 22:44, Nicholas Weaver wrote: > Because practice has shown that it is the recursive resolver, not the = authority, that gets blamed. As you saw in my mail, I completely disagree from my own personal = experience. If I look at the number of failures, the number of cases where the = validator is blamed is exactly one -- Comcast in the NASA case. Compared = to the about 50 cases or so when the zone owner/signer is blamed. Yes, = we have been running DNSSEC validation in Sweden a bit longer than in = the USA. Can you please comment on that mail that uses a few more characters than = '+1' please? Patrik From drc@virtualized.org Fri Apr 13 14:19:43 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF4121F8669 for ; Fri, 13 Apr 2012 14:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B8vdLolmEoq for ; Fri, 13 Apr 2012 14:19:43 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 12C7E21F865D for ; Fri, 13 Apr 2012 14:19:43 -0700 (PDT) Received: from [192.168.2.168] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 92AB61705A; Fri, 13 Apr 2012 21:19:32 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: David Conrad In-Reply-To: <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> Date: Fri, 13 Apr 2012 14:19:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:19:43 -0000 Patrik, On Apr 13, 2012, at 2:00 PM, Patrik F=E4ltstr=F6m wrote: > What I am against is this *CHANGE* in who is responsible. I don't see NTAs changing who is responsible. I see it changing who = absorbs the costs. Without NTAs, it is primarily the validator operator = and those costs can't be passed on to the responsible folks. With NTAs, = the validator operator can avoid those costs. The authority that has = screwed up has increased risks that the names they are serving can be = poisoned which they presumably care about if they have bothered to sign = (even if they screwed it up). I have some faith that if an authority = screws up, numerous people will make them aware of that screwup. > In Sweden, where we also had such "incidents" we did not "give up" = that easy. As you note, there is a scale issue here. To be fair, my understanding = is that the number of customers that would be affected by validation = failures detected by Comcast alone is about twice the entire population = of Sweden. More pragmatically, while I understand the theory behind rejecting NTAs, = I have to admit it feels a bit like the IETF rejecting NATs and/or DNS = redirection. I would be surprised if folks who implement NTAs will stop = using them if they are not accepted by the IETF. > But, all of this thinking leads me to think about DNSSEC validation = "risks" are very similar to the risk with deploying IPv6? We have an = IPv6 day, but why not a DNSSEC day? One day where *many* players at the = same time turn on DNSSEC validation? Definitely a good idea. Regards, -drc From paf@frobbit.se Fri Apr 13 14:22:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454C811E811C for ; Fri, 13 Apr 2012 14:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kactNNXi88US for ; Fri, 13 Apr 2012 14:22:25 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 96BAA11E8119 for ; Fri, 13 Apr 2012 14:22:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 00122138EC187; Fri, 13 Apr 2012 23:22:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taq+nh54t4ey; Fri, 13 Apr 2012 23:22:24 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7541F138EC17B; Fri, 13 Apr 2012 23:22:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> Date: Fri, 13 Apr 2012 23:22:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <324F77C7-6C75-46F5-BC22-B8F1D2ACC351@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:22:26 -0000 On 13 apr 2012, at 23:19, David Conrad wrote: > More pragmatically, while I understand the theory behind rejecting = NTAs, I have to admit it feels a bit like the IETF rejecting NATs and/or = DNS redirection. I would be surprised if folks who implement NTAs will = stop using them if they are not accepted by the IETF. Of course. But if a validator suddenly see that something is costing them too much, = they "just" turn off validation. Done! Why do IETF have to say anything at all related to the architecture if = this is down to a business cost? ;-) Patrik From paf@frobbit.se Fri Apr 13 14:24:44 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC8921F87F1 for ; Fri, 13 Apr 2012 14:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWUjlfKHHLc0 for ; Fri, 13 Apr 2012 14:24:43 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 608F421F87EF for ; Fri, 13 Apr 2012 14:24:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id BB4A1138EC2AB; Fri, 13 Apr 2012 23:24:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPPvr4lU55F3; Fri, 13 Apr 2012 23:24:42 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 64AA7138EC2A4; Fri, 13 Apr 2012 23:24:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <324F77C7-6C75-46F5-BC22-B8F1D2ACC351@frobbit.se> Date: Fri, 13 Apr 2012 23:24:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C9C7C82-12F9-43E6-93D0-1CC84AB64C62@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <324F77C7-6C75-46F5-BC22-B8F1D2ACC351@frobbit.se> To: David Conrad X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:24:44 -0000 On 13 apr 2012, at 23:22, Patrik F=E4ltstr=F6m wrote: > On 13 apr 2012, at 23:19, David Conrad wrote: >=20 >> More pragmatically, while I understand the theory behind rejecting = NTAs, I have to admit it feels a bit like the IETF rejecting NATs and/or = DNS redirection. I would be surprised if folks who implement NTAs will = stop using them if they are not accepted by the IETF. >=20 > Of course. >=20 > But if a validator suddenly see that something is costing them too = much, they "just" turn off validation. Done! BTW, have a look at this that Torbj=F6rn Ekl=F6w that normally works = with IPv6 have done: http://kommunermeddnssec.se/maps.php Even though the situation is as it is, have the major ISPs turned off = validation? Nope. Patrik From drc@virtualized.org Fri Apr 13 14:34:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FF511E812E for ; Fri, 13 Apr 2012 14:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEiSQlTeSgKg for ; Fri, 13 Apr 2012 14:34:22 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 88E5511E8123 for ; Fri, 13 Apr 2012 14:34:22 -0700 (PDT) Received: from [192.168.2.168] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 279921705A; Fri, 13 Apr 2012 21:34:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: David Conrad In-Reply-To: <324F77C7-6C75-46F5-BC22-B8F1D2ACC351@frobbit.se> Date: Fri, 13 Apr 2012 14:34:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <329A2D83-FA80-495B-9EC2-FFFD8305B2AB@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <324F77C7-6C75-46F5-BC22-B8F1D2ACC351@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:34:23 -0000 Patrik, On Apr 13, 2012, at 2:22 PM, Patrik F=E4ltstr=F6m wrote: > But if a validator suddenly see that something is costing them too = much, they "just" turn off validation. Done! Yes, however I don't think this is an outcome we want to encourage. At = this point in the deployment of DNSSEC, I'd think we'd want to = facilitate validator operators dealing with the mistakes others make = instead of forcing them eat the costs of those mistakes. > Why do IETF have to say anything at all related to the architecture if = this is down to a business cost? An interesting philosophical question relating to the role of voluntary = SDOs, but not one I'm interested in pursing right now. :-) > http://kommunermeddnssec.se/maps.php Very interesting (and sad given the amount of red in relation to the = amount of green). Any idea how many validation failures ISPs are seeing = as a result? Regards, -drc From paf@frobbit.se Fri Apr 13 14:39:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BFB11E813B for ; Fri, 13 Apr 2012 14:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSHO69BzFGNA for ; Fri, 13 Apr 2012 14:39:44 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id DCDEB11E8139 for ; Fri, 13 Apr 2012 14:39:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D7211138EC77D; Fri, 13 Apr 2012 23:39:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-+2z48MG7K3; Fri, 13 Apr 2012 23:39:42 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 34613138EC770; Fri, 13 Apr 2012 23:39:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <329A2D83-FA80-495B-9EC2-FFFD8305B2AB@virtualized.org> Date: Fri, 13 Apr 2012 23:39:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <348DD93D-0E66-494C-BDFD-7F802D415F32@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <324F77C7-6C75-46F5-BC22-B8F1D2ACC351@frobbit.se> <329A2D83-FA80-495B-9EC2-FFFD8305B2AB@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:39:45 -0000 On 13 apr 2012, at 23:34, David Conrad wrote: >> http://kommunermeddnssec.se/maps.php >=20 > Very interesting (and sad given the amount of red in relation to the = amount of green). Any idea how many validation failures ISPs are seeing = as a result? Of course the red is more failures than validation failures, but it is = definitely a large portion of it. For the cities concerned, it is of course 100% failures for the red ones = for all(!) major ISPs in Sweden. Including mobile broad band. So people = can not use their services. That is just how it is. And only when the city detects this problem themselves, they fix it. Do not forget that one thing I think I am seeing in Sweden is that there = is a relationship between "how important is your service" and "be = correct in DNSSEC". I.e. no "important" zones are dead. Because if they = where wrong in DNSSEC, they would be in the newspaper the day after. So = important zones do not not validate, if you understand what I mean. When did you last time use a web browser to look at your own web site? = ;-) Patrik From nweaver@ICSI.Berkeley.EDU Fri Apr 13 14:45:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5F711E813E for ; Fri, 13 Apr 2012 14:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKigzVgnpG9c for ; Fri, 13 Apr 2012 14:45:02 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id EC79421F86F2 for ; Fri, 13 Apr 2012 14:43:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DA4222C401E; Fri, 13 Apr 2012 14:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id F5RfmAH78Ghb; Fri, 13 Apr 2012 14:43:34 -0700 (PDT) Received: from [10.0.1.7] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 13B342C401A; Fri, 13 Apr 2012 14:43:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Fri, 13 Apr 2012 14:43:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: Nicholas Weaver , Tony Finch , "" , Paul Vixie , Evan Hunt , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:45:03 -0000 On Apr 13, 2012, at 2:18 PM, Patrik F=E4ltstr=F6m wrote: >=20 > On 13 apr 2012, at 22:44, Nicholas Weaver wrote: >=20 >> Because practice has shown that it is the recursive resolver, not the = authority, that gets blamed. >=20 > As you saw in my mail, I completely disagree from my own personal = experience. >=20 > If I look at the number of failures, the number of cases where the = validator is blamed is exactly one -- Comcast in the NASA case. Compared = to the about 50 cases or so when the zone owner/signer is blamed. Yes, = we have been running DNSSEC validation in Sweden a bit longer than in = the USA. >=20 > Can you please comment on that mail that uses a few more characters = than '+1' please? https://groups.google.com/group/public-dns-discuss A good indication how NORMAL DNSSEC failures get blamed to the recursive = resolver operator. Likewise, comcast being blamed for blocking "digifit.com" = http://forums.comcast.com/t5/Security-and-Anti-Virus/Comcast-blocking-site= /td-p/1140537 Or being blamed for blocking bitcoininca.com, again due to DNSSEC = validation failures: http://twitter.com/#!/comcasttom http://dnsviz.net/d/www.bitcoinica.com/dnssec/ Currently, Comcast is not getting stress for this because they simply = turned off validation, using basically this technique, for = bitcoininca.com [1], because it STILL isn't right. [1] Validation of the invalidation for www.bitcoinica.com: DNS OARC DNSSEC-open resolver (running BIND), first with +dnssec, then = with +cd, then to comcast's validating resolvers and validating that the = comcast resolver validates nweaver% dig +dnssec www.bitcoinica.com @149.20.64.20 ; <<>> DiG 9.7.3-P3 <<>> +dnssec www.bitcoinica.com @149.20.64.20 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50201 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.bitcoinica.com. IN A ;; Query time: 2490 msec ;; SERVER: 149.20.64.20#53(149.20.64.20) ;; WHEN: Fri Apr 13 14:36:10 2012 ;; MSG SIZE rcvd: 47 nweaver% dig +dnssec +cd www.bitcoinica.com @149.20.64.20 ; <<>> DiG 9.7.3-P3 <<>> +dnssec +cd www.bitcoinica.com @149.20.64.20 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25328 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.bitcoinica.com. IN A ;; ANSWER SECTION: www.bitcoinica.com. 39 IN CNAME bitcoinica.com. bitcoinica.com. 39 IN A 50.56.4.62 ;; AUTHORITY SECTION: bitcoinica.com. 172539 IN NS ns-556.awsdns-05.net. bitcoinica.com. 172539 IN NS ns-1893.awsdns-44.co.uk. bitcoinica.com. 172539 IN NS ns-395.awsdns-49.com. bitcoinica.com. 172539 IN NS ns-1199.awsdns-21.org. ;; Query time: 903 msec ;; SERVER: 149.20.64.20#53(149.20.64.20) ;; WHEN: Fri Apr 13 14:40:40 2012 ;; MSG SIZE rcvd: 214 nweaver% dig +dnssec www.bitcoinica.com @75.75.75.75 ; <<>> DiG 9.7.3-P3 <<>> +dnssec www.bitcoinica.com @75.75.75.75 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10370 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4000 ;; QUESTION SECTION: ;www.bitcoinica.com. IN A ;; ANSWER SECTION: www.bitcoinica.com. 300 IN CNAME bitcoinica.com. bitcoinica.com. 300 IN A 50.56.4.62 ;; Query time: 123 msec ;; SERVER: 75.75.75.75#53(75.75.75.75) ;; WHEN: Fri Apr 13 14:37:27 2012 ;; MSG SIZE rcvd: 77 nweaver% dig +dnssec www.dnssec-failed.org @75.75.75.75 ; <<>> DiG 9.7.3-P3 <<>> +dnssec www.dnssec-failed.org @75.75.75.75 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29502 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4000 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 41 msec ;; SERVER: 75.75.75.75#53(75.75.75.75) ;; WHEN: Fri Apr 13 14:43:15 2012 ;; MSG SIZE rcvd: 50 From paf@frobbit.se Fri Apr 13 15:02:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC53011E80C4 for ; Fri, 13 Apr 2012 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwjDJd0N9rby for ; Fri, 13 Apr 2012 15:02:33 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id B29D521F8565 for ; Fri, 13 Apr 2012 15:02:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id AE15B138ED02C; Sat, 14 Apr 2012 00:02:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qvzyRGQaJwA; Sat, 14 Apr 2012 00:02:26 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 6B990138ED024; Sat, 14 Apr 2012 00:02:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> Date: Sat, 14 Apr 2012 00:02:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> To: Nicholas Weaver X-Mailer: Apple Mail (2.1257) Cc: Evan Hunt , Tony Finch , "" , "Livingood, Jason" , Paul Vixie Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:02:34 -0000 On 13 apr 2012, at 23:43, Nicholas Weaver wrote: > Likewise, comcast being blamed for... Because (1) they seem to be the only large resolver operator that do = validation(?) and (2) people like us on this list try to work out end = runs around the standards we created instead of helping Comcast. Yes, I blame myself personally there as well for not doing enough. I was = working hard when we deployed DNSSEC in Sweden to counter attack all = such arguments in the press that you refer to, and I thought, naively, = that as we managed to go through those issues, other people would as = well. But as I said in an earlier message, maybe we where lucky in Sweden that = all major ISPs did deploy validation at the same time. In the US it = seems to be Comcast only(?). What would have happened if AT&T and Comcast and Verizon started = validation basically the same week? Now of course we can not turn back clock, but I think still "we give up = too early" if we go down this path. That is my reason for a +1. Now I will go to sleep. It is Friday, and I feel I am hijacking this = thread. Violating principles of IETF lists I like myself. More people should say what they want to say. Patrik From jaap@NLnetLabs.nl Fri Apr 13 15:30:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE4F21F87BC for ; Fri, 13 Apr 2012 15:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPgdT7UtwY7o for ; Fri, 13 Apr 2012 15:30:32 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by ietfa.amsl.com (Postfix) with ESMTP id 6B02221F87B2 for ; Fri, 13 Apr 2012 15:30:32 -0700 (PDT) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id q3DMUPx9056051; Sat, 14 Apr 2012 00:30:28 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) X-DKIM: OpenDKIM Filter v2.5.1 bartok.nlnetlabs.nl q3DMUPx9056051 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=sleutel; t=1334356228; bh=RRlgh0l7wgcVoGxY4g2+cjr3DY/Oyn1jqZ+boI1PVqU=; h=To:cc:Subject:In-reply-to:References:Date:From; b=AfA69FgUMU6NM3INCP97ZlERe69CEfOWRdqlLBtgQ7IjU/h8PT5am6o+mqd6hdBPR JftkZ0qvmJO4ArGgMdbCfxAqgVPmaEFwcDxPSk9SM6zaGMvQhULEurjytIFV7Lim+K pTyzoPU7Zrle9azc13LQLEOoX8TflSEbgzQTty48= Message-Id: <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> To: David Conrad In-reply-to: <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> Comments: In-reply-to David Conrad message dated "Fri, 13 Apr 2012 14:19:31 -0700." Date: Sat, 14 Apr 2012 00:30:25 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bartok.nlnetlabs.nl [127.0.0.1]); Sat, 14 Apr 2012 00:30:28 +0200 (CEST) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:30:33 -0000 <...> More pragmatically, while I understand the theory behind rejecting NTAs, I have to admit it feels a bit like the IETF rejecting NATs and/or DNS redirection. I would be surprised if folks who implement NTAs will stop using them if they are not accepted by the IETF. Doing the validation on my machine makes it easy for me to realize who to blame when things break but I realize others don't have that insight or run validators, so I see the pain for the validating ISP. However, it is still not a reason for the IETF to standardize this. (paf) > But, all of this thinking leads me to think about DNSSEC validation > "risks" are very similar to the risk with deploying IPv6? > We have an IPv6 day, but why not a DNSSEC day? One day where > *many* players at the same time turn on DNSSEC validation? (drc) Definitely a good idea. It is seems a nice idea but a problem is that a single day is probably not enough. IPv6 problems are (nearly) instantaneous but with DNSSEC problems start to arise when things expire. jaap From mehmet@icann.org Fri Apr 13 16:31:25 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9B711E8111 for ; Fri, 13 Apr 2012 16:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2buRPH937e3W for ; Fri, 13 Apr 2012 16:31:24 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 41D3211E8103 for ; Fri, 13 Apr 2012 16:31:24 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Fri, 13 Apr 2012 16:31:23 -0700 From: Mehmet Akcin To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 13 Apr 2012 16:31:23 -0700 Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0ZzYnlLQKbX/MtShidIsXO+DRoZg== Message-ID: <2EC03EEF-2893-44AA-8909-539B5DBA7C9F@icann.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <324F77C7-6C75-46F5-BC22-B8F1D2ACC351@frobbit.se> <329A2D83-FA80-495B-9EC2-FFFD8305B2AB@virtualized.org> <348DD93D-0E66-494C-BDFD-7F802D415F32@frobbit.se> In-Reply-To: <348DD93D-0E66-494C-BDFD-7F802D415F32@frobbit.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , David Conrad Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:31:25 -0000 On Apr 13, 2012, at 2:39 PM, Patrik F=E4ltstr=F6m wrote: >>> http://kommunermeddnssec.se/maps.php This is one of the coolest thing i have clicked in long time.. thanks for s= haring mehmet= From drc@virtualized.org Fri Apr 13 16:38:13 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF0721F86EE for ; Fri, 13 Apr 2012 16:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3duV8W2BfmRU for ; Fri, 13 Apr 2012 16:38:12 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6251721F86EC for ; Fri, 13 Apr 2012 16:38:12 -0700 (PDT) Received: from [192.168.2.168] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id E262B1705A; Fri, 13 Apr 2012 23:38:11 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> Date: Fri, 13 Apr 2012 16:38:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> To: Jaap Akkerhuis X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:38:13 -0000 On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote: >> More pragmatically, while I understand the theory behind rejecting = NTAs, >> I have to admit it feels a bit like the IETF rejecting NATs and/or = DNS >> redirection. I would be surprised if folks who implement NTAs will = stop >> using them if they are not accepted by the IETF. >>=20 > it is still not a reason for the IETF to standardize this. With the implication that multiple vendors go and implement the same = thing in incompatible ways. I always get a headache when this sort of = thing happens as the increased operational costs of non-interoperable = implementations usually seems more damaging to me than violations of = architectural purity. Different perspectives I guess. > It is seems a nice idea but a problem is that a single day is > probably not enough. IPv6 problems are (nearly) instantaneous but > with DNSSEC problems start to arise when things expire. Crawl before running a marathon. If we get to a point where people = actually deploy signing and/or validation systems, I'd call it success. Regards, -drc =20 From marka@isc.org Fri Apr 13 16:50:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9464011E8138 for ; Fri, 13 Apr 2012 16:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4UJ+2cdxqpg for ; Fri, 13 Apr 2012 16:50:19 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5012211E8111 for ; Fri, 13 Apr 2012 16:50:19 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 029BCC9427; Fri, 13 Apr 2012 23:50:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5cea:274a:77ce:32c1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 75852216C31; Fri, 13 Apr 2012 23:50:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 37DE31FB2097; Sat, 14 Apr 2012 09:50:00 +1000 (EST) To: Jaap Akkerhuis From: Mark Andrews References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> In-reply-to: Your message of "Sat, 14 Apr 2012 00:30:25 +0200." <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> Date: Sat, 14 Apr 2012 09:50:00 +1000 Message-Id: <20120413235000.37DE31FB2097@drugs.dv.isc.org> Cc: "dnsop@ietf.org WG" , David Conrad Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:50:20 -0000 In message <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites: > <...> > More pragmatically, while I understand the theory behind rejecting NTAs > , > I have to admit it feels a bit like the IETF rejecting NATs and/or DNS > redirection. I would be surprised if folks who implement NTAs will stop > using them if they are not accepted by the IETF. > > Doing the validation on my machine makes it easy for me to realize > who to blame when things break but I realize others don't have that > insight or run validators, so I see the pain for the validating > ISP. However, it is still not a reason for the IETF to standardize > this. > > (paf) > > But, all of this thinking leads me to think about DNSSEC validation > > "risks" are very similar to the risk with deploying IPv6? > > We have an IPv6 day, but why not a DNSSEC day? One day where > > *many* players at the same time turn on DNSSEC validation? > > (drc) > Definitely a good idea. > > It is seems a nice idea but a problem is that a single day is > probably not enough. IPv6 problems are (nearly) instantaneous but > with DNSSEC problems start to arise when things expire. > > jaap > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop What one needs to do is validate answers from one's own zones internally as well as answers from the rest of the world. That way you detect when you have stuffed up as it effects you as well as everyone else. I've been running with a config like this for several months now. The recursive clients see "ad". The non-recursive clients see the raw zone. Mark % dig drugs.dv.isc.org ; <<>> DiG 9.9.0rc2 <<>> drugs.dv.isc.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36493 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;drugs.dv.isc.org. IN A ;; ANSWER SECTION: drugs.dv.isc.org. 2371 IN A 192.168.191.240 drugs.dv.isc.org. 2371 IN A 192.168.191.223 ;; AUTHORITY SECTION: dv.isc.org. 50822 IN NS bsdi1.dv.isc.org. dv.isc.org. 50822 IN NS drugs.dv.isc.org. ;; ADDITIONAL SECTION: drugs.dv.isc.org. 60 IN AAAA 2001:470:1f00:820:ea06:88ff:fef3:4f9c drugs.dv.isc.org. 60 IN AAAA 2001:470:1f00:820:6233:4bff:fe01:7585 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Apr 14 09:43:34 2012 ;; MSG SIZE rcvd: 167 % dig drugs.dv.isc.org +norec ; <<>> DiG 9.9.0rc2 <<>> drugs.dv.isc.org +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48679 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;drugs.dv.isc.org. IN A ;; ANSWER SECTION: drugs.dv.isc.org. 3600 IN A 192.168.191.240 drugs.dv.isc.org. 3600 IN A 192.168.191.223 ;; AUTHORITY SECTION: dv.isc.org. 86400 IN NS bsdi1.dv.isc.org. dv.isc.org. 86400 IN NS drugs.dv.isc.org. ;; ADDITIONAL SECTION: bsdi1.dv.isc.org. 86400 IN A 192.168.191.233 drugs.dv.isc.org. 3600 IN AAAA 2001:470:1f00:820:6233:4bff:fe01:7585 drugs.dv.isc.org. 3600 IN AAAA 2001:470:1f00:820:ea06:88ff:fef3:4f9c ;; Query time: 8 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Apr 14 09:43:41 2012 ;; MSG SIZE rcvd: 183 % managed-keys { . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0 O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37N ZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7 ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0="; }; view "secure" { match-clients { localnets; }; match-recursive-only yes; zone "." IN { type hint; file "named.ca"; }; zone dv.isc.org { type static-stub; server-addresses { 127.0.0.1; }; }; zone "0.0.0.0.e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa" { type static-stub; server-addresses { 127.0.0.1; }; }; }; view "internal" { match-clients { localnets; }; recursion no; zone "." IN { type hint; file "named.ca"; }; zone dv.isc.org { type slave; file "slave/dv.isc.org"; masters { bsdi.dv.isc.org; }; }; zone "0.0.0.0.e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa" { type slave; file "slave/0.0.0.0.e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa"; masters { bsdi.dv.isc.org; }; }; }; -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dougb@dougbarton.us Fri Apr 13 18:51:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AADB21F8620 for ; Fri, 13 Apr 2012 18:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.875 X-Spam-Level: X-Spam-Status: No, score=-2.875 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX4fAKKnfaYC for ; Fri, 13 Apr 2012 18:51:30 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 804EE21F8618 for ; Fri, 13 Apr 2012 18:51:22 -0700 (PDT) Received: (qmail 22697 invoked by uid 399); 14 Apr 2012 01:51:19 -0000 Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 14 Apr 2012 01:51:19 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F88D816.9010104@dougbarton.us> Date: Fri, 13 Apr 2012 18:51:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: David Conrad References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> In-Reply-To: <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 01:51:31 -0000 On 4/13/2012 2:19 PM, David Conrad wrote: > Patrik, > > On Apr 13, 2012, at 2:00 PM, Patrik Fältström wrote: >> What I am against is this *CHANGE* in who is responsible. > > I don't see NTAs changing who is responsible. I see it changing who > absorbs the costs. Without NTAs, it is primarily the validator > operator and those costs can't be passed on to the responsible folks. > With NTAs, the validator operator can avoid those costs. I understand the economics involved, and I started to write more about that in my response, but decided to focus on the SECurity issues instead because I think that's the key issue. Fortunately Paul handled the economic stuff better than I could have. It sucks that validating ISPs are going to get blamed for validation failures, but this is a cost that they already absorb for other failures that they don't control. End users do not have the sophistication to understand *why* something broke, or even *where*. They just know that they can't get to where they want to go, and if that happens they blame/contact the ISP. What's being suggested with NTAs is that because validation *is* something that they control, it would be nice to have a knob to easily disable validation per zone. I get that. But ... > The > authority that has screwed up has increased risks that the names they > are serving can be poisoned which they presumably care about if they > have bothered to sign (even if they screwed it up). I have some > faith that if an authority screws up, numerous people will make them > aware of that screwup. The problem, and I cannot emphasize this highly enough, is that there is absolutely no way for an ISP (or other end-user site doing recursion/validation) to determine conclusively that the failure they are seeing is due to a harmless stuff-up, vs. an actual security incident. IOW, if we do this, we might as well just abandon DNSSEC altogether. > More pragmatically, while I understand the theory behind rejecting > NTAs, I have to admit it feels a bit like the IETF rejecting NATs > and/or DNS redirection. I would be surprised if folks who implement > NTAs will stop using them if they are not accepted by the IETF. Actually I think what's more likely to happen is that organizations conclude that validation is not ready for prime time, and turn it off. And as much as I'm a huge fan of doing validation on the end host, I think at this stage doing it at the network level is better since at least at that level there should be sufficient clue to contact the site about the errors. Doug -- If you're never wrong, you're not trying hard enough From paf@frobbit.se Fri Apr 13 23:17:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8339621F8658 for ; Fri, 13 Apr 2012 23:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj0zoAvDqQJ9 for ; Fri, 13 Apr 2012 23:17:41 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id CBFA021F864E for ; Fri, 13 Apr 2012 23:17:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3125E138F315C; Sat, 14 Apr 2012 08:17:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ4qctkL-6HE; Sat, 14 Apr 2012 08:17:40 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 001A8138F3152; Sat, 14 Apr 2012 08:17:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> Date: Sat, 14 Apr 2012 08:17:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> To: Jaap Akkerhuis X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" , David Conrad Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 06:17:41 -0000 On 14 apr 2012, at 00:30, Jaap Akkerhuis wrote: > (paf) > > But, all of this thinking leads me to think about DNSSEC = validation > > "risks" are very similar to the risk with deploying IPv6? > > We have an IPv6 day, but why not a DNSSEC day? One day where > > *many* players at the same time turn on DNSSEC validation? >=20 > (drc) > Definitely a good idea. >=20 > It is seems a nice idea but a problem is that a single day is > probably not enough. IPv6 problems are (nearly) instantaneous but > with DNSSEC problems start to arise when things expire. I was more thinking of the IPv6 Launch Day that we have this year, where = IPv6 is turned on and not off. "DNSSEC validation launch day". Patrik From paf@frobbit.se Fri Apr 13 23:36:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98BC21F86C2 for ; Fri, 13 Apr 2012 23:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gskumUCVsjz0 for ; Fri, 13 Apr 2012 23:36:23 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 4178221F86AF for ; Fri, 13 Apr 2012 23:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id BCC7E138F3663; Sat, 14 Apr 2012 08:36:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DllG6iUq9rQJ; Sat, 14 Apr 2012 08:36:21 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 91404138F365C; Sat, 14 Apr 2012 08:36:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120413235000.37DE31FB2097@drugs.dv.isc.org> Date: Sat, 14 Apr 2012 08:36:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C2D3665-7769-4C07-A4D1-82ED7380B4BE@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> <20120413235000.37DE31FB2097@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" , David Conrad Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 06:36:24 -0000 On 14 apr 2012, at 01:50, Mark Andrews wrote: > What one needs to do is validate answers from one's own zones > internally as well as answers from the rest of the world. Unfortunately too many of the broken zones we have in Sweden are the = ones where split DNS is in use and the external zone is broken while = internal one is not signed at all. Not until Microsoft do have full = working support for DNSSEC (which is coming now...) this will be = resolved, and then many more zones will be signed. But, as soon as someone actually go to the home page of a city, it will = fail as large ISPs do validate in Sweden. Next step is that a complaint = is to be filed and the problem solved. Unfortunately this process is often repeated next time there is key roll = over unless the city start having interesting stuff on their web site... = :-P Patrik From jaap@NLnetLabs.nl Sat Apr 14 07:29:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43121F85E3 for ; Sat, 14 Apr 2012 07:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8lYepb6+1vu for ; Sat, 14 Apr 2012 07:29:26 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD821F84D9 for ; Sat, 14 Apr 2012 07:29:25 -0700 (PDT) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id q3EETNuW043892 for ; Sat, 14 Apr 2012 16:29:23 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) X-DKIM: OpenDKIM Filter v2.5.1 bartok.nlnetlabs.nl q3EETNuW043892 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=sleutel; t=1334413763; bh=QYCklU0rRxNmG+0cDB4WCjZo3JKUDk1FOfbRSinmbEI=; h=To:Subject:In-reply-to:References:Date:From; b=X4NHp3GIdYpNJV+7IpsyXuQ9DLgAfcI+CnO4Z3sZLiTgXeoDJ32uyoi2gED/QM8+u dQfLQ9bmueXUEB3TBcjR4vG43+pgfpTYy1d1sMOCI0BC0AtQge5HkXFyE4tnzD6E9l ajnu+kazfdwUs7Xk16OLjbOAscABsnpoD3aXGJc4= Message-Id: <201204141429.q3EETNuW043892@bartok.nlnetlabs.nl> To: "dnsop@ietf.org WG" In-reply-to: <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> Comments: In-reply-to David Conrad message dated "Fri, 13 Apr 2012 16:38:10 -0700." Date: Sat, 14 Apr 2012 16:29:23 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bartok.nlnetlabs.nl [127.0.0.1]); Sat, 14 Apr 2012 16:29:23 +0200 (CEST) Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:29:26 -0000 On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote: >> More pragmatically, while I understand the theory behind rejecting NTAs, >> I have to admit it feels a bit like the IETF rejecting NATs and/or DNS >> redirection. I would be surprised if folks who implement NTAs will stop >> using them if they are not accepted by the IETF. >> > it is still not a reason for the IETF to standardize this. With the implication that multiple vendors go and implement the same thing in incompatible ways. I always get a headache when this sort of thing happens as the increased operational costs of non-interoperable implementations usually seems more damaging to me than violations of architectural purity. Different perspectives I guess. If people have to do te hack themselves, they are more likely to understand what they are doing. If you want to give a standard tool they might apply it just because it is there. It is like the BIND (temporary?) "delegation only" hack. Lots of people applied it without understanding. As an example, when some authoritative domains brough all there name servers in balliwick, it broke the lookup for those domains and people couldn't figure out why. And apart from this operational problem, there are more principal objections such as pointed out by Doug. jaap From paul@redbarn.org Sat Apr 14 09:25:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8D721F84DC for ; Sat, 14 Apr 2012 09:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2N52RnKw8TY for ; Sat, 14 Apr 2012 09:25:35 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1725821F84DF for ; Sat, 14 Apr 2012 09:25:17 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:e0ee:9ce0:64de:e1ac] (unknown [IPv6:2001:559:8000:cb:e0ee:9ce0:64de:e1ac]) by ss.vix.com (Postfix) with ESMTP id 304ACEDFC9 for ; Sat, 14 Apr 2012 16:25:16 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F89A4E8.1070008@redbarn.org> Date: Sat, 14 Apr 2012 16:25:12 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "dnsop@ietf.org WG" References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <4F88D816.9010104@dougbarton.us> In-Reply-To: <4F88D816.9010104@dougbarton.us> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:25:37 -0000 On 2012-04-14 1:51 AM, Doug Barton wrote: > ... The problem, and I cannot emphasize this highly enough, is that > there is absolutely no way for an ISP (or other end-user site doing > recursion/validation) to determine conclusively that the failure they > are seeing is due to a harmless stuff-up, vs. an actual security > incident. IOW, if we do this, we might as well just abandon DNSSEC > altogether. this is what i was alluding to in some text up-thread: On 2012-04-13 5:43 PM, Paul Vixie wrote: > ... i'm opposed to negative trust anchors, ... for their security implications if there were secure applications in existence, ... because a secure application must be able to fail reliably under attack. introducing third party bogosity breaks that failure, and it won't matter whether it's SOPA or NTA that breaks it. if i can leave you all with one thought its that dnssec failure must be reliable, end to end. see also . paul From warren@kumari.net Sat Apr 14 22:54:24 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BEF21F8710 for ; Sat, 14 Apr 2012 22:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.255 X-Spam-Level: X-Spam-Status: No, score=-106.255 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYqXw234ExKt for ; Sat, 14 Apr 2012 22:54:24 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id DBC9721F870F for ; Sat, 14 Apr 2012 22:54:23 -0700 (PDT) Received: from [192.168.179.109] (unknown [74.125.122.49]) by vimes.kumari.net (Postfix) with ESMTPSA id A87D51B402FA; Sun, 15 Apr 2012 01:54:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> Date: Sat, 14 Apr 2012 21:23:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: Nicholas Weaver , Tony Finch , "" , Paul Vixie , Evan Hunt , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 05:54:24 -0000 On Apr 13, 2012, at 6:02 PM, Patrik F=E4ltstr=F6m wrote: >=20 > On 13 apr 2012, at 23:43, Nicholas Weaver wrote: >=20 >> Likewise, comcast being blamed for... >=20 > Because (1) they seem to be the only large resolver operator that do = validation(?) and (2) people like us on this list try to work out end = runs around the standards we created instead of helping Comcast. >=20 > Yes, I blame myself personally there as well for not doing enough. I = was working hard when we deployed DNSSEC in Sweden to counter attack all = such arguments in the press that you refer to, and I thought, naively, = that as we managed to go through those issues, other people would as = well. >=20 > But as I said in an earlier message, maybe we where lucky in Sweden = that all major ISPs did deploy validation at the same time. In the US it = seems to be Comcast only(?). >=20 > What would have happened if AT&T and Comcast and Verizon started = validation basically the same week? Yes, but AT&T, Verizon, Cox, BestWeb, RR, TW, etc are currently *not* = doing validation, and currently don't have much in the way of incentives = to start -- yes, NASA was an unusual event, but what was the standard = advice that kept popping up on twitter / forums / fb, etc? "Change your resolver to be 8.8.8.8 and the problem is fixed" -- now, = I'm all for folk changing to use Google's resolvers, but to avoid = validation isn't the right reason=85 Yes, NTAs suck and have some really bad security implications, but I = believe that the alternative is worse. Without a way for validating = resolver operators to avoid users jumping ship to non-validation = resolver operators we delay adoption (imo significantly) and users are = at a much larger risk for a much longer time. Once most ISPs are performing validation there should be fewer screwups, = and NTAs should be almost never needed -- but until we get to that point = I think that they are needed, and the net security wins outweigh the = costs=85 W [ Written on a plane, will send when I land. The conversation may have = moved on since then=85 ]=20 >=20 > Now of course we can not turn back clock, but I think still "we give = up too early" if we go down this path. >=20 > That is my reason for a +1. >=20 > Now I will go to sleep. It is Friday, and I feel I am hijacking this = thread. Violating principles of IETF lists I like myself. >=20 > More people should say what they want to say. >=20 > Patrik >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 From paf@frobbit.se Sat Apr 14 23:33:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7D321F8713 for ; Sat, 14 Apr 2012 23:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuELEJO+WgdV for ; Sat, 14 Apr 2012 23:33:57 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id BF87E21F8712 for ; Sat, 14 Apr 2012 23:33:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 202ED139054E2; Sun, 15 Apr 2012 08:33:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnqUr7CU0Lbf; Sun, 15 Apr 2012 08:33:48 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id D7ED5139054DB; Sun, 15 Apr 2012 08:33:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> Date: Sun, 15 Apr 2012 08:33:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1257) Cc: Nicholas Weaver , Tony Finch , "" , Paul Vixie , Evan Hunt , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 06:33:58 -0000 On 15 apr 2012, at 03:23, Warren Kumari wrote: > Once most ISPs are performing validation there should be fewer = screwups, and NTAs should be almost never needed -- but until we get to = that point I think that they are needed, and the net security wins = outweigh the costs=85 ...and my point is that the effort should be spent on convincing AT&T, = Cox and others to do validation just like Comcast. And to inform the = users, press and others that for example it was NASA and not Comcast = that had problems. Solution is not to do a work around in the IETF that have all different = kind of security implications, similar to the ones Doug describes. Creating NTAs so that people, as Doug says, can turn off validation per = zone without interaction with whoever is responsible for the zone, = without interaction with whoever *decided* that the zone should be = signed, and without knowing whether it is a security incident or just a = management mistake, is I think the end of DNSSEC. So, I rather see those that do not feel comfortable taking the = discussion with the press and their customers (and of course this is = also due to zone owners not doing enough press and help when they screw = up) turn off validation completely, and then work together in whatever = community they operate with other resolver operators to turn on = validation on the same day, with the help of ISOC and whoever and have a = DNSSEC validation launch day. Similar work that you at Google did for = IPv6. Much better than creating NTAs. I see *today* many mistakes we have made that see the need for DNSSEC, = and we could, and still can, learn from the IPv6 advocates on how to = deploy something new. Easy to say afterwards though. Patrik From joe.abley@icann.org Sun Apr 15 07:41:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A301721F866A for ; Sun, 15 Apr 2012 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXHmq31aquJw for ; Sun, 15 Apr 2012 07:41:44 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id DAE8321F8663 for ; Sun, 15 Apr 2012 07:41:44 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Sun, 15 Apr 2012 07:41:44 -0700 From: Joe Abley To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Date: Sun, 15 Apr 2012 07:42:15 -0700 Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0bFeB5GMaOea2aRYqSvDrh0DQUhg== Message-ID: <830AF293-6530-4E48-BF43-95FE1C34BE78@icann.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> In-Reply-To: <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Nicholas Weaver , Tony Finch , "Livingood, Jason" , "" , Paul Vixie , Evan Hunt Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 14:41:45 -0000 UGF0cmlrLA0KDQpOb2JvZHkgaXMgdGFsa2luZyBhYm91dCBjcmVhdGluZyBOVEFzLiBOVEFzIGFs cmVhZHkgZXhpc3QuIFRoZSBxdWVzdGlvbiBmb3IgdGhpcyBncm91cCBpcyB3aGV0aGVyIG9yIG5v dCB0aGV5IGFyZSB3b3J0aCBzdGFuZGFyZGlzaW5nLg0KDQoNCkpvZQ0KDQpTZW50IGZyb20gbXkg T25vLVNlbmRhaSBDeWJlcnNwYWNlIDcNCg0KT24gMjAxMi0wNC0xNSwgYXQgMjozNCwgIlBhdHJp ayBGw6RsdHN0csO2bSIgPHBhZkBmcm9iYml0LnNlPiB3cm90ZToNCg0KPiBPbiAxNSBhcHIgMjAx MiwgYXQgMDM6MjMsIFdhcnJlbiBLdW1hcmkgd3JvdGU6DQo+IA0KPj4gT25jZSBtb3N0IElTUHMg YXJlIHBlcmZvcm1pbmcgdmFsaWRhdGlvbiB0aGVyZSBzaG91bGQgYmUgZmV3ZXIgc2NyZXd1cHMs IGFuZCBOVEFzIHNob3VsZCBiZSBhbG1vc3QgbmV2ZXIgbmVlZGVkIC0tIGJ1dCB1bnRpbCB3ZSBn ZXQgdG8gdGhhdCBwb2ludCBJIHRoaW5rIHRoYXQgdGhleSBhcmUgbmVlZGVkLCBhbmQgdGhlIG5l dCBzZWN1cml0eSB3aW5zIG91dHdlaWdoIHRoZSBjb3N0c+KApg0KPiANCj4gLi4uYW5kIG15IHBv aW50IGlzIHRoYXQgdGhlIGVmZm9ydCBzaG91bGQgYmUgc3BlbnQgb24gY29udmluY2luZyBBVCZU LCBDb3ggYW5kIG90aGVycyB0byBkbyB2YWxpZGF0aW9uIGp1c3QgbGlrZSBDb21jYXN0LiBBbmQg dG8gaW5mb3JtIHRoZSB1c2VycywgcHJlc3MgYW5kIG90aGVycyB0aGF0IGZvciBleGFtcGxlIGl0 IHdhcyBOQVNBIGFuZCBub3QgQ29tY2FzdCB0aGF0IGhhZCBwcm9ibGVtcy4NCj4gDQo+IFNvbHV0 aW9uIGlzIG5vdCB0byBkbyBhIHdvcmsgYXJvdW5kIGluIHRoZSBJRVRGIHRoYXQgaGF2ZSBhbGwg ZGlmZmVyZW50IGtpbmQgb2Ygc2VjdXJpdHkgaW1wbGljYXRpb25zLCBzaW1pbGFyIHRvIHRoZSBv bmVzIERvdWcgZGVzY3JpYmVzLg0KPiANCj4gQ3JlYXRpbmcgTlRBcyBzbyB0aGF0IHBlb3BsZSwg YXMgRG91ZyBzYXlzLCBjYW4gdHVybiBvZmYgdmFsaWRhdGlvbiBwZXIgem9uZSB3aXRob3V0IGlu dGVyYWN0aW9uIHdpdGggd2hvZXZlciBpcyByZXNwb25zaWJsZSBmb3IgdGhlIHpvbmUsIHdpdGhv dXQgaW50ZXJhY3Rpb24gd2l0aCB3aG9ldmVyICpkZWNpZGVkKiB0aGF0IHRoZSB6b25lIHNob3Vs ZCBiZSBzaWduZWQsIGFuZCB3aXRob3V0IGtub3dpbmcgd2hldGhlciBpdCBpcyBhIHNlY3VyaXR5 IGluY2lkZW50IG9yIGp1c3QgYSBtYW5hZ2VtZW50IG1pc3Rha2UsIGlzIEkgdGhpbmsgdGhlIGVu ZCBvZiBETlNTRUMuDQo+IA0KPiBTbywgSSByYXRoZXIgc2VlIHRob3NlIHRoYXQgZG8gbm90IGZl ZWwgY29tZm9ydGFibGUgdGFraW5nIHRoZSBkaXNjdXNzaW9uIHdpdGggdGhlIHByZXNzIGFuZCB0 aGVpciBjdXN0b21lcnMgKGFuZCBvZiBjb3Vyc2UgdGhpcyBpcyBhbHNvIGR1ZSB0byB6b25lIG93 bmVycyBub3QgZG9pbmcgZW5vdWdoIHByZXNzIGFuZCBoZWxwIHdoZW4gdGhleSBzY3JldyB1cCkg dHVybiBvZmYgdmFsaWRhdGlvbiBjb21wbGV0ZWx5LCBhbmQgdGhlbiB3b3JrIHRvZ2V0aGVyIGlu IHdoYXRldmVyIGNvbW11bml0eSB0aGV5IG9wZXJhdGUgd2l0aCBvdGhlciByZXNvbHZlciBvcGVy YXRvcnMgdG8gdHVybiBvbiB2YWxpZGF0aW9uIG9uIHRoZSBzYW1lIGRheSwgd2l0aCB0aGUgaGVs cCBvZiBJU09DIGFuZCB3aG9ldmVyIGFuZCBoYXZlIGEgRE5TU0VDIHZhbGlkYXRpb24gbGF1bmNo IGRheS4gU2ltaWxhciB3b3JrIHRoYXQgeW91IGF0IEdvb2dsZSBkaWQgZm9yIElQdjYuDQo+IA0K PiBNdWNoIGJldHRlciB0aGFuIGNyZWF0aW5nIE5UQXMuDQo+IA0KPiBJIHNlZSAqdG9kYXkqIG1h bnkgbWlzdGFrZXMgd2UgaGF2ZSBtYWRlIHRoYXQgc2VlIHRoZSBuZWVkIGZvciBETlNTRUMsIGFu ZCB3ZSBjb3VsZCwgYW5kIHN0aWxsIGNhbiwgbGVhcm4gZnJvbSB0aGUgSVB2NiBhZHZvY2F0ZXMg b24gaG93IHRvIGRlcGxveSBzb21ldGhpbmcgbmV3LiBFYXN5IHRvIHNheSBhZnRlcndhcmRzIHRo b3VnaC4NCj4gDQo+ICAgUGF0cmlrDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBETlNPUCBtYWlsaW5nIGxpc3QNCj4gRE5TT1BAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNvcA0K From drc@virtualized.org Sun Apr 15 08:46:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AECD21F87DC for ; Sun, 15 Apr 2012 08:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7lEGck4XTZk for ; Sun, 15 Apr 2012 08:46:52 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0BA21F8743 for ; Sun, 15 Apr 2012 08:46:52 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 40CAA1705A; Sun, 15 Apr 2012 15:46:51 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: David Conrad In-Reply-To: <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> Date: Sun, 15 Apr 2012 08:46:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24870F50-901D-41D4-968A-A6B91BBDAF93@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 15:46:53 -0000 Patrik, On Apr 14, 2012, at 11:33 PM, Patrik F=E4ltstr=F6m wrote: > ...and my point is that the effort should be spent on convincing AT&T, = Cox and others to do validation just like Comcast. The decisions as to whether to deploy an NTA vs. whether to deploy = DNSSEC are made a different times and (I suspect) different places = within the organization. Obviously, an organization must decide to = deploy DNSSEC before the question of whether to deploy NTAs becomes = relevant. My impression is that NTAs are/can be argued to reduce the = risks of deploying validating resolvers. > So, I rather see those that do not feel comfortable taking the = discussion with the press and their customers (and of course this is = also due to zone owners not doing enough press and help when they screw = up) I don't think it is a question of comfort. My impression is that it is a = question of not losing money due to customers being unable to get their = pr0n because validation has been turned on (whereas the customers' = friends at another ISP can get the same pr0n with no problems). I = suspect the vast majority of end users will simply not believe the = response of "the zone owner screwed up and our competition is not doing = the right thing". > turn off validation completely, This strikes me as far more detrimental to DNSSEC-enabled security than = NTAs. The implication of this approach is that a mistake of a single = zone owner would mean DNSSEC is disabled for everyone, everywhere, = regardless of how all the other signed zones are operating. NTAs mean = that validation is disabled for the offender only. > and then work together in whatever community they operate with other = resolver operators to turn on validation on the same day, with the help = of ISOC and whoever and have a DNSSEC validation launch day. Similar = work that you at Google did for IPv6. While I think a DNSSEC validation day is a good idea, the implication = here is that zone owners won't make mistakes after the DNSSEC validation = launch day. > I see *today* many mistakes we have made that see the need for DNSSEC, = and we could, and still can, learn from the IPv6 advocates on how to = deploy something new. Easy to say afterwards though. Given the stunning level of IPv6 deployment after more than a decade, = I'm not sure I see emulating IPv6 in this regard as the best idea. Regards, -drc From paf@frobbit.se Sun Apr 15 09:09:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A158521F87EF for ; Sun, 15 Apr 2012 09:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1o5Pdy5-mRZ for ; Sun, 15 Apr 2012 09:09:58 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id ED92B21F8764 for ; Sun, 15 Apr 2012 09:09:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4E16F1390D7AD; Sun, 15 Apr 2012 18:09:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aOTg6FcRUcI; Sun, 15 Apr 2012 18:09:56 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 1AD721390D7A6; Sun, 15 Apr 2012 18:09:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <830AF293-6530-4E48-BF43-95FE1C34BE78@icann.org> Date: Sun, 15 Apr 2012 18:09:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <354BE3E4-73FD-471C-9E3E-9FFC86EDB57E@frobbit.se> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <830AF293-6530-4E48-BF43-95FE1C34BE78@icann.org> To: Joe Abley X-Mailer: Apple Mail (2.1257) Cc: Nicholas Weaver , Tony Finch , "Livingood, Jason" , "" , Paul Vixie , Evan Hunt Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:09:58 -0000 On 15 apr 2012, at 16:42, Joe Abley wrote: > Nobody is talking about creating NTAs. NTAs already exist. The = question for this group is whether or not they are worth standardising. Fair. I am the one that extrapolate from standardizing to "wide = deployment". > Sent from my Ono-Sendai Cyberspace 7 Do they validate DNSSEC signatures there? ;-) Patrik From drc@virtualized.org Sun Apr 15 09:15:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25D21F87E6 for ; Sun, 15 Apr 2012 09:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXbfZF6wjXDf for ; Sun, 15 Apr 2012 09:15:29 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0B54621F87D8 for ; Sun, 15 Apr 2012 09:15:29 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 7C6BC1705A; Sun, 15 Apr 2012 16:15:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: David Conrad In-Reply-To: <4F88D816.9010104@dougbarton.us> Date: Sun, 15 Apr 2012 09:15:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <617BB78F-619B-4FB9-9957-435CBD671494@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <4F88D816.9010104@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:15:29 -0000 Doug, On Apr 13, 2012, at 6:51 PM, Doug Barton wrote: > The problem is that there is absolutely no way for an ISP to determine = conclusively that the failure they are seeing is due to a harmless = stuff-up, vs. an actual security incident. I suspect that in most cases, grepping through logs and comparing past = (validated) results with current (unvalidated) results can provide = sufficient information to ensure to an arbitrary level of certainty that = the bad thing either is or is not happening. For example, if the logs = show the IP address for mail.example.com maps via whois into a block = owned by Example, LLC. and the current IP address maps into a block = owned by a dialup provider in Tajikistan, it's probably safe to assume = the address shouldn't be trusted. > IOW, if we do this, we might as well just abandon DNSSEC altogether. Joe has pointed out that folks are already doing this. The question = before us is whether or not there is a standard way of doing it. >> I would be surprised if folks who implement >> NTAs will stop using them if they are not accepted by the IETF. >=20 > Actually I think what's more likely to happen is that organizations > conclude that validation is not ready for prime time, and turn it off. I guess I have less faith in the power of the IETF. Regards, -drc From paul@redbarn.org Sun Apr 15 09:19:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6F321F87F5 for ; Sun, 15 Apr 2012 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=2.850, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhAwDVh6BLd7 for ; Sun, 15 Apr 2012 09:19:19 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id D7AE421F87E6 for ; Sun, 15 Apr 2012 09:19:19 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:61b0:c3ac:dcca:41b3] (unknown [IPv6:2001:559:8000:cb:61b0:c3ac:dcca:41b3]) by ss.vix.com (Postfix) with ESMTP id 54001EDFC9; Sun, 15 Apr 2012 16:19:18 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F8AF506.7020803@redbarn.org> Date: Sun, 15 Apr 2012 16:19:18 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <830AF293-6530-4E48-BF43-95FE1C34BE78@icann.org> <354BE3E4-73FD-471C-9E3E-9FFC86EDB57E@frobbit.se> In-Reply-To: <354BE3E4-73FD-471C-9E3E-9FFC86EDB57E@frobbit.se> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Joe Abley , Nicholas Weaver , Tony Finch , "" , Evan Hunt , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:19:20 -0000 On 2012-04-15 4:09 PM, Patrik Fältström wrote: > On 15 apr 2012, at 16:42, Joe Abley wrote: > >> Nobody is talking about creating NTAs. NTAs already exist. The question for this group is whether or not they are worth standardising. > Fair. I am the one that extrapolate from standardizing to "wide deployment". extrapolating further, standardizing is a form of legitimization. i argue that this would do more harm than good. From stephan.lagerholm@secure64.com Sun Apr 15 09:20:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7F21F87E6 for ; Sun, 15 Apr 2012 09:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb4BxVtcfePd for ; Sun, 15 Apr 2012 09:20:26 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 14E4F21F8699 for ; Sun, 15 Apr 2012 09:20:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id B1C43B8501; Sun, 15 Apr 2012 10:20:24 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEeQqmD7r8wN; Sun, 15 Apr 2012 10:20:12 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id D14ACB84F3; Sun, 15 Apr 2012 10:20:11 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1334506811; bh=L9OPZ5nsBX8IdscMpypHPaECL4D+qu2sL2e492kWvKg=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=R0zvlWpTyZHGxkWSU/ xY/k3gpik4XpSbI4QtabZGkJF7uKgYIUt1eY+/WmBaC1FMHyh6jXn6T0kpznvL0zlU1 4h1sXbKvh5+8WKDUckwTbUQrDWLtGzkxoQjEEl8jzD88BJAFI8tZAkLfbSFjWE2IgUB p58xQpIddM4liECHt50= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Apr 2012 10:20:05 -0600 Message-ID: In-Reply-To: <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0a0cRlIIzggz1sQ0uRIR+LY16SGAAUB8IQ References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu><9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU><536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se><4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> From: "Stephan Lagerholm" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Warren Kumari" Cc: Nicholas Weaver , Tony Finch , dnsop@ietf.org, Paul Vixie , Evan Hunt , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:20:26 -0000 Patrik F=E4ltstr=F6m, Sunday, April 15, 2012 1:34 AM": =20 > ...and my point is that the effort should be spent on convincing AT&T, > Cox and others to do validation just like Comcast. And to inform the > users, press and others that for example it was NASA and not Comcast > that had problems. Convincing other service providers is a good long term idea. That would = increase the pressure on the zone operators to do DNSSEC properly. = However, the open resolvers that don't support DNSSEC are a bigger = "issue" since the Service Providers' customer instantly can get what he = believes is a better working resolver by switching to one of those. If = we could convince 8.8.8.8 (208.67.222.222 and 4.2.2.1) to turn on DNSSEC = validation, then there would not be any need for NTAs. /S From pawal@blipp.com Sun Apr 15 09:29:19 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280BD21F87F3 for ; Sun, 15 Apr 2012 09:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y2QH23m4ZMz for ; Sun, 15 Apr 2012 09:29:18 -0700 (PDT) Received: from vic20.blipp.com (vic20.blipp.com [213.115.13.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDF721F86D1 for ; Sun, 15 Apr 2012 09:29:18 -0700 (PDT) Received: from [192.168.0.142] (fh218n1-asp-a13.ias.bredband.telia.com [212.181.174.218]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 9F38438069; Sun, 15 Apr 2012 18:29:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Patrik Wallstrom In-Reply-To: <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> Date: Sun, 15 Apr 2012 18:29:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:29:19 -0000 On Apr 14, 2012, at 1:38 AM, David Conrad wrote: > On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote: >>> More pragmatically, while I understand the theory behind rejecting = NTAs, >>> I have to admit it feels a bit like the IETF rejecting NATs and/or = DNS >>> redirection. I would be surprised if folks who implement NTAs will = stop >>> using them if they are not accepted by the IETF. >>>=20 >> it is still not a reason for the IETF to standardize this. >=20 > With the implication that multiple vendors go and implement the same = thing in incompatible ways. I always get a headache when this sort of = thing happens as the increased operational costs of non-interoperable = implementations usually seems more damaging to me than violations of = architectural purity. Different perspectives I guess. Then I should probably go ahead and write another draft with just one = statement in it, maybe something like "do not put in NTAs in a = resolver". Problem solved? But I guess that it would have the same effect as RFC 5966. From stephan.lagerholm@secure64.com Sun Apr 15 09:36:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E21821F881C for ; Sun, 15 Apr 2012 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAyvPaVkEyhH for ; Sun, 15 Apr 2012 09:36:39 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id C08A821F881B for ; Sun, 15 Apr 2012 09:36:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 85C9AB8501; Sun, 15 Apr 2012 10:36:39 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PSmYJ1-vmQT; Sun, 15 Apr 2012 10:36:27 -0600 (MDT) Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 93D91B84F3; Sun, 15 Apr 2012 10:36:27 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1334507787; bh=VP4YsF/yEmw4L2p4iEoKPdrdRL3EAzksj/O7c8bjo/A=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To:Cc; b=bWn/0wwGMWZG5UhfgD K0gSUwvsqzWAy/sqOZyfsWmwQC84OI9SeXbtHWtEnqN4x9nrWx9sLVApeMdZ52V2w7J iBSyB3H+9W1Y+nbwWl93WGoOImBvVkS+GkZQNEc4G5eaxMOBK7SpfTLwaZmpuIJ4gq3 ghNKnrc0rRcDlmEw7BY= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Apr 2012 10:36:19 -0600 Message-ID: In-Reply-To: <617BB78F-619B-4FB9-9957-435CBD671494@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0bIvwNZdw7H1bRQw6JYw4Cg/YhtAAAe7BQ References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se><330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org><4F88D816.9010104@dougbarton.us> <617BB78F-619B-4FB9-9957-435CBD671494@virtualized.org> From: "Stephan Lagerholm" To: "David Conrad" , "Doug Barton" Cc: dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:36:40 -0000 David Conrad, Sunday, April 15, 2012 11:15 AM:=20 > I suspect that in most cases, grepping through logs and comparing past > (validated) results with current (unvalidated) results can provide > sufficient information to ensure to an arbitrary level of certainty > that the bad thing either is or is not happening. For example, if the > logs show the IP address for mail.example.com maps via whois into a > block owned by Example, LLC. and the current IP address maps into a > block owned by a dialup provider in Tajikistan, it's probably safe to > assume the address shouldn't be trusted. =20 -1 on that approach. You are turning off DNSSEC for the entire domain. Just spot checking mail.example.com and www.example.com is not sufficient. They might still be valid whereas moneytransfersystem.example.com is not. And your dig checks are not secure since you can't validate (since DNSSEC is broken). The requirement for an NTA (or for removing a DS from a parent) should be as strict as for adding a DS. That is, it must be done with an secure out of band mechanism. /S From paul@redbarn.org Sun Apr 15 09:37:43 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1248F21F881C for ; Sun, 15 Apr 2012 09:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.869 X-Spam-Level: X-Spam-Status: No, score=-7.869 tagged_above=-999 required=5 tests=[AWL=2.130, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vQe-0XYKZ5f for ; Sun, 15 Apr 2012 09:37:42 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE8621F8816 for ; Sun, 15 Apr 2012 09:37:42 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:61b0:c3ac:dcca:41b3] (unknown [IPv6:2001:559:8000:cb:61b0:c3ac:dcca:41b3]) by ss.vix.com (Postfix) with ESMTP id 4F641EDFCE for ; Sun, 15 Apr 2012 16:37:42 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F8AF955.2060500@redbarn.org> Date: Sun, 15 Apr 2012 16:37:41 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu><9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU><536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se><4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:37:43 -0000 On 2012-04-15 4:20 PM, Stephan Lagerholm wrote: > ... However, the open resolvers that don't support DNSSEC are a bigger > "issue" since the Service Providers' customer instantly can get what > he believes is a better working resolver by switching to one of those. > If we could convince 8.8.8.8 (208.67.222.222 and 4.2.2.1) to turn on > DNSSEC validation, then there would not be any need for NTAs. ... dnssec makes dns less reliable. that's because it's a security technology not a resiliency technology. security makes things harder to use and makes failures more apparent. in the real world if you put a lock on your house or your car then you're at risk for forgetting or losing your key and not being able to enter or use your own property. you could mitigate that risk by removing the lock but then you'd have other risks. what's unique about dnssec is that if you lose your key or use the wrong key or forget to re-sign your zones then it's not you (the property owner) who cannot enter or use the zones, but rather, everybody else. i don't think that asymmetry of cost changes the fundamentals. the operators of 8.8.8.8 and so on (from the above examples) may have done a cost:benefit analysis leading them to not deploy dnssec validation at this time. that will make their systems more reliable in the eyes of end users. that's true and that's inevitable. i'm imagining that some NTA-using party notices via their syslogs that validation is failing for some zone, and believing that access to this zone in an unsecure way has a better cost:benefit ratio to them and to their own customers than letting the failure propagate and so enters the zone into the NTA... only to have it turn out later that there was a key compromise and the failure was due to a credential or key or system attack rather than due to someone forgetting or losing their key. people who sign their zones must be told, early and often, that adds risk. they will have to re-sign their zones before signatures expire, they will have to carefully coordinate key changes with their parent zone, they will have to keep their signing key under secure but redundant control... and any failure by them to do any of those things will make their zones unreachable by a large and growing audience. if they sign anyway then any resulting failures have to be laid at their doorstep, not at validating server operators' doorsteps. if a secure application knows that a zone is supposed to be signed (because there are DS RRs in the parent and the parent is signed) then an upstream NTA will just look like a signature-stripping attacker. let us not imagine that there will never be secure applications other than recursive name servers (and here i'm thinking of DANE), and let us also not imagine that every secure application (here i'm again thinking of DANE) will have to subscribe to a trusted NTA. dnssec is end to end, including dnssec failures, which are statistically inevitable. i'd tell validator operators who think they need NTA's in order to control the risks posed by zone owner errors, "if you can't stand the heat then stay out of the kitchen." see also . paul From paf@frobbit.se Sun Apr 15 10:19:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DBF21F883A for ; Sun, 15 Apr 2012 10:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4NJDxSaAcYd for ; Sun, 15 Apr 2012 10:19:28 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 898A421F8832 for ; Sun, 15 Apr 2012 10:19:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 39DAD1390E75E; Sun, 15 Apr 2012 19:19:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0G7ShDj+oqj; Sun, 15 Apr 2012 19:19:24 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id E969B1390E757; Sun, 15 Apr 2012 19:19:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <24870F50-901D-41D4-968A-A6B91BBDAF93@virtualized.org> Date: Sun, 15 Apr 2012 19:19:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <24870F50-901D-41D4-968A-A6B91BBDAF93@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 17:19:28 -0000 On 15 apr 2012, at 17:46, David Conrad wrote: > The decisions as to whether to deploy an NTA vs. whether to deploy = DNSSEC are made a different times and (I suspect) different places = within the organization. Obviously, an organization must decide to = deploy DNSSEC before the question of whether to deploy NTAs becomes = relevant. My impression is that NTAs are/can be argued to reduce the = risks of deploying validating resolvers. This all depends on the arguments in favor of, and against, validating = resolvers. What I think you say is "...can be argued to reduce the risk of being = blamed if someone is making mistakes with their keys." I.e. with the help of standardized NTAs, it will be easier for parties = to always be able to give back responses, regardless of whether they = validate or not. Which I think is the wrong view. You (and many more) = have a different view. In Sweden, for some reason, we managed to get people to deploy = validators without being afraid of the risk of being blamed. Or rather, = the "risk" of being blamed was much lower in the calculation that lead = to so many access providers turning on validation. >> So, I rather see those that do not feel comfortable taking the = discussion with the press and their customers (and of course this is = also due to zone owners not doing enough press and help when they screw = up) >=20 > I don't think it is a question of comfort. My impression is that it is = a question of not losing money due to customers being unable to get = their pr0n because validation has been turned on (whereas the customers' = friends at another ISP can get the same pr0n with no problems). I = suspect the vast majority of end users will simply not believe the = response of "the zone owner screwed up and our competition is not doing = the right thing". Ok, I agree with this, and it was sort of what I said as well. >> turn off validation completely, >=20 > This strikes me as far more detrimental to DNSSEC-enabled security = than NTAs. The implication of this approach is that a mistake of a = single zone owner would mean DNSSEC is disabled for everyone, = everywhere, regardless of how all the other signed zones are operating. = NTAs mean that validation is disabled for the offender only. Ok. >> and then work together in whatever community they operate with other = resolver operators to turn on validation on the same day, with the help = of ISOC and whoever and have a DNSSEC validation launch day. Similar = work that you at Google did for IPv6. >=20 > While I think a DNSSEC validation day is a good idea, the implication = here is that zone owners won't make mistakes after the DNSSEC validation = launch day. Well, we of course must first decide what the problem is, and what = problem we might resolve with a validation deployment day. I think one thing it can help with is to make it more understandable to = /. people who is to blame for the inability to reach whatever is to be = reached. And to some degree that is what I heard from for example Google before = the initiative with IPv6 day started. >> I see *today* many mistakes we have made that see the need for = DNSSEC, and we could, and still can, learn from the IPv6 advocates on = how to deploy something new. Easy to say afterwards though. >=20 > Given the stunning level of IPv6 deployment after more than a decade, = I'm not sure I see emulating IPv6 in this regard as the best idea. Well, I was more thinking of the (un-) happy eyeballs problem. Or let me ask you differently, if many access providers and not only = Comcast started to do validation at the same time, would we be in a = different situation? Patrik From drc@virtualized.org Sun Apr 15 11:58:13 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23B021F87FB for ; Sun, 15 Apr 2012 11:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MULJJBzMjfd5 for ; Sun, 15 Apr 2012 11:58:13 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5421F85D9 for ; Sun, 15 Apr 2012 11:58:13 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 96FD51705A; Sun, 15 Apr 2012 18:58:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Sun, 15 Apr 2012 11:58:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se><330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org><4F88D816.9010104@dougbarton.us> <617BB78F-619B-4FB9-9957-435CBD671494@virtualized.org> To: "Stephan Lagerholm" X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 18:58:13 -0000 Stephan, On Apr 15, 2012, at 9:36 AM, Stephan Lagerholm wrote: > David Conrad, Sunday, April 15, 2012 11:15 AM:=20 >> I suspect that in most cases, grepping through logs and comparing = past >> (validated) results with current (unvalidated) results can provide >> sufficient information to ensure to an arbitrary level of certainty >> that the bad thing either is or is not happening. >=20 > -1 on that approach. The alternative is for names in the zone in question to not exist = resulting in your customer support center to receiving some number of = calls and/or customers bolting to service providers that don't do = validation. =20 At the current state of DNSSEC deployment, I suspect it is far more = likely that the zone owner has screwed something up. Validator operators = that deploy NTAs are implicitly assuring their customers that the zone = in question is actually safe. This presumably implies they will do some = level of due diligence to ensure that names in that zone are indeed = safe. How much due diligence they do is, of course, their own business = decision. > You are turning off DNSSEC for the entire domain. Just spot checking > mail.example.com and www.example.com is not sufficient. They might = still > be valid whereas moneytransfersystem.example.com is not. And your dig > checks are not secure since you can't validate (since DNSSEC is = broken). DNSSEC is broken for that zone. Without NTAs, you have the choice of = either the alternative above or turning off DNSSEC for all zones. Which = would you prefer? Regards, -drc From drc@virtualized.org Sun Apr 15 12:04:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C4B21F8849 for ; Sun, 15 Apr 2012 12:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLXq0aAmGzB7 for ; Sun, 15 Apr 2012 12:04:05 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3423621F883E for ; Sun, 15 Apr 2012 12:04:05 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id C43BE1705A; Sun, 15 Apr 2012 19:04:04 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4F8AF955.2060500@redbarn.org> Date: Sun, 15 Apr 2012 12:04:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu><9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU><536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se><4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 19:04:05 -0000 On Apr 15, 2012, at 9:37 AM, Paul Vixie wrote: > i'd tell validator operators who think they need NTA's in > order to control the risks posed by zone owner errors, "if you can't > stand the heat then stay out of the kitchen." Given the benefits provided by DNSSEC (to date) are largely invisible = and the costs quite non-trivial, I'd think this would ensure DNSSEC = validation never gets deployed, thus secure applications (such as DANE) = will never exist. I thought we'd learned that flag day deployments don't work on the = Internet anymore. Regards, -drc From drc@virtualized.org Sun Apr 15 12:18:50 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A488621F87D2 for ; Sun, 15 Apr 2012 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKorS4a8r9Ee for ; Sun, 15 Apr 2012 12:18:50 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id EA68E21F87CA for ; Sun, 15 Apr 2012 12:18:36 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 8E1E61705A; Sun, 15 Apr 2012 19:18:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: David Conrad In-Reply-To: Date: Sun, 15 Apr 2012 12:18:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A707D37-D7AD-4F49-A59C-B09743E34DF5@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <24870F50-901D-41D4-968A-A6B91BBDAF93@virtualized.org> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 19:18:50 -0000 Patrik, On Apr 15, 2012, at 10:19 AM, Patrik F=E4ltstr=F6m wrote: > I.e. with the help of standardized NTAs, it will be easier for parties = to always be able to give back responses, regardless of whether they = validate or not.=20 Or, more specifically, will be easier for parties to give back the same = responses that their (non-validating) competitors do. > In Sweden, for some reason, we managed to get people to deploy = validators without being afraid of the risk of being blamed. I'm guessing the reason has to do with scale. It might be helpful to get = an idea from ISPs in Sweden how many validation failures they have seen = (and how many calls they get as a result of those validation failures). = Given the lack of signed zones, I'm guessing the number of validation = failures is in the noise. It's only when you get a lot of (popular) = zones signed and a lot of people behind validators that false positive = validation failure becomes an issue. > I think one thing it can help with is to make it more understandable = to /. people who is to blame for the inability to reach whatever is to = be reached. I don't think /. folks are significant in the decision making. I suspect = what is more significant are the number of paying customers impacted by = validation failure. > Or let me ask you differently, if many access providers and not only = Comcast started to do validation at the same time, would we be in a = different situation? Potentially. However, I suspect it has more to do with the number of = false positives caused by the relative immaturity of the available = tools. As the tools get more mature and validation failures become = caused more by malicious intent than all too easily caused mistakes, the = desire for NTAs will wane (particularly given the implicit risks an ISP = takes on when deploying an NTA). Regards, -drc From paul@redbarn.org Sun Apr 15 13:12:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C3221F876A for ; Sun, 15 Apr 2012 13:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzr6ABKXXsQD for ; Sun, 15 Apr 2012 13:12:26 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id D269621F8739 for ; Sun, 15 Apr 2012 13:12:26 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:dc66:63ae:5ca4:a7be] (unknown [IPv6:2001:559:8000:cb:dc66:63ae:5ca4:a7be]) by ss.vix.com (Postfix) with ESMTP id DE316EBD60 for ; Sun, 15 Apr 2012 20:12:25 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F8B2BA9.1050603@redbarn.org> Date: Sun, 15 Apr 2012 20:12:25 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu><9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU><536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se><4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> In-Reply-To: <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 20:12:27 -0000 On 2012-04-15 7:04 PM, David Conrad wrote: > On Apr 15, 2012, at 9:37 AM, Paul Vixie wrote: >> i'd tell validator operators who think they need NTA's in >> order to control the risks posed by zone owner errors, "if you can't >> stand the heat then stay out of the kitchen." > Given the benefits provided by DNSSEC (to date) are largely invisible and the costs quite non-trivial, I'd think this would ensure DNSSEC validation never gets deployed, thus secure applications (such as DANE) will never exist. > > I thought we'd learned that flag day deployments don't work on the Internet anymore. i thought so too until we had "world ipv6 day" last year. noting that adding a AAAA record to www.{facebook,yahoo,google}.com has been seen to hit all kinds of roadblocks due to teredo and other failed tunneling mechanisms, the only way big companies will feel safe turning it on (knowing that they'll lose 0.3% of unique eyeballs when they do) is if they're traveling in a "pack" with other big companies. so it apparently will be for dnssec. nobody should validate until everybody validates, because otherwise the failures at the social security administration or nasa to sign and re-sign their zones, and to properly maintain the relationship between the keys they use and the DS RRs their parent zones have for them, will be felt by early adopters. ipv6 and dnssec both have incredibly strong early adopter penalties: "you can break me now, or you can break me later." i seek to avoid legitimizing the aaaa "igor hack" in bind9, and negative trust anchors. i know that people will do this stuff but i also know that IETF should not give either one an implicit +1. From drc@virtualized.org Sun Apr 15 14:07:24 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D4721F8639 for ; Sun, 15 Apr 2012 14:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYcBvX6MeF9C for ; Sun, 15 Apr 2012 14:07:23 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7C08121F8693 for ; Sun, 15 Apr 2012 14:07:23 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 7721C1705A; Sun, 15 Apr 2012 21:07:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4F8B2BA9.1050603@redbarn.org> Date: Sun, 15 Apr 2012 14:07:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu><9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU><536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se><4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 21:07:24 -0000 Paul, On Apr 15, 2012, at 1:12 PM, Paul Vixie wrote: >> I thought we'd learned that flag day deployments don't work on the = Internet anymore. > i thought so too until we had "world ipv6 day" last year.=20 I'm not sure how world IPv6 day changes anything. It's not like IPv6 saw = a significant (relative to IPv4) increase in usage. > i seek to avoid legitimizing the aaaa "igor hack" in bind9, and = negative trust anchors. My impression is that what is being proposed is standardizing on the = moral equivalent of a manual version of happy eyeballs (is that the = "igor hack"?). I suspect the only way we're going to see real deployment = of DNSSEC validation is if we make it essentially transparent to end = users which is what I see happy eyeballs doing. Like IPv6 with happy = eyeballs, the implication of new technology failure is to transparently = fall back to (working) old technology. Unlike IPv6 with happy eyeballs, = DNSSEC with NTA has security implications. I would imagine those = security implications will be an incentive not to deploy unless there is = no real alternative (and to remove as soon as possible), so I can't get = too worked up about the abuse of the architecture. I guess in the end it boils down to the philosophical question of the = role of the IETF. If DNSOP declines to accept this topic, I suspect it = merely means each vendor will come up with their own implementation with = their own quirks that operators will have to wade through. I fail to see = how this improves anything. Regards, -drc From i.grok@comcast.net Sun Apr 15 17:02:42 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5B21F88CD for ; Sun, 15 Apr 2012 17:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60DTMRtsgk-X for ; Sun, 15 Apr 2012 17:02:42 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by ietfa.amsl.com (Postfix) with ESMTP id 16ABD21F88CC for ; Sun, 15 Apr 2012 17:02:42 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta07.emeryville.ca.mail.comcast.net with comcast id yPCT1i0031u4NiLA7Q2h5g; Mon, 16 Apr 2012 00:02:41 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.emeryville.ca.mail.comcast.net with comcast id yQ2g1i01B00PQ6U8hQ2hxi; Mon, 16 Apr 2012 00:02:41 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q3G02dXN022030 for ; Sun, 15 Apr 2012 20:02:39 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q3G02dl3022029 for dnsop@ietf.org; Sun, 15 Apr 2012 20:02:39 -0400 Date: Sun, 15 Apr 2012 20:02:39 -0400 From: Scott Schmit To: dnsop@ietf.org Message-ID: <20120416000239.GA21739@odin.ulthar.us> Mail-Followup-To: dnsop@ietf.org References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 00:02:42 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 13, 2012 at 04:38:10PM -0700, David Conrad wrote: > On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote: > >> More pragmatically, while I understand the theory behind rejecting NTA= s, > >> I have to admit it feels a bit like the IETF rejecting NATs and/or DNS > >> redirection. I would be surprised if folks who implement NTAs will stop > >> using them if they are not accepted by the IETF. > >>=20 > > it is still not a reason for the IETF to standardize this. >=20 > With the implication that multiple vendors go and implement the same > thing in incompatible ways. I always get a headache when this sort of > thing happens as the increased operational costs of non-interoperable > implementations usually seems more damaging to me than violations of > architectural purity. Different perspectives I guess. What's to standardize (or be incompatible)? Each recursive resolver already has different mechanisms for configuring it, and I'd imagine that the list of NTAs would be configured similarly to (for example) its TAs & DLVs. If you're thinking of some kind of DLNV (similar to the DNS-based spam blacklists), then there's something to talk about, but in that case I'd want it to be secured via DNSSEC, and let's hope the operators of those don't screw up or start blacklisting each other. (Either on purpose or due to unfortunate timing.) Attacking DLNV zones would have a nice amplifying effect, too, if the need for them is widespread enough to be worth standardizing. --=20 Scott Schmit --bp/iNruPH9dso1Pn Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNDE2MDAwMjM5WjAjBgkqhkiG9w0BCQQxFgQUshOiDHJz S1BMNZEaizEklGXBXlMweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAE2bI1HMV dKtBShvWnsFKYYnvTE5j2y51e/kcOCSGbhjlucKz57G6XcA+tpLbtZEvf7PKp/dLhk4vgiIX z1ysUhedbiAjxcOcrKN46Py+jYiKR5qQZsfb3NHwWZxMLSzsBGfiv7tdCyWKRy91ytlFHV95 DK/UMLr2rspdp4GcDSgV40LoIeBTv5SjGivR4DcBaprHv14/NE2p7hYZ7qmDdC+IguVmAAzj xD2ig9YKn603Bgb68Hq6PHD00ZmJu1XI/VrVUmoS8dESDzDl8AqFx/ZkgF/jlujbixclllWh uXRc0GOzitkQ/SaBScAjgK71xH7dDNP8PWN5pvxKKqRUTA== --bp/iNruPH9dso1Pn-- From i.grok@comcast.net Sun Apr 15 18:28:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F3821F88F9 for ; Sun, 15 Apr 2012 18:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-QRKQpqCkbx for ; Sun, 15 Apr 2012 18:28:08 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3C721F88F8 for ; Sun, 15 Apr 2012 18:28:08 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta02.emeryville.ca.mail.comcast.net with comcast id yRRG1i0010S2fkCA2RU8Lf; Mon, 16 Apr 2012 01:28:08 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta09.emeryville.ca.mail.comcast.net with comcast id yRU61i00S00PQ6U8VRU73c; Mon, 16 Apr 2012 01:28:07 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q3G1S4wC022198 for ; Sun, 15 Apr 2012 21:28:04 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q3G1S4X3022197 for dnsop@ietf.org; Sun, 15 Apr 2012 21:28:04 -0400 Date: Sun, 15 Apr 2012 21:28:04 -0400 From: Scott Schmit To: dnsop@ietf.org Message-ID: <20120416012804.GB21739@odin.ulthar.us> Mail-Followup-To: dnsop@ietf.org References: <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 01:28:08 -0000 --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2012 at 02:07:20PM -0700, David Conrad wrote: > On Apr 15, 2012, at 1:12 PM, Paul Vixie wrote: > > i seek to avoid legitimizing the aaaa "igor hack" in bind9, and > > negative trust anchors. >=20 > My impression is that what is being proposed is standardizing on the > moral equivalent of a manual version of happy eyeballs (is that the > "igor hack"?). It's manual for now...until the utter lack of consequences for screwing up (everybody can still get to the broken zones just fine) junks up the NTA lists. As the failures start to build up, what's to keep operators =66rom responding to these much like most users respond to browser SSL validation failures? Eventually it'll become automatic, and then it'll be automated. Once that happens, you may as well turn it off. I suppose we could add heuristics, but then debugging will be even more difficult, because different validators will have different heuristics (and there will be no transparency as to what they are). And if we could standardize the heuristics to some reasonably secure set, they'd be part of DNSSEC! I admit, there are certainly some disturbing parallels to the IPv6 transition--but one difference in this case is that it's pretty clear who is at fault when things go wrong. That is, until validators start trying to "fix" things, and get it wrong (not saying that that's happened so far, but give it time...). > I guess in the end it boils down to the philosophical question of the > role of the IETF. If DNSOP declines to accept this topic, I suspect it > merely means each vendor will come up with their own implementation > with their own quirks that operators will have to wade through. I fail > to see how this improves anything. I suppose one way we could go is to mix this with the NXDOMAIN interception/typo "correction"/captive portal mechanism: If the resolver is unable to validate the domain, it MAY return a false result leading the user to a host that will explain the error and how to notify the domain owner of the problem. If operators decide to do this, the implementation MUST make it possible for the chosen notification mechanism to get through. The host SHOULD be able to notify users who are not attempting to connect to the site via HTTP/HTTPS. End result? If your domain is insecure, it's as it was pre-DNSSEC. If your domain is secure, all is well. If your domain is bogus, the ISP gets a chance to tell the user what went wrong and why, and how to complain to the people that caused the problem in the first place. If the user is validating the results themselves, they don't see the ISP page, but all DNS resolvers look the same to them (i.e., switching to 8.8.8.8 won't fix it) so they'll eventually realize its their own machine, etc. I'm not entirely sure I like that solution, but I think I like it better. --=20 Scott Schmit --wq9mPyueHGvFACwf Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNDE2MDEyODA0WjAjBgkqhkiG9w0BCQQxFgQU701nahgD DtInXXhR2QeRg+gIajgweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAadeiDwUh FrqS+fMuX9ikUoaAIwjdPgEd1uIq9aZnEMkYPvskxf/APYs9vVGIussGDNn02SWwm+xqKMgL 0+4a/CXE7vAe2X1dgvxWD80zdFpnacYJRdcL5+YZuzu/Ww6ZkvJlCZzNSs/7rtBmrjRSWe3Y u2MNRvYoopXXvCKvY5sIk8HmiqFx8xnA5GZrfwPjPEzxRU0fddWbmulrbXJ1kHZ81vuigse5 Wg2CXkprP+ce79rXWjdcE2pVnCkg/oosPRp3Z7dxWqB30H5ki/vrJsg7s+HtCDqhkLYDjeh+ evoUTL+Z6KzMdnFdtau93ihNiq7ifXEBcZefJY7t9At+JA== --wq9mPyueHGvFACwf-- From Ralf.Weber@nominum.com Sun Apr 15 21:03:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BED521F8743 for ; Sun, 15 Apr 2012 21:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fynd248mGfSk for ; Sun, 15 Apr 2012 21:03:31 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 5426921F86D5 for ; Sun, 15 Apr 2012 21:03:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT4uaEaobD0seAzXTj049Iy880cP2L+kD@postini.com; Sun, 15 Apr 2012 21:03:31 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A46381B83A4 for ; Sun, 15 Apr 2012 21:03:28 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 97F0219006C for ; Sun, 15 Apr 2012 21:03:28 -0700 (PDT) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sun, 15 Apr 2012 21:03:28 -0700 From: Ralf Weber To: dnsop Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: AQHNG4XgYsRYAd2Muk+tjlLa6R3E+Q== Date: Mon, 16 Apr 2012 04:03:27 +0000 Message-ID: <71DFDCAC-C4B7-46E9-B178-F5BF6D853BEF@nominum.com> References: <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <20120416012804.GB21739@odin.ulthar.us> In-Reply-To: <20120416012804.GB21739@odin.ulthar.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <9CBF1CB9B3738D4B93D7BA8C47F668A9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 04:03:32 -0000 Moin! Not to answer anyone specific, as a lot of people seemed to spend their wee= kend commenting on this and I don't want to increase the incoming mail fold= ers too much. In general I agree with what David Conrad said, but want to spare you of a = couple of +1 mails and just want to add some remarks. We are still talking about the draft submitted by Jason Livingood which jus= t describes negative trust anchors which are available in validators today.= We are not talking about creating a list or technology to distribute negat= ive trust anchors, although this may be an idea at least as good as DLV. The current use case for DNSSEC is protection of cache poisoning for resolv= ers (been there and therefore want DNSSEC), and while there is a great pote= ntial for security applications using DNSSEC once it is widely deployed, we= need to have that deployment first and that will not happen in one day, bu= t rather will be a gradual rollout when looked at it from a global perspect= ive, or even within regional markets. So operators rolling out DNSSEC alway= s will be in competition with operators who don't have it. And the average = end user will never understand the difference between the two, no matter ho= w good you market it. He will only understand I can get there with X and ca= n't get there with Y. Which means that in order to not loose customers operators have to install = procedures for dealing with failures and if the procedure is turn it off co= mpletely and this happens a couple of time upper management will ask why a = technology that has to been turned off from time to time and does work when= turned off is needed at all. And turning it off completely will get more m= anagement attention than deploying a NTA for just a failed domain especiall= y if there is a worked out process in operations. If I look at what failures have happened during DNSSEC deployment, which gr= anted is early, but so far also mostly done by professionals earning there = money with DNS software or services I see the following (I'm not claiming t= his list is complete): - TLD failures more than once - Interoperability problems - Different interpretations of RFCs - Different levels of liberalism in what to accept - some public visible domains failing I don't believe that further deployment will be without errors, and as said= a lot of times the cost of these errors will be on the validator operators= . So in order to get them to deploy DNSSEC we have to give them tools to de= al with errors. If the IETF or this group wants to ignore these operational facts and not g= ive new people guidance on how to deal with them, and do nothing is not an = acceptable advise here, I doubt that a lot of people will adopt DNSSEC or m= ove back after the first or second failure and that would not the be outcom= e I would want. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From paul@redbarn.org Sun Apr 15 21:05:57 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D1221F8899 for ; Sun, 15 Apr 2012 21:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4rm8on7I3pt for ; Sun, 15 Apr 2012 21:05:57 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 32CBA21F86D5 for ; Sun, 15 Apr 2012 21:05:57 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:9469:a947:eb2:af46] (unknown [IPv6:2001:559:8000:cb:9469:a947:eb2:af46]) by ss.vix.com (Postfix) with ESMTP id EA30FEDFCE; Mon, 16 Apr 2012 04:05:56 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F8B9AA4.2080000@redbarn.org> Date: Mon, 16 Apr 2012 04:05:56 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: David Conrad References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu><9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU><536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se><4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 04:05:57 -0000 On 2012-04-15 9:07 PM, David Conrad wrote: > I guess in the end it boils down to the philosophical question of the > role of the IETF. If DNSOP declines to accept this topic, I suspect it > merely means each vendor will come up with their own implementation > with their own quirks that operators will have to wade through. I fail > to see how this improves anything. if you don't want something to live forever and get turned on by default or left on across sysadmin churn, don't put it in an RFC. From drc@virtualized.org Sun Apr 15 21:14:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82C21F8800 for ; Sun, 15 Apr 2012 21:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXzQXo6L56Wm for ; Sun, 15 Apr 2012 21:14:07 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 990FF21F87FB for ; Sun, 15 Apr 2012 21:14:07 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id D83AE1705A; Mon, 16 Apr 2012 04:14:05 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4F8B9AA4.2080000@redbarn.org> Date: Sun, 15 Apr 2012 21:14:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <575A95AA-A654-4671-8833-8D3E02023B55@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com><4F8851CF.2020807@dougbarton.us><4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org><6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu><9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU><536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se><4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <4F8B9AA4.2080000@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 04:14:08 -0000 On Apr 15, 2012, at 9:05 PM, Paul Vixie wrote: > if you don't want something to live forever and get turned on by = default > or left on across sysadmin churn, don't put it in an RFC. Weren't we talking about requiring an explicit lifetime on NTAs? I'd be = all for "SHOULDs"/"MUSTs" that increase the touch factor to ensure = people pull NTAs instead of letting them ossify. =20 Regards, -drc From drc@virtualized.org Sun Apr 15 21:24:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0221F87FF for ; Sun, 15 Apr 2012 21:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRsZ1Gws3mUE for ; Sun, 15 Apr 2012 21:24:37 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2920621F87F7 for ; Sun, 15 Apr 2012 21:24:37 -0700 (PDT) Received: from [10.0.1.3] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 932691705A; Mon, 16 Apr 2012 04:24:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20120416012804.GB21739@odin.ulthar.us> Date: Sun, 15 Apr 2012 21:24:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9DCA9614-A9C7-4722-9859-35A835078193@virtualized.org> References: <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <20120416012804.GB21739@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 04:24:37 -0000 Scott, On Apr 15, 2012, at 6:28 PM, Scott Schmit wrote: > It's manual for now...until the utter lack of consequences for = screwing > up (everybody can still get to the broken zones just fine) junks up = the > NTA lists. =20 Given the implicit assertions associated with NTA (specifically, that = the validator operator is asserting that the zone in question is not = being spoofed despite the fact that validation is failing), I have some = skepticism that folks will let stuff like this 'junk up NTA lists'. > If the resolver is unable to validate the domain, it MAY return a = false > result leading the user to a host that will explain the error and how = to > notify the domain owner of the problem. Not sure I follow -- are you proposing additional error codes in stub = resolver responses? Regards, -drc From sm@resistor.net Mon Apr 16 03:36:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA9621F8714 for ; Mon, 16 Apr 2012 03:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPVpThce22Wr for ; Mon, 16 Apr 2012 03:36:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B417221F8709 for ; Mon, 16 Apr 2012 03:36:30 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3GAaOVf005501; Mon, 16 Apr 2012 03:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334572590; i=@resistor.net; bh=SGx0cyEk7gvq+9x+GmHR2XK2QeNiEehgA4cNxoUuzC0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CeUhaiqsdXkY1npa1O2OnK4wTes1Q5sRitLh+4f+yyJIeKKErvmjwDjtP7rKHlMcm mcxBLeBlbEvKhSsWQvCLfkxrtzc7oou6XPCvIT0g5/uAQM1ujpZ7nyGELZ8OigYsQ7 gxLhwKUxmz5MbSaAMMaBaU95x0Ae1ScGMczBBb8c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334572590; i=@resistor.net; bh=SGx0cyEk7gvq+9x+GmHR2XK2QeNiEehgA4cNxoUuzC0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EkHqYb5hByf7h0VLPMqUURFCDVs+fNrMX6uBroGY6Guc/YRnH3xpkqKw9wFM/xYyp M5+UsrhmOJGf5/0ctiEUmbfnvhlspJAXhRKt3UDQ3MKj+KlqJbmH6hrfy5vn1sPSYx Wprn/V62JG9ZjlPiR5X9Q2EbP/qtQcg4sqGR1EaA= Message-Id: <6.2.5.6.2.20120416020446.0946a9c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Apr 2012 03:01:57 -0700 To: dnsop@ietf.org From: SM In-Reply-To: <71DFDCAC-C4B7-46E9-B178-F5BF6D853BEF@nominum.com> References: <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <20120416012804.GB21739@odin.ulthar.us> <71DFDCAC-C4B7-46E9-B178-F5BF6D853BEF@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ralf Weber Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:36:35 -0000 At 21:03 15-04-2012, Ralf Weber wrote: >If the IETF or this group wants to ignore these operational facts >and not give new people guidance on how to deal with them, and do >nothing is not an acceptable advise here, I doubt that a lot of >people will adopt DNSSEC or move back after the first or second >failure and that would not the be outcome I would want. From draft-livingood-negative-trust-anchors-01: "A Negative Trust Anchor should be considered a transitional and temporary tactic which is not particularly scalable and should not be used in the long-term. Over time, however, the use of Negative Trust Anchors will become less necessary as DNSSEC-related domain administration becomes more resilient." The parallel here would be draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11. The significant difference is that it is not about a technological choice. There are different angles to the problem discussed in draft-livingood-negative-trust-anchors-01. I could look at it as follows: A Negative Trust Anchor should be considered even though the tactic is not particularly scalable. Regards, -sm From i.grok@comcast.net Mon Apr 16 04:52:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67921F85FD for ; Mon, 16 Apr 2012 04:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2wSJORFfzQn for ; Mon, 16 Apr 2012 04:52:36 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 63D1D21F8671 for ; Mon, 16 Apr 2012 04:52:36 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id ybPU1i00427AodY5Dbscmr; Mon, 16 Apr 2012 11:52:36 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta19.westchester.pa.mail.comcast.net with comcast id ybsc1i00h00PQ6U3fbscmZ; Mon, 16 Apr 2012 11:52:36 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q3GBqXIH031763 for ; Mon, 16 Apr 2012 07:52:33 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q3GBqXf7031762 for dnsop@ietf.org; Mon, 16 Apr 2012 07:52:33 -0400 Date: Mon, 16 Apr 2012 07:52:33 -0400 From: Scott Schmit To: dnsop@ietf.org Message-ID: <20120416115232.GA30983@odin.ulthar.us> Mail-Followup-To: dnsop@ietf.org References: <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <20120416012804.GB21739@odin.ulthar.us> <9DCA9614-A9C7-4722-9859-35A835078193@virtualized.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <9DCA9614-A9C7-4722-9859-35A835078193@virtualized.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 11:52:37 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2012 at 09:24:35PM -0700, David Conrad wrote: > On Apr 15, 2012, at 6:28 PM, Scott Schmit wrote: > > It's manual for now...until the utter lack of consequences for screwing > > up (everybody can still get to the broken zones just fine) junks up the > > NTA lists. =20 >=20 > Given the implicit assertions associated with NTA (specifically, that > the validator operator is asserting that the zone in question is not > being spoofed despite the fact that validation is failing), I have > some skepticism that folks will let stuff like this 'junk up NTA > lists'. Please explain how operators will prevent this, and why they can afford to remove a zone from the NTA list (while it is still failing) but couldn't afford to leave it off the list in the first place. > > If the resolver is unable to validate the domain, it MAY return a false > > result leading the user to a host that will explain the error and how to > > notify the domain owner of the problem. >=20 > Not sure I follow -- are you proposing additional error codes in stub > resolver responses? No, I'm talking about a targeted use of the controversial practice of returning spoofed results redirecting the user to another host. Since the usual protocol in use is HTTP or HTTPS, that host presents a web page with the desired content (usually a search page with embedded ads, or a portal page requesting payment and/or providing terms of use that must be accepted before continuing). It may be possible to provide application-level error messages for other protocols to be served by that host in support of non-HTTP/HTTPS traffic (email bounces, etc). In this case, the page would educate the user that there's something wrong with the site, and offer a way to let the user let the site know about the problem. This shifts the perception of brokenness back toward the site causing the problem (or at least attempts to). If desired, one could also go the captive portal route and let the user through after they've seen/acknowledged the error page (for some amount of time). References: https://en.wikipedia.org/wiki/DNS_hijacking https://en.wikipedia.org/wiki/Captive_portal --=20 Scott Schmit --n8g4imXOkfNTN/H1 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNDE2MTE1MjMyWjAjBgkqhkiG9w0BCQQxFgQUfVDWRZ5H nDbOxgFZ03eMOsv1KbYweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAKLM7HOOJ wUJ/7+RYDSsbOj+z8IgATdRhLOmgVIUYMaUX6Yye4Dk1uIvzPGD48F4XCATxtcnUWN117Mb3 7oObxRn8rrceaAmF12R66iKLschqSu3dAO8TlhZVEhUT63/PUGr2LYmtjRw4K3xRCLKwfnvW RYZBuU6Sv3u8fpgxWiphYl0Ib58kpKpFP35pvEfR+Nx9vJLTOQhGA76aytfxcZ53ZCFHa6zM AwTwBXfU30R7GQBhPQRQLlkJ0zhAkKpHzrzYL/24u5TpzC/e5D4uWV/wMN97b1juYDe+DPjo dq7gFS9VrDFAbfGLAk+G6BLdmrtcD5y8r/jGr+HvFAcL5A== --n8g4imXOkfNTN/H1-- From drc@virtualized.org Mon Apr 16 09:41:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859B711E80BB for ; Mon, 16 Apr 2012 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d058ahY2eGX2 for ; Mon, 16 Apr 2012 09:41:39 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id C6F4C11E80B6 for ; Mon, 16 Apr 2012 09:41:39 -0700 (PDT) Received: from [192.168.2.168] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 8258C1705A; Mon, 16 Apr 2012 16:41:34 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20120416115232.GA30983@odin.ulthar.us> Date: Mon, 16 Apr 2012 08:32:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <20120416012804.GB21739@odin.ulthar.us> <9DCA9614-A9C7-4722-9859-35A835078193@virtualized.org> <20120416115232.GA30983@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:41:40 -0000 Scott, On Apr 16, 2012, at 4:52 AM, Scott Schmit wrote: >> Given the implicit assertions associated with NTA (specifically, that >> the validator operator is asserting that the zone in question is not >> being spoofed despite the fact that validation is failing), I have >> some skepticism that folks will let stuff like this 'junk up NTA >> lists'. >=20 > Please explain how operators will prevent this, and why they can = afford > to remove a zone from the NTA list (while it is still failing) but > couldn't afford to leave it off the list in the first place. I would assume operators will keep NTAs alive until the zone owner fixes = things.=20 You appear to be assuming zone owners will leave brokenness in place. In = the case of popular zones (which would be the most likely candidates for = NTAs since end users would notice the brokenness and complain to the = validator operator), I'd imagine there would be some pressure to fix = things, either by pulling the DS or by remedying whatever booboo caused = the problem to begin with. My impression is that those who are arguing = against NTAs believe that NTAs reduce that pressure. I'd agree with = this to some extent, however I suspect because of the indirect nature of = the failures, the vast majority of complaints the zone owner will = receive will come from validator operators, not end users. > No, I'm talking about a targeted use of the controversial practice of > returning spoofed results redirecting the user to another host.=20 An interesting idea, albeit I'm actually unsure which is less appealing = architecturally speaking. For others against NTAs, is the use of = redirection as Scott suggests preferable? Regards, -drc From joe.abley@icann.org Mon Apr 16 09:55:39 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DC611E80DC for ; Mon, 16 Apr 2012 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkXo3Uk52Nlo for ; Mon, 16 Apr 2012 09:55:38 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7611E80DB for ; Mon, 16 Apr 2012 09:55:38 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 16 Apr 2012 09:55:37 -0700 From: Joe Abley To: Scott Schmit Date: Mon, 16 Apr 2012 09:55:37 -0700 Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0b8b94a5Hqbz5jRXyX0FO0iq+iRA== Message-ID: <806B7B7C-40FE-4A5F-8670-795B8743704E@icann.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> <330B3041-59E0-49F6-ADCF-01CD66D799DA@virtualized.org> <201204132230.q3DMUPx9056051@bartok.nlnetlabs.nl> <5DA9F819-F527-4FE7-80CF-4B64B2C033BF@virtualized.org> <20120416000239.GA21739@odin.ulthar.us> In-Reply-To: <20120416000239.GA21739@odin.ulthar.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_4381AC6A-20D3-440D-87A1-EAA15F1E3B87"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:55:39 -0000 --Apple-Mail=_4381AC6A-20D3-440D-87A1-EAA15F1E3B87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2012-04-15, at 20:02, Scott Schmit wrote: > On Fri, Apr 13, 2012 at 04:38:10PM -0700, David Conrad wrote: >> On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote: >>>> More pragmatically, while I understand the theory behind rejecting = NTAs, >>>> I have to admit it feels a bit like the IETF rejecting NATs and/or = DNS >>>> redirection. I would be surprised if folks who implement NTAs will = stop >>>> using them if they are not accepted by the IETF. >>>>=20 >>> it is still not a reason for the IETF to standardize this. >>=20 >> With the implication that multiple vendors go and implement the same >> thing in incompatible ways. I always get a headache when this sort of >> thing happens as the increased operational costs of non-interoperable >> implementations usually seems more damaging to me than violations of >> architectural purity. Different perspectives I guess. >=20 > What's to standardize (or be incompatible)? Details like: - what data ought to be recorded with the NTA (e.g. reason, = instantiation timestamp, expiration timestamp) - whether other available trust anchors to domains under an NTA should = also be invalidated - whether there ought to be any signalling to a client to let them know = that they're getting an answer despite a validation failure > Each recursive resolver > already has different mechanisms for configuring it, and I'd imagine > that the list of NTAs would be configured similarly to (for example) > its TAs & DLVs. - if NTAs were to be published as RRs, a bit like DLV - what RRs should be used? - should NTAs read from the DNS be cached? - are there requirements that the zone data be signed? I think there's more to standardise here than you think. It's not that = any of this is hard; it's just that it'd be so much less pain = operationally if everybody's validator was configured along similar = lines. If we did it right I can imagine subscription services for ISPs = run by reliable people that ISPs could opt-in to in order to get an = automatic whitelist. (Look at that! I just made all the security people = on this list bang their fists on the table.) Clients are very touchy about the performance of the caches they use. I = have some dealings with a large (i.e. tiny by comparison with Comcast) = residential ISP here in Canada, and I've seen first-hand the dramatic = traffic shifts from the ISP-operated resolvers to OpenDNS and Google DNS = if the ISP caches ever malfunction. Comcast's experience (as I heard = about it in Teddington) rang very true -- unless you have the ops to = mitigate signing failures, there is no way in hell you should validate = in your cache. Another thought from Teddington via Paris: if Comcast hadn't whitelisted = NZ during the period when the NZ zone was tripping validation failures = on CNS due to the BAABAA encoding oddity, there would have been a whole = country's worth of content off the air to Comcast customers for a = prolonged period. Someone might argue that the right thing to do was to = suppress resolution of all names under NZ for reasons of architectural = purity, but I would have a hard time agreeing with them (and I doubt = they'd find many kindred spirits amongst kiwi expats living in Comcast = service areas). (And as I hope is obvious, even to those who didn't see Sebastian's talk = about it, the NZ people actually know what they're doing. DNSSEC = amateurs who are just blindly clicking "sign" have no hope. And most of = the DNS isn't even signed -- the longer and wrigglier the entrails of = trust become, the bigger problem this is, and I don't think it's = necessarily the case that more deployment of signatures in the namespace = will make things more reliable.) I understand the reluctance to appear to sanction selective tolerance of = validation failures -- from a security perspective it's ugly, it muddies = the whole DNSSEC message, it smacks of "click OK to continue" = certificate failures. But I do not see how we can expect validation in = the cache to ever make sense to ISPs in any general, pervasive sense = without some mechanism to mitigate signing failures. And if there's a = mechanism, I think it should be standardised. If all that sounds horrible, then the alternative is to issue new = guidance that nobody expects caches to do validation anyway, ever, and = that validation properly belongs in or near the application, on hosts. = Reduce the advice to ISPs that they should make sure they can receive = and generate large responses reliably and respond properly to clients = that are willing and able to do their own validation. Re-point the = energy currently directed at ISPs to Microsoft, Apple, Google and = Mozilla. That way the practical problems surrounding the use of a remote = validator (the support cost of validation, the lack of benefit from = validation from the perspective of the na=EFve end-user, the unfortunate = user comparisons between a BROKEN! validating ISP and a WORKING! = non-validating one next door, dealing with NTAs/whitelists/whatever, the = direction of the user's anger when broken zones fail to validate, the = unsecured channel between the client and the cache) all disappear. Joe --Apple-Mail=_4381AC6A-20D3-440D-87A1-EAA15F1E3B87 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNDE2MDIwNjEzWjAjBgkqhkiG9w0BCQQxFgQUcZuSuBGGWXCBt4fiCwTk0IxlsQwwgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB AEwiFrRueQDNmV7QbcRH+ID9aSNK96dajudz+FwxX/z4EyCjaqpwNG3di0p9gfUlxYIKO2qieCJ/ T+YQZ3whEExa1mZHQKQiZotK5TTbCuylyvmCzUiK7sSwl+Zc9P3MZWtWLD9dI9xTBKDxVx1Kv+r9 QTBMrd4bpXJwKemUDpdIgVr2Y2B2Oen3t1pc9tvQj2YApnW+nUNXd3QhTvpqBa+PBQBccoEs60IC U/eYgUca48J5Hv9o/sJ05s0fBTGj9TC0UiQQPc15bSr5PrUR+V1Dje9nSCnRPXOfWudleqWDx00W wfrusvgc5p/ngvAjmG9R8ENPlkMHGyvnypb8WVsAAAAAAAA= --Apple-Mail=_4381AC6A-20D3-440D-87A1-EAA15F1E3B87-- From jason_livingood@cable.comcast.com Mon Apr 16 10:13:22 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4700E21F8629 for ; Mon, 16 Apr 2012 10:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.23 X-Spam-Level: X-Spam-Status: No, score=-101.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8UKD3VbmG3i for ; Mon, 16 Apr 2012 10:13:21 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF9A21F861F for ; Mon, 16 Apr 2012 10:13:21 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.13551139; Mon, 16 Apr 2012 10:59:57 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 13:13:16 -0400 From: "Livingood, Jason" To: dnsop Thread-Topic: re Many Comments on Negative Trust Anchor I-D (back from vacation) Thread-Index: AQHNG/Q2ifbFWP4KKkqkaNjy2Yc49g== Date: Mon, 16 Apr 2012 17:13:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CBB1CB6D597D2jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [DNSOP] re Many Comments on Negative Trust Anchor I-D (back from vacation) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:13:22 -0000 --_000_CBB1CB6D597D2jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am an author of the document and am just back from vacation today. I will= start to read and respond to the many emails now =96 did not want anyone t= o think I was ignoring the discussion. :-) Jason --_000_CBB1CB6D597D2jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7D7899C734629C45AB8E2D4FF85E244D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
I am an author of the document and am just back from vacation today. I= will start to read and respond to the many emails now =96 did not want any= one to think I was ignoring the discussion. :-)

Jason 
--_000_CBB1CB6D597D2jasonlivingoodcablecomcastcom_-- From paf@frobbit.se Mon Apr 16 10:27:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69D921F85B5 for ; Mon, 16 Apr 2012 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3LPcclptw11 for ; Mon, 16 Apr 2012 10:27:27 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 57EBE21F8663 for ; Mon, 16 Apr 2012 10:27:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 55CE01392F588; Mon, 16 Apr 2012 19:27:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRlw7bdyL20H; Mon, 16 Apr 2012 19:27:23 +0200 (CEST) Received: from [10.19.19.153] (unknown [62.205.104.254]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id A0ABD1392F582; Mon, 16 Apr 2012 19:27:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 16 Apr 2012 19:26:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <31B2931C-B763-497F-B407-ECA0AB5A8A5C@frobbit.se> References: To: "Livingood, Jason" X-Mailer: Apple Mail (2.1257) Cc: dnsop Subject: Re: [DNSOP] re Many Comments on Negative Trust Anchor I-D (back from vacation) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:27:28 -0000 On 16 apr 2012, at 19:13, Livingood, Jason wrote: > am just back from vacation today I am sorry...returning to "this"... :-P Patrik From jason_livingood@cable.comcast.com Mon Apr 16 10:28:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F73821F8685 for ; Mon, 16 Apr 2012 10:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.231 X-Spam-Level: X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqxIz4TCJNNp for ; Mon, 16 Apr 2012 10:28:36 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 88A0E21F8663 for ; Mon, 16 Apr 2012 10:28:36 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.13554849; Mon, 16 Apr 2012 11:15:15 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 13:28:34 -0400 From: "Livingood, Jason" To: Shane Kerr Thread-Topic: Limiting duration for Negative Trust Anchors, was Re: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5Z9oZ0AgACNQoCAACFqAIAAV/YAgBXK1ACACWNTAA== Date: Mon, 16 Apr 2012 17:28:33 +0000 Message-ID: In-Reply-To: <20120410160644.457bc56b@shane-eeepc.home.time-travellers.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop Subject: Re: [DNSOP] Limiting duration for Negative Trust Anchors, was Re: New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:28:37 -0000 Inline below. - JL On 4/10/12 10:06 AM, "Shane Kerr" wrote: >Jason, > >On Tuesday, 2012-03-27 15:19:23 +0000, >"Livingood, Jason" wrote: >> I posted a =AD01 a short time ago >> (http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01) >> and listed this in open items for the next version. I may have some >> questions on the best way to include that. > >I like this idea; it was something I planned on including in BIND 10 >for a while, although we've got other higher-priority things to add >first (like DNSSEC validation). ;) > >One tiny bit: > > Furthermore, a Negative Trust Anchor should be used only for a short > duration, perhaps for a day or less. > > >While for larger ISPs a top-100 approach makes sense, and so a 1 day fix >is reasonable to expect, other operators will have other concerns. For >example, you may have a distributor for your business that has a crappy >IT department and simply can't get their zones fixed in a reasonable >time, or you may have a department at your university that is literally >gone for the summer. This is indeed an issue we have observed. Here are some recent examples where we've not seen a 1 or 2 day resolution: http://dnsviz.net/d/www.bayfieldelectric.com/T4wofg/dnssec/ http://dnsviz.net/d/www.bayfieldelectric.com/T4wofg/dnssec/ >The approach I had planned on taking is simply to require that an >administrator specify the ending time of the Negative Trust Anchor. If >they want to, of course they can put 30 years (or perhaps however much >time is left until their retirement), but at least they would have had >to think about the issue! I think that is a great approach! And perhaps have a default TTL in there for the NTA of X hours. - Jason From jason_livingood@cable.comcast.com Mon Apr 16 10:31:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98C621F86A4 for ; Mon, 16 Apr 2012 10:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.231 X-Spam-Level: X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QTkU5if9fLl for ; Mon, 16 Apr 2012 10:31:07 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55F21F86A1 for ; Mon, 16 Apr 2012 10:31:07 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.13555421; Mon, 16 Apr 2012 11:17:45 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 13:31:04 -0400 From: "Livingood, Jason" To: Shane Kerr Thread-Topic: [DNSOP] Limiting duration for Negative Trust Anchors, was Re: New I-D on Negative Trust Anchors Thread-Index: AQHNG/ayjADaUkeTNkaBWLVnXSsYtQ== Date: Mon, 16 Apr 2012 17:31:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <87DC0957D1D21D428B21CF13E624FA24@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop Subject: Re: [DNSOP] Limiting duration for Negative Trust Anchors, was Re: New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:31:08 -0000 Had a double copy & paste error! Here is the 2nd domain: http://dnsviz.net/d/www.bitcoinica.com/T4pqsA/dnssec/ >http://dnsviz.net/d/www.bayfieldelectric.com/T4wofg/dnssec/ > > >http://dnsviz.net/d/www.bayfieldelectric.com/T4wofg/dnssec/ > From jason_livingood@cable.comcast.com Mon Apr 16 10:41:34 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3DC11E80AB for ; Mon, 16 Apr 2012 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.064 X-Spam-Level: X-Spam-Status: No, score=-101.064 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTzFQf1pYw9c for ; Mon, 16 Apr 2012 10:41:33 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7594D11E809C for ; Mon, 16 Apr 2012 10:41:33 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.9394360; Mon, 16 Apr 2012 13:32:46 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 13:39:39 -0400 From: "Livingood, Jason" Thread-Topic: on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDADUScOA Date: Mon, 16 Apr 2012 17:39:37 +0000 Message-ID: In-Reply-To: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Marc Lampo , dnsop Cc: "ralf.weber@nominum.com" , Nick Weaver Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:41:34 -0000 Inline. - JL On 4/12/12 8:21 AM, "Marc Lampo" wrote: >The draft of Negative Trust Anchors does not mention anything about >informing the operator of the failing domain. I'll make a note to call this out in the next version. Something about making reasonable attempts to notify the domain of the issue and any action taken (such a using a NTA and when it expires, how to contact party adding the NTA, etc.). >The advantage over negative trust anchor would be that this is more >centrally managed : the action by the parent (remove DS) is visible (TTL >permitted) to any validating name server. > (the negative trust anchor needs to be configured by every validating NS, > whose administrators bother to do so) I see the advantages but I'm reluctant to see this more automated / easy. Thanks, Jason From jason_livingood@cable.comcast.com Mon Apr 16 10:53:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD87B21F8771 for ; Mon, 16 Apr 2012 10:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.022 X-Spam-Level: X-Spam-Status: No, score=-101.022 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W+bc9MfbpqP for ; Mon, 16 Apr 2012 10:53:05 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 22BCF21F8762 for ; Mon, 16 Apr 2012 10:53:05 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.9397033; Mon, 16 Apr 2012 13:45:39 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 13:52:30 -0400 From: "Livingood, Jason" To: Tony Finch , "Griffiths, Chris" Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5aU2PUogABrvICAAMNrgIAH1PuA Date: Mon, 16 Apr 2012 17:52:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop , Wes Hardaker Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:53:05 -0000 Inline On 4/11/12 10:16 AM, "Tony Finch" wrote: >Griffiths, Chris wrote: >> On Apr 10, 2012, at 8:11 PM, Wes Hardaker wrote: >> >> > Suggested rewrite: >> > >> > Furthermore, a Negative Trust Anchor MUST only be used for a >> > short duration, perhaps for a day or less. >> >> Agreed. Maximum time supported makes sense to me. > >This only makes sense if the negative trust anchor is for a third party >domain. There are situations where it makes sense to use negative trust >anchors covering your own domains, and these might be necessary for a >long period of time (because that would require a difficult upgrade or >extensive renaming). There are more use cases than just the NASA screwup >scenario. True. We had an issue with one of our own domains that has persisted longer. So I think this argues agains an maximum duration for all NTAs, and simply some TTL that the DNS admin can set (which could vary by domain). The other alternative is to leave this question completely to implementers, where some will set a max duration for all NTAs, others will choose a TTL that varies by domain, and others still may not specify any times (in force until removed). Jason From jason_livingood@cable.comcast.com Mon Apr 16 10:56:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC811E80CC for ; Mon, 16 Apr 2012 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.997 X-Spam-Level: X-Spam-Status: No, score=-100.997 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7taC2AkOs0eq for ; Mon, 16 Apr 2012 10:56:08 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 75BEC11E80AB for ; Mon, 16 Apr 2012 10:56:08 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.9397727; Mon, 16 Apr 2012 13:48:49 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 13:55:40 -0400 From: "Livingood, Jason" Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNGMiceZAZwGV2Bk2QEn5IpxhAY5adwrEA Date: Mon, 16 Apr 2012 17:55:39 +0000 Message-ID: In-Reply-To: <0lwr5kor5i.fsf@wjh.hardakers.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Wes Hardaker , Joe Abley Cc: Ralf Weber , Nick Weaver , dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:56:09 -0000 >Joe Abley writes: > >> On 2012-04-11, at 12:09, Wes Hardaker wrote: >>> NTA example.com Thu Apr 12 09:06:42 PDT 2012 >> >> I realise this is just a thought experiment > >Well, true it certainly is. And in fact the above thought experiment >wasn't meant to imply a resource record, but rather a config line. +1 > I >should have probably written it like this: > > NTA { > example.com Thu Apr 12 09:06:42 PDT 2012; > }; > >Or something. In actuality, I'd expect every implementation to have a >different config file structure of course. This is my expectation as well - it is a config file implemented by a DNS administrator (on a recursive resolver). - Jason From jason_livingood@cable.comcast.com Mon Apr 16 12:24:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C31821F869E for ; Mon, 16 Apr 2012 12:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.98 X-Spam-Level: X-Spam-Status: No, score=-100.98 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUEq9X1ii23p for ; Mon, 16 Apr 2012 12:24:06 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE4721F85C4 for ; Mon, 16 Apr 2012 12:24:06 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.9414994; Mon, 16 Apr 2012 15:16:40 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 15:23:34 -0400 From: "Livingood, Jason" To: Paul Vixie , Tony Finch Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAADNGu4AAAnNXgAAAh3MAAJH67AA= Date: Mon, 16 Apr 2012 19:23:33 +0000 Message-ID: In-Reply-To: <4F8865CE.80203@redbarn.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 19:24:07 -0000 On 4/13/12 1:43 PM, "Paul Vixie" wrote: >we need to move quickly to the point where lots of large eyeball-facing >network operators are validating, such that any failure to properly >maintain signatures and keys and DS records, is felt most severely by >whomever's domain is thus rendered unreachable. +100 >i'm opposed to negative trust anchors, both for their security >implications if there were secure applications in existence, and for >their information economics implications. But then what you might get is the request to turn off validation across *all* domains until example.com is fixed and the call center pain stops. This problem of course goes away once there are (many) more recursive operators validating but there's the challenge of how we get from here to there.=20 - Jason From jason_livingood@cable.comcast.com Mon Apr 16 12:29:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F009C21F8554 for ; Mon, 16 Apr 2012 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.985 X-Spam-Level: X-Spam-Status: No, score=-100.985 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3hLj62noT9p for ; Mon, 16 Apr 2012 12:29:11 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 611DA21F8550 for ; Mon, 16 Apr 2012 12:29:11 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.13583425; Mon, 16 Apr 2012 13:15:15 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 15:28:36 -0400 From: "Livingood, Jason" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Evan Hunt Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAADNGu4AAAnNXgAAAh3MAAAUUIYAAAIpuAAABPkoAAItLOoA= Date: Mon, 16 Apr 2012 19:28:34 +0000 Message-ID: In-Reply-To: <08ACE1DE-8F63-484F-B242-406977BED81F@frobbit.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CBB1EA4C59851jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: Tony Finch , dnsop , Paul Vixie Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 19:29:12 -0000 --_000_CBB1EA4C59851jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 4/13/12 5:00 PM, "Patrik F=E4ltstr=F6m" > wrote: In a private chat I am asked to explain my "+1". Let me explain why. Today, before negative trust anchors, the responsibility for whether a the = resolution that is basis for a connection establishment is with the zone ow= ner. If the signature fails, it fails, resolution fails, and the connection= can not be established. Now, if we have negative trust anchors that the validator is controlling, t= hen I interpret it as if this choice of ability to resolve a name moves fro= m the zone owner to the validator (or as in the case of X.509 certs to the = client). What I am against is this *CHANGE* in who is responsible. It is indeed a concern (see a section dedicated to this @ http://tools.ietf= .org/html/draft-livingood-negative-trust-anchors-01#section-5). But I argue= that the design of DNSSEC or the way that incremental deployment was envis= ioned shifted this model by making it something that a recursive operator h= ad to take action to turn on. This creates the situation where recursive op= erators get the costs of adoption errors initially. But, all of this thinking leads me to think about DNSSEC validation "risks"= are very similar to the risk with deploying IPv6? We have an IPv6 day, but= why not a DNSSEC day? One day where *many* players at the same time turn o= n DNSSEC validation? +1 - Jason --_000_CBB1EA4C59851jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7CC6B2B25B6D0246988952B35D4A40BB@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 4/13/12 5:00 PM, "Patrik F=E4ltstr=F6m&quo= t; <paf@fro= bbit.se> wrote:
In a private chat I am asked to explain my "+1".

Let me explain why.

Today, before negative trust anchors, the responsibility for whether a= the resolution that is basis for a connection establishment is with the zo= ne owner. If the signature fails, it fails, resolution fails, and the conne= ction can not be established.

Now, if we have negative trust anchors that the validator is controlli= ng, then I interpret it as if this choice of ability to resolve a name move= s from the zone owner to the validator (or as in the case of X.509 certs to= the client).

What I am against is this *CHANGE* in who is responsible.

It is indeed a concern (see a section dedicated to this @ http://= tools.ietf.org/html/draft-livingood-negative-trust-anchors-01#section-5). B= ut I argue that the design of DNSSEC or the way that incremental deployment= was envisioned shifted this model by making it something that a recursive operator had to take action to turn o= n. This creates the situation where recursive operators get the costs of ad= option errors initially. 

But, all of this thinking leads me to think about = DNSSEC validation "risks" are very similar to the risk with deplo= ying IPv6? We have an IPv6 day, but why not a DNSSEC day? One day where *many* players at the same time turn on DNSSEC v= alidation?

+1

- Jason
--_000_CBB1EA4C59851jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Mon Apr 16 12:38:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465EC11E808C for ; Mon, 16 Apr 2012 12:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVVdVbzDjK7V for ; Mon, 16 Apr 2012 12:38:14 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id D467311E808A for ; Mon, 16 Apr 2012 12:38:13 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.13585315; Mon, 16 Apr 2012 13:23:49 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 15:37:14 -0400 From: "Livingood, Jason" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Nick Weaver Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAADNGu4AAAnNXgAAAh3MAAAUUIYAAAIpuAAAAsJSAAAE1MwAAivDHAA== Date: Mon, 16 Apr 2012 19:37:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CBB1EB8B5985Djasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: Evan Hunt , Tony Finch , dnsop , Paul Vixie Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 19:38:15 -0000 --_000_CBB1EB8B5985Djasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 4/13/12 5:18 PM, "Patrik F=E4ltstr=F6m" > wrote: On 13 apr 2012, at 22:44, Nicholas Weaver wrote: Because practice has shown that it is the recursive resolver, not the autho= rity, that gets blamed. As you saw in my mail, I completely disagree from my own personal experienc= e. If I look at the number of failures, the number of cases where the validato= r is blamed is exactly one -- Comcast in the NASA case. Compared to the abo= ut 50 cases or so when the zone owner/signer is blamed. Yes, we have been r= unning DNSSEC validation in Sweden a bit longer than in the USA. Can you please comment on that mail that uses a few more characters than '+= 1' please? Maybe what we should do is publicize all the escalations and failures we se= e so others have some sense of this (assuming we have the cycles for that)?= Here are a few complaints by customers that I found in a quick search: http://forums.comcast.com/t5/Web-Browsers/Cannot-connect-to-NOAA-gov-and-re= lated-sites/m-p/1211707/highlight/true#M23142 http://forums.comcast.com/t5/Connectivity-and-Modem-Help/DNS-issues-with-go= v-addresses-Proven-Comcast-issue/m-p/1241301/highlight/true#M150167 http://forums.comcast.com/t5/Connectivity-and-Modem-Help/DNS-Issue-Again/m-= p/1209289/highlight/true#M148556 http://forums.comcast.com/t5/Connectivity-and-Modem-Help/DNS-can-t-find-NOA= A-Hurricane-Center-other-major-sites/m-p/1084603/highlight/true#M141297 http://forums.comcast.com/t5/Connectivity-and-Modem-Help/Why-is-Comcast-una= ble-to-keep-DNS-working-No-dot-gov-resolution/m-p/908009/highlight/true#M13= 1067 And sites here (http://www.dnsops.gov/USAdotGOV-status.html) we usually hea= r about. - Jason --_000_CBB1EB8B5985Djasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9E514F4B6C9A424D88BADEF176F5500A@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 4/13/12 5:18 PM, "Patrik F=E4ltstr=F6m&quo= t; <paf@fro= bbit.se> wrote:

On 13 apr 2012, at 22:44, Nicholas Weaver wrote:

Because practice has shown that it is the recursive resolver, not the = authority, that gets blamed.

As you saw in my mail, I completely disagree from my own personal expe= rience.

If I look at the number of failures, the number of cases where the val= idator is blamed is exactly one -- Comcast in the NASA case. Compared to th= e about 50 cases or so when the zone owner/signer is blamed. Yes, we have b= een running DNSSEC validation in Sweden a bit longer than in the USA.

Can you please comment on that mail that uses a few more characters th= an '+1' please?

Maybe what we should do is publicize all the escalations and failures = we see so others have some sense of this (assuming we have the cycles for t= hat)? Here are a few complaints by customers that I found in a quick search= :






And sites here (http://www.dnsops.gov/USAdotGOV-status.html) we usually hear abo= ut.

- Jason

--_000_CBB1EB8B5985Djasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Mon Apr 16 12:45:52 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8368F11E808C for ; Mon, 16 Apr 2012 12:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.956 X-Spam-Level: X-Spam-Status: No, score=-100.956 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a4EfeLrQAbu for ; Mon, 16 Apr 2012 12:45:52 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id F24F911E80B2 for ; Mon, 16 Apr 2012 12:45:51 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.9418723; Mon, 16 Apr 2012 15:38:55 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 15:45:49 -0400 From: "Livingood, Jason" To: Doug Barton , David Conrad Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAADNGu4AAAnNXgAAAh3MAAAUUIYAAAIpuAAABPkoAAACstYAACX3uAACBuoQA Date: Mon, 16 Apr 2012 19:45:48 +0000 Message-ID: In-Reply-To: <4F88D816.9010104@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <7710B0A4C84E9E4BBA2013508DDFFB8C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 19:45:52 -0000 On 4/13/12 9:51 PM, "Doug Barton" wrote: >The problem, and I cannot emphasize this highly enough, is that there is >absolutely no way for an ISP (or other end-user site doing >recursion/validation) to determine conclusively that the failure they >are seeing is due to a harmless stuff-up, vs. an actual security incident. It is admittedly manual and not scalable. It generally involves some DNS admin checking to verify it with the authoritative admin. If not, you are correct that if you cannot confirm it is a misconfiguration then it is questionable if you should take action (as a recursive operator). - Jason From jason_livingood@cable.comcast.com Mon Apr 16 12:48:01 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070D721F8639 for ; Mon, 16 Apr 2012 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.967 X-Spam-Level: X-Spam-Status: No, score=-100.967 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY5HaSpDptwz for ; Mon, 16 Apr 2012 12:48:00 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8389621F861F for ; Mon, 16 Apr 2012 12:48:00 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.13587674; Mon, 16 Apr 2012 13:34:07 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 15:47:26 -0400 From: "Livingood, Jason" Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAADNGu4AAAnNXgAAAh3MAAAUUIYAAAIpuAAAAsJSAAAE1MwAAANwYgAAAqNQAADlPFgAAUHgdgA== Date: Mon, 16 Apr 2012 19:47:25 +0000 Message-ID: In-Reply-To: <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4EEEB9D4A9557C4AA80DF39EA084FBDF@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Warren Kumari , =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= Cc: Evan Hunt , Tony Finch , dnsop , Nick Weaver , Paul Vixie Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 19:48:01 -0000 On 4/14/12 9:23 PM, "Warren Kumari" wrote: >Yes, but AT&T, Verizon, Cox, BestWeb, RR, TW, etc are currently *not* >doing validation, and currently don't have much in the way of incentives >to start -- yes, NASA was an unusual event, but what was the standard >advice that kept popping up on twitter / forums / fb, etc? >"Change your resolver to be 8.8.8.8 and the problem is fixed" -- now, I'm >all for folk changing to use Google's resolvers, but to avoid validation >isn't the right reason=8A > >Yes, NTAs suck and have some really bad security implications, but I >believe that the alternative is worse. Without a way for validating >resolver operators to avoid users jumping ship to non-validation resolver >operators we delay adoption (imo significantly) and users are at a much >larger risk for a much longer time. > >Once most ISPs are performing validation there should be fewer screwups, >and NTAs should be almost never needed -- but until we get to that point >I think that they are needed, and the net security wins outweigh the >costs=8A +1 - Jason From jason_livingood@cable.comcast.com Mon Apr 16 12:50:52 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30DB11E80BA for ; Mon, 16 Apr 2012 12:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.964 X-Spam-Level: X-Spam-Status: No, score=-100.964 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3Nx505uO9F5 for ; Mon, 16 Apr 2012 12:50:51 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0C011E80B7 for ; Mon, 16 Apr 2012 12:50:51 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.13588178; Mon, 16 Apr 2012 13:36:38 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 15:49:58 -0400 From: "Livingood, Jason" Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAADNGu4AAAnNXgAAAh3MAAAUUIYAAAIpuAAAAsJSAAAE1MwAAANwYgAAAqNQAADlPFgAACtd+AAARDxWAADSoMIA= Date: Mon, 16 Apr 2012 19:49:57 +0000 Message-ID: In-Reply-To: <830AF293-6530-4E48-BF43-95FE1C34BE78@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F7C01004EF99B42B7C616F3B9C5AA86@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Joe Abley , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Nick Weaver , Tony Finch , dnsop , Paul Vixie , Evan Hunt Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 19:50:52 -0000 On 4/15/12 10:42 AM, "Joe Abley" wrote: >Patrik, > >Nobody is talking about creating NTAs. NTAs already exist. The question >for this group is whether or not they are worth standardising. > >Joe Quite true, Joe! We'll keep using NTAs as needed. But I've had enough people ask me to document what it was we were doing and why, and other ISPs ask about it that I figured an informational document certainly couldn't hurt.=20 Jason From i.grok@comcast.net Mon Apr 16 22:16:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F6621F854D for ; Mon, 16 Apr 2012 22:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5pBzLh+s0Yw for ; Mon, 16 Apr 2012 22:16:57 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by ietfa.amsl.com (Postfix) with ESMTP id A712E21F84F3 for ; Mon, 16 Apr 2012 22:16:57 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta06.emeryville.ca.mail.comcast.net with comcast id ytDy1i0041u4NiLA6tGxb6; Tue, 17 Apr 2012 05:16:57 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.emeryville.ca.mail.comcast.net with comcast id ytGv1i00W00PQ6U8htGwNs; Tue, 17 Apr 2012 05:16:57 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q3H5Gqml020613 for ; Tue, 17 Apr 2012 01:16:52 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q3H5GqD4020612 for dnsop@ietf.org; Tue, 17 Apr 2012 01:16:52 -0400 Date: Tue, 17 Apr 2012 01:16:52 -0400 From: Scott Schmit To: dnsop@ietf.org Message-ID: <20120417051652.GA32554@odin.ulthar.us> Mail-Followup-To: dnsop@ietf.org References: <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <20120416012804.GB21739@odin.ulthar.us> <9DCA9614-A9C7-4722-9859-35A835078193@virtualized.org> <20120416115232.GA30983@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 05:16:58 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2012 at 08:32:59AM -0700, David Conrad wrote: > On Apr 16, 2012, at 4:52 AM, Scott Schmit wrote: > > Please explain how operators will prevent this, and why they can > > afford to remove a zone from the NTA list (while it is still > > failing) but couldn't afford to leave it off the list in the first > > place. >=20 > I would assume operators will keep NTAs alive until the zone owner > fixes things.=20 >=20 > You appear to be assuming zone owners will leave brokenness in place. Not an assumption--a reality. See Jason's recent posts for documentation. > > No, I'm talking about a targeted use of the controversial practice of > > returning spoofed results redirecting the user to another host.=20 >=20 > An interesting idea, albeit I'm actually unsure which is less > appealing architecturally speaking. For others against NTAs, is the > use of redirection as Scott suggests preferable? Believe me, I feel dirty even suggesting it. But its benefits could outweigh the ugliness of it, so I figured I'd offer it. Another approach would be to bless client-configured/non-automated NTAs for now...until there are enough resolvers validating. Then do a 'Turn Off All NTAs Forever Day.'" And hope that the world follows through & blessing NTAs doesn't backfire instead. --=20 Scott Schmit --YZ5djTAD1cGYuMQK Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNDE3MDUxNjUyWjAjBgkqhkiG9w0BCQQxFgQUXduXk6D0 DPyxPwr1iPh4GMTe8vwweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAABxXiDYy rgemL9/T3yVUTpz0aaM8C6xkNxifAwwVIjiKqOS6WXvFi6/u4RZkFFgPbqRNsGZFHsg6EDSS 44UdhthGRlBdukNqdSZvfOtKDOZ8gy+cYeqpEXGfqcBnimbfa7inIDva6oo1i9ummHwiI4+G gnT0uN24H0Gw621RR1Vzsn4wULpO6Kj91SkSqNuIWQQQapD4LWjX1ZHzu07vVHNPwdKj+kap SkcV6+ysAeoRsTrdmiyrbbKXJUUuAg+YussD8P9uTYw2Gq1ym8bNlq+hUwtz2Zy96F+mlbMO cdgs+KXJfjnFK8jil+/4XGZxv2UEOjq3SF1DhAwDbIEeJw== --YZ5djTAD1cGYuMQK-- From warren@kumari.net Tue Apr 17 00:25:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA43821F8458 for ; Tue, 17 Apr 2012 00:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FNTRTTCaRe0 for ; Tue, 17 Apr 2012 00:25:28 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 27C8821F854B for ; Tue, 17 Apr 2012 00:25:27 -0700 (PDT) Received: from dhcp-27-180.ripemtg.ripe.net (dhcp-27-180.ripemtg.ripe.net [193.0.27.180]) by vimes.kumari.net (Postfix) with ESMTPSA id 43D101B40378; Tue, 17 Apr 2012 03:25:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 17 Apr 2012 08:55:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Livingood, Jason" X-Mailer: Apple Mail (2.1257) Cc: Joe Abley , Nick Weaver , Tony Finch , dnsop , Paul Vixie , Evan Hunt Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:25:28 -0000 On Apr 16, 2012, at 9:49 PM, Livingood, Jason wrote: > On 4/15/12 10:42 AM, "Joe Abley" wrote: >=20 >> Patrik, >>=20 >> Nobody is talking about creating NTAs. NTAs already exist. The = question >> for this group is whether or not they are worth standardising. >>=20 >> Joe >=20 > Quite true, Joe! We'll keep using NTAs as needed. But I've had enough > people ask me to document what it was we were doing and why, and other > ISPs ask about it that I figured an informational document certainly > couldn't hurt.=20 >=20 As one of the folk who asked -- thank you. I think that this is a useful document and is *really* needed to help = with DNSSEC deployment, and fully support it's publication (especially = if it comes with examples!)=85 The IETF publishing an RFC on this doesn't mean that folk will be forced = to use it (and not publishing it doesn't mean that folk won't) -- if = this were not true, we would have universal adoption of BCP 38, everyone = would be running v6 and all packets involved in SPAM / DoS would have = the Evil bit set=85 W > Jason >=20 From paf@frobbit.se Tue Apr 17 00:38:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D4C21F856F for ; Tue, 17 Apr 2012 00:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLZiy1qUbuq5 for ; Tue, 17 Apr 2012 00:38:07 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id A121721F856A for ; Tue, 17 Apr 2012 00:38:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id BAE541393E662; Tue, 17 Apr 2012 09:38:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUhfrkwckiZf; Tue, 17 Apr 2012 09:38:03 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 743E91393E65B; Tue, 17 Apr 2012 09:38:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Tue, 17 Apr 2012 09:38:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2B8E43BA-6404-4EC4-B4D2-E73044BD9F9C@frobbit.se> References: To: Warren Kumari X-Mailer: Apple Mail (2.1257) Cc: Joe Abley , Nick Weaver , Tony Finch , dnsop , Paul Vixie , Evan Hunt , "Livingood, Jason" Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:38:07 -0000 On 17 apr 2012, at 08:55, Warren Kumari wrote: > The IETF publishing an RFC on this doesn't mean that folk will be = forced to use it (and not publishing it doesn't mean that folk won't) -- = if this were not true, we would have universal adoption of BCP 38, = everyone would be running v6 and all packets involved in SPAM / DoS = would have the Evil bit set=85 Well, I do not agree with this extrapolation. There is a difference = between RFCs that tell people to do things and to make investments and = the ones that tell people not to. But you can most certainly find those as well ;-) Patrik From regnauld@x0.dk Tue Apr 17 01:30:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5E21F85A4 for ; Tue, 17 Apr 2012 01:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3nTbwilFs-U for ; Tue, 17 Apr 2012 01:30:31 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1321F85A2 for ; Tue, 17 Apr 2012 01:30:30 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 52A3E4CEE32; Tue, 17 Apr 2012 10:30:28 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id D0HEehC1QEYN; Tue, 17 Apr 2012 10:30:28 +0200 (CEST) Received: from macbook.bluepipe.net (macbook.bluepipe.net [195.249.214.179]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id 2D1414CEDB0; Tue, 17 Apr 2012 10:30:25 +0200 (CEST) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id CF7958F8C70; Tue, 17 Apr 2012 10:30:26 +0200 (CEST) Date: Tue, 17 Apr 2012 10:30:26 +0200 From: Phil Regnauld To: "Livingood, Jason" Message-ID: <20120417083026.GG43960@macbook.bluepipe.net> References: <830AF293-6530-4E48-BF43-95FE1C34BE78@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Darwin 11.3.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsop , Joe Abley Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 08:30:32 -0000 Livingood, Jason (Jason_Livingood) writes: > On 4/15/12 10:42 AM, "Joe Abley" wrote: > > >Patrik, > > > >Nobody is talking about creating NTAs. NTAs already exist. The question > >for this group is whether or not they are worth standardising. > > > >Joe > > Quite true, Joe! We'll keep using NTAs as needed. But I've had enough > people ask me to document what it was we were doing and why, and other > ISPs ask about it that I figured an informational document certainly > couldn't hurt. I think quite a few people new to DNSSEC might be happy to know that NTAs do in fact exist (and at least one vendor actually has knobs to turn them on it their GUI), and how they can be (mis)used. Additionally, I found the discussion on the possibility of having NTAs automatically limited in time quite healthy. So at the very least having the concept documented seems worthy of the effort. Phil From shane@isc.org Tue Apr 17 02:34:13 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A40E21F8627 for ; Tue, 17 Apr 2012 02:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBD1cfoElfYW for ; Tue, 17 Apr 2012 02:34:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CCD4121F8576 for ; Tue, 17 Apr 2012 02:34:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0C6F85F984C; Tue, 17 Apr 2012 09:33:56 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:67c:64:42:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C17FC216C31; Tue, 17 Apr 2012 09:33:53 +0000 (UTC) (envelope-from shane@isc.org) Date: Tue, 17 Apr 2012 11:33:50 +0200 From: Shane Kerr To: David Conrad Message-ID: <20120417113350.128585f5@shane-eeepc.home.time-travellers.org> In-Reply-To: <575A95AA-A654-4671-8833-8D3E02023B55@virtualized.org> References: <6AC5F263-6698-4047-B74F-0094F1637007@nominum.com> <4F8851CF.2020807@dougbarton.us> <4F8865CE.80203@redbarn.org> <20120413200907.GA86915@isc.org> <6E08322F-1DB4-47B7-8210-1B5BC37AFFBB@icsi.berkeley.edu> <9B9153FE-EE60-4ECC-BA58-7279EA2BF6C4@ICSI.Berkeley.EDU> <536CCE0E-3308-4B34-ADFD-F23E500B5325@frobbit.se> <4E728138-3498-4B87-AA34-FCEBB3A089C6@kumari.net> <615EDFCB-996E-4520-A2F7-6F9DE6CF65D0@frobbit.se> <4F8AF955.2060500@redbarn.org> <24440C49-F07D-41CA-9CA9-A1596541CC53@virtualized.org> <4F8B2BA9.1050603@redbarn.org> <4F8B9AA4.2080000@redbarn.org> <575A95AA-A654-4671-8833-8D3E02023B55@virtualized.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: [DNSOP] Preventing cruft in NTA management, was on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 09:34:13 -0000 David, On Sunday, 2012-04-15 21:14:04 -0700, David Conrad wrote: > On Apr 15, 2012, at 9:05 PM, Paul Vixie wrote: > > if you don't want something to live forever and get turned on by > > default or left on across sysadmin churn, don't put it in an RFC. > > Weren't we talking about requiring an explicit lifetime on NTAs? I'd > be all for "SHOULDs"/"MUSTs" that increase the touch factor to ensure > people pull NTAs instead of letting them ossify. That is my suggestion, yes, for just the problems that Paul identifies, as well as any other staleness that might ensue. -- Shane From shane@isc.org Tue Apr 17 02:51:39 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F9A21F8652 for ; Tue, 17 Apr 2012 02:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0Y315ESUnI4 for ; Tue, 17 Apr 2012 02:51:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4221F85F0 for ; Tue, 17 Apr 2012 02:51:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id AC2645F984C for ; Tue, 17 Apr 2012 09:51:31 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-eeepc.home.time-travellers.org (unknown [IPv6:2001:67c:64:42:4a5d:60ff:fe2a:dd50]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7E837216C36 for ; Tue, 17 Apr 2012 09:51:29 +0000 (UTC) (envelope-from shane@isc.org) Date: Tue, 17 Apr 2012 11:51:25 +0200 From: Shane Kerr To: dnsop Message-ID: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 09:51:39 -0000 All, Is it just me, or does the NTA discussion remind anyone else of NAT discussions? And not just because they have the same letters. ;) Operators say, "wow, here is a useful tool that can solve real-world problems, maybe it would be helpful to recognize these problems and perhaps standardize the solution?" Protocol zealots answer, "but this is bad for this long list of very valid reasons, so sorry about your problems but really we know better." If we insist on DNS Purity, I predict a similar end state with NTA as with NAT: they will be almost universally deployed, and completely non-standard, and result in a lot of potential breakage due to inconsistencies and semi-broken implementations. Yay. -- Shane From ogud@ogud.com Tue Apr 17 09:29:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4739811E80A5 for ; Tue, 17 Apr 2012 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r641I94qasYy for ; Tue, 17 Apr 2012 09:29:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9F69E11E80A3 for ; Tue, 17 Apr 2012 09:29:09 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q3HGT826019911 for ; Tue, 17 Apr 2012 12:29:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F8D9A52.10803@ogud.com> Date: Tue, 17 Apr 2012 12:29:06 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsop WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [DNSOP] What does a NTA validator return in an answer under the NTA? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:29:10 -0000 When resolving with DNSSEC-trigger on Comcast's network DNSSEC-Trigger acts like forwarding stub-validator. For it to be happy when there is a NTA in place, the upstream resolvers MUST return to it the non validatable RRSIG (if they exist). The current draft is silent on the behavior of the validating resolver as if it returns the answers with RRSIG's or without. The reason for this is if NTA strips signatures the stub-validator thinks it is under attack and may a) go into recursive mode to try to resolve the domain, getting to the right answer the long way. b) Give the wrong error "Missing signatures" instead of the real error. If all the validator does is not to set the AD bit for RRsets at and below the NTA, stub-resolvers (and cascading resolvers) should be happy. Olafur From Ralf.Weber@nominum.com Tue Apr 17 09:39:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DBA11E8080 for ; Tue, 17 Apr 2012 09:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4BDbBg8CZUX for ; Tue, 17 Apr 2012 09:39:54 -0700 (PDT) Received: from psmtp.com (chip3ob111.obsmtp.com [64.18.14.70]) by ietfa.amsl.com (Postfix) with ESMTP id 992C011E8074 for ; Tue, 17 Apr 2012 09:39:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by chip3ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT42c2VKroRGPy517ed0aZE9glAhPGeJU@postini.com; Tue, 17 Apr 2012 09:39:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A207D1B8352 for ; Tue, 17 Apr 2012 09:39:52 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9946A190064; Tue, 17 Apr 2012 09:39:52 -0700 (PDT) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 09:39:52 -0700 From: Ralf Weber To: Olafur Gudmundsson Thread-Topic: [DNSOP] What does a NTA validator return in an answer under the NTA? Thread-Index: AQHNHLi1i8Cc8yzBJ0m7ymHx3ZifLw== Date: Tue, 17 Apr 2012 16:39:51 +0000 Message-ID: <0269396A-52F8-448A-B247-0B0D49D5CF21@nominum.com> References: <4F8D9A52.10803@ogud.com> In-Reply-To: <4F8D9A52.10803@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop Subject: Re: [DNSOP] What does a NTA validator return in an answer under the NTA? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:39:54 -0000 Moin! On 17.04.2012, at 09:29, Olafur Gudmundsson wrote: > When resolving with DNSSEC-trigger on Comcast's network DNSSEC-Trigger ac= ts like forwarding stub-validator. > For it to be happy when there is a NTA in place, the upstream resolvers M= UST return to it the non validatable RRSIG (if they exist). >=20 > The current draft is silent on the behavior of the validating resolver as= if it returns the answers with RRSIG's or without. >=20 > The reason for this is if NTA strips signatures the stub-validator think= s it is under attack and may > a) go into recursive mode to try to resolve the domain, getting to the ri= ght answer the long way. > b) Give the wrong error "Missing signatures" instead of the real error. >=20 > If all the validator does is not to set the AD bit for RRsets at and belo= w the NTA, stub-resolvers (and cascading resolvers) should be happy. That's exactly what at least our implementation (Nominum Vantio) that Comca= st uses does and I agree that this behavior should be specified in the draf= t. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From msk@cloudmark.com Tue Apr 17 09:40:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256BF11E80A3 for ; Tue, 17 Apr 2012 09:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO4Za63pDDf8 for ; Tue, 17 Apr 2012 09:40:01 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2395D11E80BA for ; Tue, 17 Apr 2012 09:40:01 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id z4gH1i0010as01C014gH9w; Tue, 17 Apr 2012 09:40:17 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=zFiQ2L8hQeEA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=rEUZ27ypv1Z-6LxNpgMA:9 a=xBHFhghHLZxbAtdHqpgA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=k4jbGveSQKo0SvUU:21 a=zuyzTq3SgLAlysGv:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 09:40:00 -0700 From: "Murray S. Kucherawy" To: dnsop Thread-Topic: [DNSOP] on "Negative Trust Anchors" Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDAAPrmiAADmQDoAAAnNXgAAAh3QAAAUUIIAAAIpvAAAAsJSAAAE1MwAAANwXgAAAqNQAADlPFwAACtd9AAARDxaAAD0Jp4AAFzsOgAAFbxTw Date: Tue, 17 Apr 2012 16:40:00 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F6189@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334680817; bh=eEGVDOLKP5611oWRfYesnyDj5scBN4yXlPdPswsc8Wc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=DWU01J55mtT03MLuRtDW7qAWPOINVmqk2o5Ygj3qrThwnSmI7y1CFr8CG6zVaRBeb AUa2fV/qnk/f5ZvkwE40iGTuxey8wc7UCEuLSaIn03pZ22k6N1yrsVoD1F/B7FwASH qvVRJWRtHiIKUX1s6oUlwLFlATH/ohS+Kk7giWvs= Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:40:05 -0000 > -----Original Message----- > From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of= Warren Kumari > Sent: Monday, April 16, 2012 11:55 PM > To: Livingood, Jason > Cc: Joe Abley; Nick Weaver; Tony Finch; dnsop; Paul Vixie; Evan Hunt > Subject: Re: [DNSOP] on "Negative Trust Anchors" >=20 > I think that this is a useful document and is *really* needed to help > with DNSSEC deployment, and fully support it's publication (especially > if it comes with examples!)... >=20 > The IETF publishing an RFC on this doesn't mean that folk will be > forced to use it (and not publishing it doesn't mean that folk won't) - > - if this were not true, we would have universal adoption of BCP 38, > everyone would be running v6 and all packets involved in SPAM / DoS > would have the Evil bit set... Some of this conversation reminds me of the "X-" debate just wrapping up in= apps, in that things that are supposed to be temporary often become perman= ent even if we tag them very explicitly as temporary. In that sense, I'm m= ore sympathetic to the "no" side so far, but not enough to object. Also, a lot of things in apps space like to call out "MUST/SHOULD except if= local policy says otherwise", and this strikes me as, basically, a kind of= a local policy tool. I presume the idea is to describe a mechanism that w= orks and is minimally destructive to encourage people away from more broken= methods. In that sense, this is the right thing to do. So if this is going to go forward to publication, I would urge ample explan= ation of why we think this is necessary to document, but also advocate stro= ngly in the document that the technique is meant to be a short-term solutio= n for a problem that exists during gradual and un-coordinated DNSSEC rollou= t, and that support for it be dropped once DNSSEC has reached critical mass= . Or something like that. -MSK From chris_griffiths@cable.comcast.com Tue Apr 17 12:27:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B0211E80BA for ; Tue, 17 Apr 2012 12:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.277 X-Spam-Level: X-Spam-Status: No, score=-100.277 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jbWS2uZEX6j for ; Tue, 17 Apr 2012 12:27:31 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id BDD3511E80B5 for ; Tue, 17 Apr 2012 12:27:31 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.9551980; Tue, 17 Apr 2012 15:20:00 -0400 Received: from PACDCEXMB03.cable.comcast.com ([fe80::c9c:28ac:e945:214f]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.02.0283.003; Tue, 17 Apr 2012 15:26:56 -0400 From: "Griffiths, Chris" To: "Livingood, Jason" Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5aU2PwIgABrs4CAAMNtgIAIGAeAgAGsuYA= Date: Tue, 17 Apr 2012 19:26:56 +0000 Message-ID: <659AFDE9-F0F5-49E9-BAF1-FFA70950D181@Cable.Comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D8C639451FB2A4CB4814E485262B8A4@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tony Finch , dnsop , Wes Hardaker Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:27:32 -0000 On Apr 16, 2012, at 1:52 PM, Livingood, Jason wrote: > On 4/11/12 10:16 AM, "Tony Finch" wrote: >=20 >> Griffiths, Chris wrote: >>> On Apr 10, 2012, at 8:11 PM, Wes Hardaker wrote: >>>=20 >>>> Suggested rewrite: >>>>=20 >>>> Furthermore, a Negative Trust Anchor MUST only be used for a >>>> short duration, perhaps for a day or less. >>>=20 >>> Agreed. Maximum time supported makes sense to me. >>=20 >> This only makes sense if the negative trust anchor is for a third party >> domain. There are situations where it makes sense to use negative trust >> anchors covering your own domains, and these might be necessary for a >> long period of time (because that would require a difficult upgrade or >> extensive renaming). There are more use cases than just the NASA screwup >> scenario. >=20 > True. We had an issue with one of our own domains that has persisted > longer. So I think this argues agains an maximum duration for all NTAs, > and simply some TTL that the DNS admin can set (which could vary by > domain). The other alternative is to leave this question completely to > implementers, where some will set a max duration for all NTAs, others wil= l > choose a TTL that varies by domain, and others still may not specify any > times (in force until removed). I think leaving flexibility to support different use cases makes sense, sin= ce there are definitely going to be different reasons for keeping an NTA in= place for short as well as longer term reason. Perhaps we can define thes= e additional use cases like short term, longer term, and indefinite until r= emoved. Chris= From fanf2@hermes.cam.ac.uk Wed Apr 18 04:26:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC28521F85B5 for ; Wed, 18 Apr 2012 04:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.533 X-Spam-Level: X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBpBrrQOKvgY for ; Wed, 18 Apr 2012 04:26:25 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id A697321F85B6 for ; Wed, 18 Apr 2012 04:26:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46123) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SKT1j-0007YY-Ey (Exim 4.72) (return-path ); Wed, 18 Apr 2012 12:26:23 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SKT1j-0004YY-Jh (Exim 4.67) (return-path ); Wed, 18 Apr 2012 12:26:23 +0100 Date: Wed, 18 Apr 2012 12:26:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Olafur Gudmundsson In-Reply-To: <4F8D9A52.10803@ogud.com> Message-ID: References: <4F8D9A52.10803@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop WG Subject: Re: [DNSOP] What does a NTA validator return in an answer under the NTA? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 11:26:30 -0000 I would expect the validator to treat queries for names under a negative trust anchor as if the CD bit had been set. Tony. -- f.anthony.n.finch http://dotat.at/ Hebrides, Bailey: Northerly or northeasterly 5 to 7, but mainly 4 in south and east Hebrides. Rough or very rough, becoming moderate in east Hebrides. Squally showers. Moderate or good. From paul@redbarn.org Wed Apr 18 11:08:42 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444FC21F855F for ; Wed, 18 Apr 2012 11:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib8AXZLLFY2g for ; Wed, 18 Apr 2012 11:08:40 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F50621F855A for ; Wed, 18 Apr 2012 11:08:40 -0700 (PDT) Received: from [10.44.223.49] (69-170-40-42.static-ip.telepacific.net [69.170.40.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 900E0EBCE9 for ; Wed, 18 Apr 2012 18:08:39 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F8F0321.5040307@redbarn.org> Date: Wed, 18 Apr 2012 18:08:33 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsop References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> In-Reply-To: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 18:08:42 -0000 On 4/17/2012 9:51 AM, Shane Kerr wrote: > Is it just me, or does the NTA discussion remind anyone else of NAT > discussions? And not just because they have the same letters. ;) > > Operators say, "wow, here is a useful tool that can solve real-world > problems, maybe it would be helpful to recognize these problems and > perhaps standardize the solution?" > > Protocol zealots answer, "but this is bad for this long list of very > valid reasons, so sorry about your problems but really we know better." > > If we insist on DNS Purity, I predict a similar end state with NTA as > with NAT: they will be almost universally deployed, and completely > non-standard, and result in a lot of potential breakage due to > inconsistencies and semi-broken implementations. Yay. what potential breakage or semi-broken implementations are you thinking of? in NAT, it's all rather broken. the fix for NAT, had the IETF been willing to recognize this technology in spite NAT's non-purity, would have been in the form of what we now call firewall traversal or perhaps PnP. neither of which the world was ready for at the time, and neither of which was something that could have been standardized soon enough to stop "bad NAT" from getting out, nor standardized at a high enough quality and relevance level at that time since in the early days noone knew yet how many things NAT would break. but let's continue the analogy anyway. what would have saved the world from "bad NAT" was a change to the underlying connection model of the internet -- not just an RFC that says "here's how you can use 192.168" but rather one that said "here's how you can preserve some aspects of end-to-end, not break FTP, not have to reframe your TCP sessions at the gateway layer if they might contain embedded IP addresses." in that sense, i agree with your comparison: a fundamental change to the nature of DNSSEC to allow for secure signalling of errors and secure signalling of middle-man policy would definitely help us head off a generation of "bad NTA". but that's not what's on offer here. DNSSEC currently presumes reliable end-to-end failure, and offers no way to signal other conditions. so if somebody breaks into your primary name server and alters your zone and either doesn't sign their changes or signs the whole zone with some key that's not matched by your delegating DS RRset, right now it will cause the modified content to be marked as bad and ignored or dropped by any validating server. NTA will change that, by adding middlemen who can decide as a matter of their own policy to just ignore these bad or missing signatures and pass your data to their stub clients as though DNSSEC had not been in use. that's horrible. that's worse for deployment confidence in DNSSEC than anything the social security administration or NASA could otherwise do by failing to re-sign or using the wrong keys. so i'm all for changing DNSSEC itself to accomodate these other use cases. but i'm not on-board at all for a standardized way for middlemen to block unwanted (by them) DNSSEC signalling. this means i'm in favour of the thing you're suggesting ("do better with DNSSEC than we did with NAT") but i'm also opposed to the thing you're supporting ("make end-to-end DNSSEC failures less reliable"). i think this means you're offering me a false dichotomy above. let me know if i'm misreading you. paul From drc@virtualized.org Wed Apr 18 11:28:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A72E11E8093 for ; Wed, 18 Apr 2012 11:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWXmqW3Uf7ED for ; Wed, 18 Apr 2012 11:28:40 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 112DE11E8091 for ; Wed, 18 Apr 2012 11:28:40 -0700 (PDT) Received: from [192.168.2.168] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 07A021705A; Wed, 18 Apr 2012 18:28:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4F8F0321.5040307@redbarn.org> Date: Wed, 18 Apr 2012 11:28:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> <4F8F0321.5040307@redbarn.org> To: paul vixie X-Mailer: Apple Mail (2.1257) Cc: dnsop Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 18:28:40 -0000 Paul, On Apr 18, 2012, at 11:08 AM, paul vixie wrote: > DNSSEC currently presumes reliable end-to-end failure, and offers no = way > to signal other conditions. True, in the sense that either a name (and the entire chain leading to = that name) validates or it doesn't. > NTA will change > that, by adding middlemen who can decide as a matter of their own = policy > to just ignore these bad or missing signatures and pass your data to > their stub clients as though DNSSEC had not been in use. No. NTA is not adding middlemen. The way the vast majority of the DNS is = implemented, namely stub communicating with a remote validator, there = already exists middlemen. They're called the validator operators. NTA is = allowing those middlemen to implement policies that meet their business = requirements. Their validator, their rules. If you don't like the policy of your validator operator, change to a = validator operator whose policy you agree with (or, better yet, run your = own validator -- it is the only way to be sure). If you are not = permitted to do this, you have other issues. Regards, -drc From paul@redbarn.org Wed Apr 18 11:52:16 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E522A21F845F for ; Wed, 18 Apr 2012 11:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDzJjaSmrcXb for ; Wed, 18 Apr 2012 11:52:12 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF3B21F845D for ; Wed, 18 Apr 2012 11:52:12 -0700 (PDT) Received: from [10.44.223.49] (69-170-40-42.static-ip.telepacific.net [69.170.40.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 8914DEBCE7 for ; Wed, 18 Apr 2012 18:52:11 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F8F0D56.8000603@redbarn.org> Date: Wed, 18 Apr 2012 18:52:06 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsop References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> <4F8F0321.5040307@redbarn.org> <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> In-Reply-To: <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 18:52:17 -0000 On 4/18/2012 6:28 PM, David Conrad wrote: > ... Their validator, their rules. ... that would be a fundamental change to the architecture of dnssec. see again: From jim@rfc1035.com Wed Apr 18 11:52:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888AA11E8089 for ; Wed, 18 Apr 2012 11:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeuyjaEoSJOU for ; Wed, 18 Apr 2012 11:52:19 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABDF11E8085 for ; Wed, 18 Apr 2012 11:52:18 -0700 (PDT) Received: from [127.0.0.1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id 05FE1CBC451; Wed, 18 Apr 2012 19:52:16 +0100 (BST) Message-Id: <888B37DE-66E5-46F7-8F33-B5B8EDC987E1@rfc1035.com> From: Jim Reid To: David Conrad In-Reply-To: <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Apr 2012 19:52:14 +0100 References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> <4F8F0321.5040307@redbarn.org> <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> X-Mailer: Apple Mail (2.936) Cc: dnsop , paul vixie Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 18:52:20 -0000 On 18 Apr 2012, at 19:28, David Conrad wrote: > If you don't like the policy of your validator operator, change to a > validator operator whose policy you agree with (or, better yet, run > your own validator -- it is the only way to be sure). If you are > not permitted to do this, you have other issues. +1 Though you've not explained how someone would be able to find out what was the flavour-of-the-month policy of the validator operator they were using that day. Assuming the current network's validation policy was broken (for some definition of broken) would of course be a wise approach. That probably means everyone runs their own validator to avoid sucky hotel nets and the like. Which just moves where NTAs get (mis)configured. From joe.abley@icann.org Wed Apr 18 12:31:36 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D38B21F84EC for ; Wed, 18 Apr 2012 12:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf-l-QsJoTUT for ; Wed, 18 Apr 2012 12:31:36 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id C690B21F84C4 for ; Wed, 18 Apr 2012 12:31:34 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 18 Apr 2012 12:31:34 -0700 From: Joe Abley To: Jim Reid Date: Wed, 18 Apr 2012 12:32:09 -0700 Thread-Topic: [DNSOP] NTA... the new NAT? Thread-Index: Ac0dmd0tMUwWqHj1SpuVlUtBW/ul4Q== Message-ID: <7FD66F13-27E5-4ADC-A4FE-494B00A2F4B1@icann.org> References: <20120417115125.4a966c81@shane-eeepc.home.time-travellers.org> <4F8F0321.5040307@redbarn.org> <188F19B4-FD25-45C3-9A92-E8D47EF1651B@virtualized.org> <888B37DE-66E5-46F7-8F33-B5B8EDC987E1@rfc1035.com> In-Reply-To: <888B37DE-66E5-46F7-8F33-B5B8EDC987E1@rfc1035.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop , paul vixie , David Conrad Subject: Re: [DNSOP] NTA... the new NAT? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 19:31:36 -0000 On 2012-04-18, at 14:53, "Jim Reid" wrote: > On 18 Apr 2012, at 19:28, David Conrad wrote: >=20 >> If you don't like the policy of your validator operator, change to a =20 >> validator operator whose policy you agree with (or, better yet, run =20 >> your own validator -- it is the only way to be sure). If you are =20 >> not permitted to do this, you have other issues. >=20 > +1 >=20 > Though you've not explained how someone would be able to find out what =20 > was the flavour-of-the-month policy of the validator operator they =20 > were using that day. In a cryptographic sense, if you outsource your validation to a third party= you can never be sure of the integrity of the answers you receive. If you = want certainty, validate in the client. (I continue to think this is the ad= vice the IETF should be giving. Certainty is required in some applications.= I think it should be the default expectation of other protocols and applic= ations.) In a more practical sense, if you're making use of a third-party supplier f= or something, presumably you have a way to find out details of the service = they're providing. In principle, wanting a validation supplier who is sane = is no different to wanting a bank who doesn't store or process your persona= l data in a jurisdiction with over-reaching data mining by government. If y= ou care, chances are you can find something that meets your needs. Joe= From jason_livingood@cable.comcast.com Thu Apr 19 07:40:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7257C21F866B for ; Thu, 19 Apr 2012 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.23 X-Spam-Level: X-Spam-Status: No, score=-98.23 tagged_above=-999 required=5 tests=[AWL=-2.761, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGcwVILLv4kE for ; Thu, 19 Apr 2012 07:40:05 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9A12521F8644 for ; Thu, 19 Apr 2012 07:40:04 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.14027473; Thu, 19 Apr 2012 08:26:29 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.02.0283.003; Thu, 19 Apr 2012 10:39:58 -0400 From: "Livingood, Jason" To: dnsop Thread-Topic: identitytheft.gov DNSSEC Issue Thread-Index: AQHNHjpKKApY//pbPUqrIcJQ46KU0g== Date: Thu, 19 Apr 2012 14:39:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [24.40.56.165] Content-Type: multipart/related; boundary="_004_CBB59BB45B25Djasonlivingoodcablecomcastcom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [DNSOP] identitytheft.gov DNSSEC Issue X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:40:09 -0000 --_004_CBB59BB45B25Djasonlivingoodcablecomcastcom_ Content-Type: multipart/alternative; boundary="_000_CBB59BB45B25Djasonlivingoodcablecomcastcom_" --_000_CBB59BB45B25Djasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In case anyone knows the domain admins=85 Jason On 4/11/12 5:58 PM, "Szymanski, Todd M [NTK]" > wrote: [http://dnsviz.net/d/www.identitytheft.gov/dnssec/auth_graph.png] For those who can=92t see pictures, it=92s identitytheft.gov. Looks like i= t=92s been this way for about a week. ____________________________________________ Todd Szymanski| Data Network Administration Sprint | Service Management --_000_CBB59BB45B25Djasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <98A82C9F9C36FF4C9894B28B443CD148@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
In case anyone knows the domain admins=85

Jason

On 4/11/12 5:58 PM, "Szymanski, Todd M [NTK]" <Todd.Szymanski@sprint.com> wrote:=

 

3D"http://dnsviz.net/d=

For those who can=92t see pictures, it=92s identityt= heft.gov.  Looks like it=92s been this way for about a week. 

 

 

_________________________________________= ___
Todd Szymanski| Data Network Administration

Sprint | Service Management 

 --_000_CBB59BB45B25Djasonlivingoodcablecomcastcom_-- --_004_CBB59BB45B25Djasonlivingoodcablecomcastcom_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=134650; creation-date="Thu, 19 Apr 2012 14:39:57 GMT"; modification-date="Thu, 19 Apr 2012 14:39:57 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAcEAAAQmCAYAAABIwgR1AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAP+QSURBVHhe 7F0FYBVn1r0QEuLuBsGCu1uh0FJvqXv711237rbV7dZl6+7eUgq0heLuLjECcXeB/5wvmfSRJmgg T+7dnb6X9+bNfN+Z4Ttzvd1uiKgoAoqAIqAIKAIuiEA7F5yzTlkRUAQUAUVAETAIKAnqjaAIKAKK gCLgsggoCbrspdeJKwKKgCKgCCgJ6j2gCCgCioAi4LIIKAm67KXXiSsCioAioAgoCeo9oAgoAoqA IuCyCCgJuuyl14krAoqAIqAIKAnqPaAIKAKKgCLgsggoCbrspdeJKwKKgCKgCCgJ6j2gCCgCioAi 4LIIKAm67KXXiSsCioAioAgoCeo9oAgoAoqAIuCyCCgJuuyl14krAoqAIqAIHBYSrK2tlc2bN0tS UpK4ubkpyoqAIuBiCHAN8PHxkb59+0pgYKCLzV6n60gIHBYSLC4ulh9//FGysrJk1KhRUlVV5UiY 6FgVAUXgEBBo166dZGdny8qVK81DMNcAFUXAXhE4LCRYUVFhngInTZokY8aMEW1ZaK+XX8elCLQ8 Am3atJH8/HyhNlhWVtbyJ9AjKgItiMBhIUGOr3379hIQECCenp4tOFw9lCKgCDgCAn5+fsKtbdu2 jjBcHaMLI3DYSJDaH58EVRQBRcD1EOC//V27drnexHXGDofAYSNBh0NCB6wIKAKKgCLgcggoCbrc JdcJKwKKgCKgCFgIKAnqvaAIKAKKgCLgsggoCbrspdeJKwKKgCKgCCgJ6j2gCCgCioAi4LIIKAk6 0KUvra6RypoaqUDkXUUNtmq+2vyNz6rwXS2i8qqxIUBX8H/z2a769/yupv67dm3biHs7N7OfWxsR D7e20gb/o3ggydl8hsRnT+xjNnzWvtHfnu5u4uPu7kAo6lAVAUVAEfgbASVBO7gbQFeSXVohhZWV UlhRLUV4LaqslgK+VlThtUryyvEd/i4DEXIjIZZVVUtpFV5BhGU1de9JjiQ55KeAAUmBEJBlHR1C +Hltfeg6c7hAbkaQ4IzyHnitBwRkR5L0xKuPRzvxxqu3Ozf3+ld8jvf8LqC9hwR5tpdATw+8by/+ 5tVmw3ehXp7ihuOpKAKKgCJgTwgoCR7Bq5FdViGZpWWSWYKttNy8ZpXhFe+zQIIFqLRTQNKrIOFV SQlehRvJDCTiBzIhEZF8vEE+vh7uEunn1fCZD77zxNYO5NYehNaWxAbxgrbmVs9u7vicGh+FZEnS 5F61OAc1TIs3y0Gq5MryapCrRbrmtVryMabtRSXmPYm3GGOV8oo6nsUYfUCCgfWkWPfaXsK8vSTC B5uvl4T7eEsE/zbv+bn3EbwKeipFQBFQBP5GQEnwMNwNlSCWpIJibEWyLb9IUguLJQNElw3CIxFm 430OXktBiEIS8vaUWH8faEteEuXrLb3DgyXEC9oTiCIE5BcEUvH18DBaF8mNpknzStIz79vCVInv 8J4E59YGZs1DVLpMsQOQGk2pnA8Jkq+V9abYus/qNE9qpsXQSgtB4DmYYw4IMbesEq/leK3A/Etk R0mp1HK+7UDgmFcY5hzasGHeIMMOgf6SEOQnCYHYAvxB3np7HobbUw+pCCgCNgjoKnOIt0M11KV1 OfmyKa9AtuYVgfgKseDXaXkZ2HZiq6GWBHNiTKCvxPn7yrCYcJCer8QH+BrSC0JpOZoPqdmR6Cwz oxd+01rC+o/tQKTt2taZQQ9ESIylIMUSS4skQUJbzIdJd0dxqdEiU4tLJK2oVNZl50taYYoIzL9u IMcoaIeRwCQc76PxYNARZNg1JEC6BAVIr9AgQ/QqioAioAi0FAIHtrq11Fkd+Dj0v63OzJWV2FZg 25pXaIiOWh61uxos9t4+ntIzJEiO6hAlPUKDzSJOcyCJzr+9Oza+ehht7mCEWlop/YA0T9b7BWma LMdn5fD/kXxqGQljmTmxH/+ygmRI3DR7UmtkYItlAvUCwbTDZyZQBv47L4zPB+OlmdULGpx5xeYH siYxWubWxnOwAmlCpOm6sdQui4AT/Z5F6DBiNEg8KGzKLZD1OQWyAQ8Vs9MypBjaYxuci+ZSao18 YCAZUlPuHxEmfSKCzVhUFAFFQBE4WASUBPeBXBUIY8mOLFmIbUVGtmyFeZMmzVyQXi7MmvR/DYgI ldGxkdIjLEgSQwONGZMmzEAEiQTCrLm/lkkeNwsmQ5oQ8+B3s14b3oMoqFGRxGpAcowA5VaDv82r 2fh5XTQoz8sQGEaE1ofFGHLcVc96jFOh/9D6rh20P4vY6jRBbCBFd+zD/dzxA76ayFG892jrZkgo FKRvzLaYK824wXyFdhsM4rJ8gbYw8/fEiFtjob+RflEGATFYaDM07LVZ+bI2O08WpGfJ9K1pwBTH hfk0DK80nfaPDDXa9eDocJC13tIHuxjo7xQBV0RAV4wmrjrNmHO3Z8is5B2yZGe2IaZ8LsxYoBkB OTg6Qs7u2VmGRodJZ2gmDPygZkdz5t6Emls6zIHctsMUmA6TIDeaBRkcw2jPShIaNKUqEFdVDTYQ GkmP2hMJmWoaUxW82rXFBk0NvkAf97biy8hNnN8T5MT3biAwkht1TfoOLSL2YFoENv5dzWAYnIOE RzGRpfUESaIsxzlLjc+PqRhVUorzl2MOJfisnD5BUyAZZAiiJLG51796kDDr31Pb9YKJl4EwMTBv xvr5Gv9nDLS6GJiE+TdNwJYwypSbiJ/56JhOsUbbpeaYj21bfqEs3ZkjC9Mz8ZoNYsyQKVtT8cDh YTTGfiDE8R1iZEyHSIn29XHFf9M6Z0VAETgABJQESQZYzDfCFPdHUrrMSt0ha2HmLKJPC5s7yGZE TKSMiY+SIdA0OiF4o86c6W60osZSp43tMsS2BaZSbpvqt+1FxQgmoeZWR2gN5Aaia7u7DbSndhIG Aoj2dMei3k6CcZ5AEFggzhXC9yA5fxAGz0qSoyZHza3uff3f/M6QXB0Jkt5sMxNMJmA9I5Lv/tYR 8b4+l7BuTtQY66JGSYhNvUcsqSHJPBJURY0hqXxEi+YDtwJs/DwX/tFNSPvgeWyJkiTpDk2SptMo P29JDA6E2TgQ5k5/856ESXIlxj7GV+qO/XykJ/yCx3fpUG9OrZJkBCAthpZO8+kCPLiszsqTHzYm GQ21O7RyEuLETnGSiGNbUbEH8O9Dd1UEFAEnR8BlSZBaD31507alybfrt5rgFn7GRZ9ay8ndOmLx jJWhUeHGzOcHEmps1jSRkyCzdAR6rMjMkWUZOeY4W/OKES1ZZVrJkBDrktd3S3uwT6S3h0T6tJco mAojvdtLJI4dhS0MGmZ7LPgksDpiqyO6xptFaJYJk0xnvd9d/8783bDDHm/3ejvvMb/6P/hiJdDz xxaBWvvyNDTBEjdrswiTf1tm2xwQYgYiRneWV2GrqHuPLbO4HIExRbIcROZWb3alZkq8aeqk/69f eCh8gKEmkMgTDyUkU0tj7BDgB99rtFw9CKSL467ANeA1/RNa/OzUnSDGTHl2/grpFRYsp+Cantgt Hhoij3Nw/lgnXw90eoqAyyHgUiTIsP5cLJRzoTV8sW6LzMcCyYor9Hl1RyDLhE4xRnPoHRFiTIq2 mh4Xe5MGAF/VBgRvkPC44JL8GBDDYJU22LgfNbVILw/pgMW2A6IdO8L0x1cSHk2RfxNbPdGR+Oop toHI9iA3aml1JHPEZI9T7f28lrbZFqkZHvXaJ6djEShfY+A37B1Yl3bxN1nW+TWzYWpOKqmQZDyU pEJz3FbMPMoyWYJtKcyeZN7d2Jhw3xfXZkBkiAxEYEx3+GBJhgzYoebHjaR4YtcOJmhoHa7Tn8nb ZRr8iGtz8mQ5rtW/5y6TEfDfTk5MkPEdY0zAjRLiEbur9ESKgN0h4BIkyOTzTbmF8snazfL9hiSY 7ipAcu4SB83imIRYOb17J+kJTaHxYkjSYyL4Fvih5qZlyl8wlXIhpY+KWpt7ffBIBxBeIsx33aG5 dPb3kjgs+N7QNIyJElRgaXXUoiwtzYrWJOkxWKUuftMxxcylWfWzbl5Gc2QgDkBwr9ctLa2Spt6u wG/X7hChidX4I+Gr3I6Hi61FZbIJmvb6ghJojhUyK2m7/AFNrxLk6YmI1QHwAY6Oi5RRIDaaPKlB WhG4wxEsw+224f1MKsZPm5NlyuZU40/8A+TIVJTTQIbn9+6K619HqCqKgCLgWgg4LQly6WVO2pKd WfL2svUyM2WHITkS30ndOsgZIL4RsRF7RBNyIc8qKzNBK1woZ8PHRHMaj+OL33ozqhE+uSFBvtId xyHxdQ3wkSB8Ru2OQuKzNRXWEUSdFnckFTl7u43/Jv+m7bTEjKZghvDwPbEOhi+0N7DevTvcYEh/ 42Zcm42F3EqgPZbL+sxsWYLgmCeg5TMSdWRcFCJ1I2Q4NuZkMoqUwTkkS253jxwIC0CG/LQpCffE TvkKpvAPV22UsUhnubRvd/O7GPgem0v/sDdcdTyKgCJwaAg4HQnSB7cZgSi/Q2N4f+VGY65klCBN X2f26ARfXweTnG4JtQ5Ga6ZB25iTmiG/ItJwPgjQDZ8HYRFmMMoEmN/6opJJ/xB/6RbgbepoclG2 FYvseDzH1ekO7WY6lF9b+Nkew3qYMA8W2Og35TYyPMj4JhmhuhGa4mr4YFchdSUZ/sV50PB+2rQN 16CNDIwMkxO6xMtYBDXRTBqNABwGx9CHyI2BTz9uSpZvNmyVpTty5ILvZkjX4AC5YmAPORbBNN0Q oMMAHhVFQBFwXgScigQZlEJz55vL1hptjibOy/v3kPN6dZFxWPRsa4lRu2Ny9hz4B6du3Q7iy0Dg Cn1XXjIKprFegT5GC+kJE2c4Fl5SmxU9uWt3XbI5RQnv8P3jaAj4sXngsIiRr9Tw+uHhZECwH8zO MZKDYKS1eSWyBqbTtYgaTUbAzb9nL5EHkckxGOksxyHQiVG+NJtSS2RKC02h3P6CpeDrDdvM6x0z 5svTXivkusG9ZDIsBn0QnKOiCCgCzomAU5DgepAfc8XeWLJWtuD9YPiBLu3XXc4B+TGk3hJGf65B 0jWT37+HBjAd2iI1vs4wfx0bE2IW1MEIq++J8mbMp6tLD6hLoVDCs49/AH8T499XpK44zm4JgI9v TGSQjI8OMXmVGwvLZDGCY1bmF8O3WCLPIijmsdkCq0C0nA5f4FDcJ/QF0jc4Fg9J3LbC//vZ2i3Q JpPloZmL5J0V60GGveVEpGUwUlVFEVAEnAsBhybBFBSm/nlziry1bJ2shAmzD5LYHzhqiHmy725D finwHy1DYvUfeMr/Djlk6TCXdoSmd3JcGMyc/kaT6AHiY7ALk9QZ1l/BMEYVh0DAVmOse2ip64zR A9e4L66tyQOFH3F5bpGsQn3XlYgUvQERo1HQ8k9BJOnEhBgZjFSYjgxsQvGD+0cPkvN7dZWPV2+S 7zcmy91T58j7URvkqoG9TJpFZ9wzKoqAIuAcCDgkCVJD+21Lqry0eLX8BvNn5/AQufuooXJWj84y MCq04cowleHP5HT5FkEQf0Dra4cFcmh4oJzVF9VewgKkf7C/ieI0VVqwUJZi8VRxDgRIjMzNtAgx EQFMfUCIVbVR8B8Wy8KsQlmC++NjaHpvLl0n4xOi5TTmhibEGe2wE4juwbGD5Qz4kb9Yu1W+RgDN bT/PlB9AmjcN7Ssn41X9hc5xr+gsXBsBhyNBVnZ5f+UGeWXxGpPcftmQ3nIZ/H6jECZvCYtbT0cY /TcgyAVImGZy+rkJqPgCU+egUH+TwsC0BIbZFyOfTMW5EWhMiAPw8DMU98L20ghZDs1wcU6hzEjP lpu3pMlg3Eend0+QSZ3jEVgTapLsHx0XbAKqeN+9s3wDIo5/lysH9JDTQZB9wkJMKT0VRUARcEwE HIYEqf3xafzFhatkPrS6gfHReCLvY7Q/q9XPOvj7vlq/TX6AP2c5Uhs6IJLzqh4dZGwkqo5AC2DJ MUYUlphO660njCz1Qu9AbrbCCjPV6ABRgTxGvqdw33aIRvXz85NKJOqXo0dfY/FFUr71O6sOqDv8 XJ6IgnWr71RRy+o2+H0Vgkes4/L8PHZJSUnDIXk+/o7f8Vz8DY/p7+8vbZsoE8cfcrylpaXmXBwL hX/znNZ4+Orjg9QDHKO4uPgf0bVH6mqQEFm6jlsIytOdHBcuE6NC5PiYUJmTmS8/p2bKvdPnG78g NcMzUSO2LywNLJnH1zG4716BBeKF2UsRSZxmiJJ1S5mo7281EmaJO7xnmbdYbGwcrKIIKAL2iYBD kCALWtP0+QoIsAoa3O1jBsv/9e9untIp7Dzw2ZrN8iF8OAvh9+sE/94tMHmOjGCUpy9aArVFMehd qAdqH1ofiWL69Okybdo0QzKWBAQEyODBg+Xoo48WDzTRrUE1G76mp6fLY489JmPGjJFjjjnGkA6F hMJ9/ve//0mnTp1k/Pjxhrj4my1btsiMGTNk27Zthog6duxojtu9e3dzTm9vb/njjz8kOTlZzj33 XENgJF4S1fz58+XHH3+UcePGyVFHHWX2f+CBByQ/P7+BnG1v55EjR8oFF1xgxsmxkETPOOMMQ5wc H8fJY7/33nuyY8cOufzyy813FtG31j8N+n6Ld2F8wGd4WKAMQMurCQiqmZ9VIN8ih/CxvxbLT1tS 5OI+iXJRn26musy5CLZixZoPVm4y5dg2sqKN6bcIekWCP8oMoWC4hwSABCNAftEgwUgU9mbR8Hik aTAqlaZWpmKoKAKKQOsjYPckuAYFkR+ctUi+W7dVeuFJ/EEEvpyKJ3SrueoPCFx4F2aq32D+9EQ0 xNW9YMrCU30PJLMzJ4xP/CzybE9CkliwYIH8+uuvhmRIUiSLrVu3yqxZs2TZsmVy8803G62KGl1h ISIWP/tMVq1aJYmJiRITE2M0P/6OmtuUKVMMQZ5wwglG01u9erX85z//MftwX5LN7NmzZc6cOea4 JFpqeitXrpS5c+fKOeecY45FYlyxYoUh3PZoAzV58mRDqCS/zz//XPr27SthYWF7kBe1PW4cB7VV ktwPP/wgnTt3lokTJ5rvSIIk5ddee02GDBli5mRPwtxOdsZgXVaaShkdTOvBb+k58tHmNLnj9/nG vH5p30Q5CySYiBJ7j4wbgnqmIfLcgpWyGEQYgW4YZ/ZIMOX3UhGIxbJv25CmwQpDGQjEYk6NF/Cl VsiC4ayDyjxE1kRllCrJUUURUASOPAJ2TYKs8Xn79HmyEOXKTobZ8/HxQ41JisI8Py5An63ZIhl4 fwIiPc/pFA2zp7/4IdiFbX7K7Iz8rMtrJdpTg3r00UcbNDqaJRcuXGjIomvXrg0kRC2NZktqde+/ /77ce++9DWZGHpNkSWLlcbkvCSswMNBoXNQQ+XlKSoq8+eab8vbbb8ugQYPMUPgby3xJUly7dq0Z D8nw4Ycfll69ehnCI5FFRkbKDTfc0PCZNRd+T6KkiZPEyX3WrFljxtCnTx9DmtRcP/nkE3Mui9xJ 0PYmjCy1yJAWhHhfTyTmB8rXSRnyLQKxFqOF0yz4mO8Y2R8d7/3kbBIiopCfnrscOYZbTd7p5MRO csOQPsY6kV+Oja/Y2DJrM/yPm7EPeyN+ifuWQpNpB0SlMndxNKrdsIwf/1ZRBBSBI4OA3ZLgn2hr dO2vf5kWR9cgGu8hROpFohA15c+UdHlyznLzdN7V31vuHN5TRiDak9VE2COvDIu2vYvle6P2ZJkL Q0JCJC4uTrZvR9FnmEppvqTZkNodPx8xYoT89NNPMnDgQDnllFP2MKVyvpb/bcOGDcYcyf1IUtz4 /v/+7/+MlkaTKU2vlpAMSbBPPPGE2ZemTxIgzaCWT5HHJonxd9zHtmKORZTcPz4+Xi6++GJ57rnn ZN68eYbIqZlSw73iiiukQ4cOhlTtWUiGtB64oyD4MJhJO0NzOxp5pK+uS5HXlq4x7ZoeGDMQvQ7j pB+0wRcmjTKtn56btwJFGsrkmQkjTGm+xrVI2T7L9EUEKbLoOos7zE/biTqmO0wAF6vXdPD3MxHO Z/fsIhOQutFUuy57xk7Hpgg4GgJ2SYIzkdZw5S8zJRUJznePGoBtoAQg2IA+nDeXrZHnF66WbTAx nRofIZcnxpo6nnTJ0O/nSGJaLdX7zEgM1I6o8ZH8aCqlGZSkwv0s8yTNje+++64xTZJQrEAXztsi JhLmd999JyRVEie1PB6/d+/eEhsba85h+eOoxaWlpcmTTz5pzJ4PPvig9O/f3xAg97FI0Dq+Raq2 JGj7nlrfSSedJH/++ad89dVX5lhffPGFJCQkyPHHH28uT2v7Avf3HmEwFq0JLJ13DHyFnfEQ9vam NPke/sIrfp4Fja+3Cc6iifNhmOmD4Qd8AAn2N0+bY5oTn5bYcY9T0TxPvyI3+gRZu/ZMVKTJQWcT NgueikCbH2He/wDl/n7D+15Izme+IqvWsCi4iiKgCLQ8AnZHgmxRdP2vs2U7zEd3jRwg94AAGf3J J+inUPHjRQTIsAvBXX06y+SOEabIMvPB6NdxBiGhREejxBvENhDF8u9ddtllctttt8kHH3xgNLbG JEWyu+qqq+T55583vr2goCDp0aOH8QPSb8hjW8RJ31xWVpa88sorhrSGDh3acO7GRMXjJiUlGX+e rSbH9yRbmkst/yBJl1rfXXfdJU899ZRs2rRJ7r//fgkNDbV7LbCpe4gFFFirlBrhnbjvaCp9bUOq PPrXEmHBhifGDzMPabeP6GeKgN/zxwK5/88F+Mzd1KzdmwTAesGNCfg0h94yrK8sz8hGKsZ60xNx UXqWvAef9zWDehlfuJcJwlFRBBSBlkLArv5FsZD1bdPmyiY8Fd8Ev8p9qNzBzg/5eFJ+aNYSlEVb LfFYiG7v1UnGRQWbQAaamJyD/v6+pJZZs7G2RfIaNmyYnH/++YYEGWRiaVfWr0lENGU+88wzhnyW L19ufHT0M9JP969//UuGDx9uTKc0g9J0Gh4eLrfccot8/fXXRoO8+uqrDblaZEfNkSkPJFZqpI2L h5988sly5513Gs2VQi1ywIABctxxxxmtlSZRyw/pKFpg439gfMaqRM3YQA83ORs5p51h/vz3yi2w TKxDj8lqeQkmUZo/b0Xbpgpcg4f/WCiPI40iCtqjbfWivf3DJcHFufuaIJmj0NeS5tKXYPX4FRGq V/0yS75DbVP+m2BPRRVFQBFoGQTshgTZ8PbZectNN/CzkJtF8xIJkJX+n5izTF5dvEp6I+jlLqQ+ DEOiM5/OqQE6m5CccnJyzLTof7PNzaPplIR0+umny+LFi02QDKNFSUy2JLhz506jdZHsaI4kedLP +NJLL8lbb71ltEKeh2RFArzyyivNvrm5ufLxxx9Lv379TNSqlZNIMqQ/8O677zYpFiRBWyJkIA0D YyzhdyQ7kuPPP/9solbp27RSOxz5mjFFh22z6Cv89+BEeXT5FgRnbUIx77by0rGjxBum01uH9ZMs dLR4ff5yeQWBM89MHNGQy7q/c6dmOSImQvqfHGKKvD8xZ6khwSU7suXR8UPkHPgM1V+4v2jqfopA 8wjYDQlOS0qTt2ECYqDB4+OGmuRjVnV5bela+ABXGgK8x5Q7CzRpD85g/iQRUeOyiI7v+RkDSiIi IkyEZ2PCsYJPaBa955575KOPPjIkx99yI3Fdd911cu211xrfnJX6EBUVJWeddZY8++yzJjmeJkz+ jr46Kwr00ksvNSkSjCBligN/YwXB8Ng0pXL/xoExJGcey9JgebtxH5pFSdB8tf3O0f9B1vWG3I0u I37y6MBucv+yjfIRclSZF/jw2CHm3r0BvkJ2s38dgTTD4yLkAvj2DgYDaofHoPvFoKgweXHRKnlt yRq5Cv5Idkm5GaZTz/piCI6OqY5fEWgtBOyCBBkt9xTCzNtDy7l/zCDpgqAB6njs7fc4tMA4LC63 9OpoCJAVX5xF/7PIw0p6p9+PaQoMKKG2R02wqUhKalT07zG/j/mDNFUyJ48LM4mTaQk0bTJwhoEw XHypHTL/kMTGiFRLk7MImOTKgBqSK4NjaBalhmhpmdy/DA2HSaC2Y7KCZ5qqJmORpaOaQPf2j5Ih WDV4GGOR7vv7dZHbF61HIff10isUwSx9WMA9UG6Dj5D9LN8EcQ1HcXfe1wcrwV7t5RFYR7ohof+h mUvkPphbWST8NphfVSM8WFT1d4oA6lvYAwg086zOykVR4o5yKlrcUFIRcPDc/JVSg9qeV8A8ehSS l1kr1BkIkKTEjf46BqVYyfI0g1ITo2Z26qmnGgKy0g9IdBZxkYRoFqVmR38f0w9siYn5gQxIeeih h0xQDH1/qampJpGdGqIVTEPtjcRmHZfkOmnSJFm0CC2E3nlHunXrJscee6zRVDm2Tz/91GiDtqRG Iqe/j77JxiXdeNzG5dPs4X5rqTGQCGmSZ8Pl23onyL2LUNMWhDcSml/HQH85HvVHL0ZLr5cQ0PU7 mv2yUsyhdqy/oHc3lGmD73H6XBSRWGwq0lyIajYqioAicHAItDoJlmER/XDVRvFF1OGtw/safwu7 w09BcvIsmEjP6hyDVIhwBMDAz3Rwc7S7X5F8SE7U+pYuXdowPvrNGPRy2mmnGY2OmiEJiJ8zsd42 KMUyi1544YXG18boTB6XZEif3+OPP25KnzHwhURFrZDl0Xgc7sN9+RmJy6o8Y5lemU/IIBdWsKHm R58fA3KoTZJIGwtNtyRlW+GxOF6ej+O399zAg71JaJZ3wzVihZlzu8TI+1vS5d0VG1FRZrDR0Jji MAXtvj5ZvVlO6NxB4pjOc4hyIjpYlOHh8Pqps+VhRKiyrimT7VUUAUXgwBFodRJciELXG3ILZWRs JGoyhpkZMEr0DUTddUYo+pkdI027I/oBnUWKiopMsjsT2htHWpIsSFpWRRWSHau+0JdnW1ibWFDL Gj16tMkrJKkxOMXSKhnAQo3SMlPyPDyuVeKM+9JnaCXdW9od96G298ILLzSQJTVHVpuxyLLxdeBv OKfGPsHg4GAzbs7Btkaqs1xHax5swxUEP+DkDhEyDd0opqKIw4V9u5qyaMNQEm0iqsC8sWi1rEKl mJYgQZ6XwWNMpXge9XTfWAa/+cSRB+VzdLZrofNRBA4UgVYnQTbFrcbCz3JT1AIZis5cwdVoh3Qe yqANDPE3LY+cSUgWJDmSR2NpTIr8ngRFAmzqO1tisyUh63Pb49v+3hpDU8EaJMrG59tbZCeP29Rx +Hlz43am68m5sCdlJ6TvnIm+hG9uSJFpSHYnCVKGIyn+w1UbZA7K/7GBb/sWCma5BVGov6L90zfo nHLj4N4wtx68z9HZrofORxHYXwRalQTp31uIZGBWghkeG27GXAZyYOWMcCQQs/8fxUny4PeL8Jq7 cE0RoLVvc9/t7TcH+tv9OVZTYz/Y3+3vDWwv+zFi1A+RnAPQsms3fNeLdmQZHzbTfPqh8ktXmCvn IdUhs6TcFM9uCWGlmuO7xJlcxWnbtsvVgwJMsIyKIqAI7D8CrUqCmaXlkoVq+6wJGo5Gt5QCVIbh AsJeb93RD5AEqaIIOAICLJXG+rVdgnxNsexkBHd1B/klBAZIFNopLdmZLQWIhG4pEiQmrEjzLsqs /YX82ivQ6FcjRR3hTtEx2hMCrUqC21EblEEwnWHGcUOxYko5TIRJBUXSDRX8I70RHelA8aBMPWC0 JU2RB5MTdqRuDGpnjBi1Gura81iPFCYtcR7mtfpCG4xBbdCteMDbCd82SZBl0RjRmYO+mKUIaGlJ 6QqTK7W/zXkFyJ1tySPrsRQB10CgVUmwFKZPmjp9EFTA2owUan6FFVXiju4Qvu5uUslGpXYuVsrD iy++aEqFMerSHloFscoLSdm2wzuhZLQnewuyFuhFF13UZLd6O4fcLoeHFHrxQC0/HxBhWXHFHoRn +l+ivFr1rpbtoBEIguU/nYLyKpxdWdAubwwdlF0j0Kok6I4QcjQAMtqg9c+Xn7i3RZdzfMAcrOYi Eu0JVYsEmeTOlkVdunRpMRJkZCY7PfDVivBkJOjefG2MCOU+LFrNnEFGe9qSMlMXmJ7x119/mYT4 xvl9zWHLc3IcJFEKyZUka6tJcqwssm1FqTIq1BorP7O+52ccozUu6ztqp3zPYCB+bxs8ZItFU9+3 /j2BcZsG87thlmyzh2mSplLkUiBPsM7i0VJiuQtYuJv/llQUAUXgwBBoVRIM8fLkuoDeauVY9Opo 0ANPzFF+XqYyTC6enEOgJdqTWAu+bW6dNT7mw3ERt130G5P4gQSKkMzS09NNkjrz/UheTIdgTU6S SXOVWHgO/pa5fSQsaz+LrDleHoua4oGMx+o7yIoynCe7Ttx4442GCM21w5hmzpwp3377rUnXYFUb JvTzPFaHCVa4mTFjhskdZIoIUzxIdNyfvRL/+OMPk5vI8mzMa2RzYf6WBMg8xS+//NL0J2TNU1bM YePexqXlWut+IQ+x9VIO/H6BKKYdgiovlGpEjpaiBq4nzKQtXeYsrajY5M/Go8mv4UEVRUAROCAE WpUEGSDgA60huaDY+AL9UTSYSfN90D1+LYJjklGEOCzUQxh5Zw9CErEtD8b3zS3A/M42R88iTysB fm9+OJIWSYYJ66+++qohF5ZRY2sltjyi5sZWRRb5NMbG0tj4G+bvkWQa1yi1nYctOTaFs20OIUu5 sbQaq9RQk7z11lvNT0iQ/Ju9A5mjSPKaP3++aQ7MAtrUDkl+v//+u6lCk5GRYUq+sdUTK85wXrNn zzbEzbqmW7ZskTfeeMN0tGAfRFa8+c9//mNKu5155pmGEOfOnWtI0F6kHe6Pgqoa2YLGukPjUWcV xETZDt9gFh706Pv2R8BXS8pypBPxeg+IDDVtnFQUAUXgwBBoVRL0wkLfIyzI9GRbj7YxEYigC8LT 8wREvP2OhOMVSKIfFY7KKXbgFrTqe1LT+eabb0wfPtbopLmRGpGtVkbCoWbD0mMLFiwwWg01F+bM PfLIIybJfV/mTJ6PGhG1HrZBIhFYJkQe85prrmn2SvO3NEOyryBJiucn6fzvf/8zFWpIHDw2yZXS uCB24wNbhEkypQZ39tlnGzMmfYrWPEiCxIa1SW+++WZDiqyKwyR7khznTxJkWbbzzjtP8vLyzLx+ ++030+mCif0cJwsDUHMsKCgw/srk5GTzPavfsDINf0si5Ph5DeylLil92ihqJNuKy9AktxKF4IMl xNvLQLkR9zbLALI9Umj9Zwf2z7TpvVmt5qdNzLPdJSd2jZe2ag5tCVj1GC6GQKuSILFmNY0/0Eme uYFj8fTMhPlxWCw8QZDzsgvkDFSMYTUO41NpRaFZ8ZdffjHmOi7OJANqOjTPUTsiSVEsfxx797F9 0U033WQWbPbiI0GwigrNhezU0Jz897//NQTC7gt8XbhwoSl6TeKgBsSu8k0l2lvHs0ywJFDuR42R LZLYKon9BHkMVoSh1sWxkxw5j6aEGtzLL7/c0IyXpEPtkoRuq83yPT+jFsdxW22aUlJSGiJm2cGe PRBJoNQAWZt0+vTphkit0mscKx8gVq5cafYheXIOJH76Wh9++GFTx3TcuHFGIyXe9kCEHhjHzrIK +Q15r3GoEcp72Qr2WozUiPS8QhmHDhNBsHa0lPDfzPztGSDcUBlUX22ppY6tx1EEXAWBVidBFhl+ et4y+WFjkvwLFTBCkQDcBW2Tzka/tA9WrpdftufI/3WNkdpWLp7NxZk1OWnqIyHRXMl6neyxt23b NtNE1iJBano07VELGzVqlAnwoHmPBbO5wNMPRs2nOeFxafJk/VA2pP33v/9tmuiSWPg7mgj3pwwZ yYgkRvIkkTJQhoE7PDYDY7Kzs814qJ2NGDGiyeGQ3EhG+4p25ffU2Gj+/PXXX6Vnz55Ge2P9USuo h+flmCyfJcdGrKwgGh8fH6M9U9OmJsgappwv8eNYiQcDeXgt+CDBfdk2qrWDp2iFNIUfcgrlrx05 ck6fRDm6Y6zBk6bQWSnpEgNT6EC0Q2qpdBSmF7HHYBHyam8c0ttEWKsoAorAgSPQ6iQYgyr4J3Xp YBJ+P1u7RW5EHzb2Y7u0X6J8tX6rfJu8U/qjdFp/VOpnx+7WEsskSE2QCz39dQwuoaZD86BtwAw1 F35P0x4XcJoG2Z+PpkgSAAmUC35zYvkTSV5sacRAmGOOOcZoclz8v//+e7n++usNgdCkyWOShJpb YDkG7svxUFsjifN9Zmam+S2P0dx49uUvtObA43OcJDo27+Uc+GBAQrf6JBIvS4Ok9kacSIrWwwN/ y1qm48ePN22fpk6dah48eByaSIkzm/9apElTa2uTIL1w7THXdYWl8r+NKRIJC8E5vbqIByO+IL+g LCAtHSxx1qOFilwXIIXojt/nywJogZeiS8WkLvGt9c9Cz6sIODwCrU6CdGNcPqCnfIn6h6+iDc0J 8G0wgGAwnppvR1eJB39fIG9vTJUH+3eRMJiSWquOKEmCKRD0Yd17770SHx9vzII0d9qmGFgkRzMj NUSaQLnwUyPi4k0CYvAIO7w3JzRV0rxKYmFUKH1sNItS2DqJrY5IpNSkrC701NaaMwtaJMfx0D9H 7Y/vSVQcDzU2jqkp4TkYnMM0C5Ipf0PTsJW2wfecH0mYryQxBuRQU+XDAudAAuPveAyOnwRM7PgA QT8gMaPJmOMnadLnx31poqXpliZUPkRYGiVxZMRoUz0Mj/S/SJJdBkjp7Y1psrmwzHRCOQldHiib cgvko5UbJADkf2piR2GD3EOVLCTh3/H7PPkCD4w0ud43epDJS1RRBBSBg0PALv71MDjm//BE++z8 5aa57qvHj8GTtJtcBLPSIvhYfoSplLVEb+mVgPqMSKBvhY4SXKhJCBQGmXDRX7x4sSEpLsZcmEmG /JyESZPnJ598Yj7jAk8TIRvckoCo1dGn1ZxQY+LveBySBKMojzrqKGPWpIbUr18/QwIkl0cffdSY K9llniZEW7HGQ78a/X/vv/++OT/Hz/GQEDk2khbJqzmhJmsRIE2R7HzPefM4fE9tjmZikh4/I2kx tYNaMwNZLL8e50DC5f78nsdglCvJjT5AaspsvcS/lyxZYvynfNggObJpMDVDkio1yJ9//rkBwwNJ 8zi4fyZN/4p+wCJEg36M9kk/JmfIsdDIbh3az/QMrMI9+j/U9JyLmp53jx8mI2IiD+nUdImvzMqR +/5ciNZMqTIqLlJeOW6M6VGooggoAgePgF2QIINhroNf4zdEhNIkSt/JtYN6mRqLD44dLGnwf3yE hYbV96/rHi++yCWsskmwP/jp7/8vufiTuGiStNoKcWFmuL/lM6P2Rs2IWhr7ApJ0aBqkFkPCoV+L CzrJlMTSnFjtlKhN0uxJfyBbElH7Yp4gzYI8DhvwkhRIOraBMiQFkjKjQDkWjumCCy4wATA8DrVK tlEiGZHcSLqWWbLxmHgsqxcgz89ozfvuu8/sxjnwPavk8Fw8LomMBBsTEyMXX3xxQ+QsHxSYKsE0 D6Y+UANlDqHloySJrl+/3uDFBwkGwbABcGJiotEwmXPIh4APP/zQ/E1CJcG2Ro4gTaDUAAtJgFvT 5Y0NqdI/OkwePGqwaZXEqM2PV28ylo2hHaNN01vLPLr/d9zfe+5EubUfNyXLk3OWCX2Bp3VPkKeO Hq49BA8GTP2NItAIAbsgQY4pGkW0n8QT87nfTpPH/los8f6+CPvuIINAiM8fO1Ju+HUOTE4p0AJr 5RoQYQRSKagRcsE5EkKS4cLNlAhulvbBxZ0kQfMeCYb7UQMjsXCRp4ZGbcvqIG8t2nuL7rTmw30Z QcnAGFshAZLkmDvHABRqnbYmWYtoGZFqjYdaFc24FCswxTJD8rP9ibAk+bAkHM3Clq/QSq+gWZZa G4NvGo/VOjZJlJofN2scHB/HwfEx6IUbxQp2sQiYfzNIiJvl++R3+zPulrw/GPHpRRMoypR9uDkd fsA06QlLxhO4d0ehJyZlOrS/R2cuEqYAPYbPe+H7teglmI8kekZy0ue9P5IB8luGyNL/LlwpM5K2 Swd0q79nzEC5Ff7FYCTjqygCisChI2A3JMipjMNT8wPQ/O6cPl9umzZPgvAPfSTMPkyZePm40fKv GfPlo01pqMhRJVclxktvVOuv3Y3efEeo36ClFVmLMP+2rcZiLejUvkiKrPRCEyi7sdP0d+mll+4z yrLxJbXqftpGQPK81AAZQELTITWnpjq3W+OxSM7SEG3HfaC3kEXitibIxsdtqpqORXrWfKzf277a Ytk4d7Ex1q2hAdJi4eHWRtYWlMr7m7fLt9t2yAB0dX/i6GHCKGfKfDSJvg9+7OLyCnl04gijrX22 ZrM8MnspLBlt5eszJolfyN77/tGXuBTkR6vIL5uTxRcPDxfANXANrCOj8e9BRRFQBFoOAbsiQbaB uWpgT8lAzzWmTVz1y0x588Sj4P+IMi1jXj9+rDw2Z4n8vCFJtqIqx7U9Osgx0chLw+LCzvNHQifc 2+JrLehcwOnPYz7flClTDFHRhEl/F82PBypNndMKDtlbontjX1lLEcfetK99nWN/8GvOx9eYOA8U x0PZ37P+HpuWnievrk+RtWiVRB/gg8j9o3/OIsDbfpsjW3LyZHLvruaz66b8hV5/aVKDTPq4AB8p xgNLU5KUXyRb8gtNQ+mv1m2RpakZEgJryMndOsoZPTrLuT27ijsIWEURUARaFgG7IkFOjSake0YN MNX2/zN/hVzx05/ywqTRMglP2kNjwg0R9gwNlteWrpV7lmyQTd3i5PSOEdIZ5tQq1B89Ulrh3i4D SYJmUvrKTj31VLMroyX3J7fvQC9vawWFHOg4HXV/lkLzbNcWJfwq5MfUTHl7U6rUogj2jUP7yu0j +kmH+tJo7CT/wKxFsiQ9U/ogcZ2lAJniUwq/oReCudqBv2gOpTZIyUNVGVZK4rYiM0f+QirQ7LQd UoPPu0WFy5U4/rGd4ky0tLdGfzrq7aPjdgAE7I4EiRlriD40ZjAWjHby7NxlctkPf8jjE4abAINY PB0/CfNTX3TrfmreCnl99TZZhiTlsztFybjIYAlE0AnzCe2g0tphIz4HuK8cfojUuXwQgJWPwtfT d+bKN4j+nJWWJYmo0XnbsL4mmtkdhMb2RR8hCObJOctlA/x+wSiSvb24RNZkV5oIZ4vA2rTdLRWo //fxmk2mdNoSRD2vwf5rMnNFcI6EiBA5vXsnGYjjj0bqg6VdOjyQOgFFwM4RsEsSJGZ+IML7Rw80 HecfnblYbvhlFhqHFsoNg3tLNBLsLwAhdoW/5b0VG7AIbZYVizfKCfHhclp8hIwIQ6NRPMEziOZI mEjt/Brr8A4AAZIfOz3wzlmAsn3fQ/v7PjlT2uCzywb3ksv79zB+ako2imK/sHCVvLNivWSXVogv 7tkKVDaiMJJ5T4E/EergU7OXwSxQJf7QIHuFBcsVMP/3AwH2RcDMALzyvldRBBSBI4eA3ZIgIWBy 8U0wC7FNzMPIj3oSZLgST843G1NRrAxFUEIfaITHdY6Tt0GG3yGfcDEWrkmx4XIsfIUDUGmGwpwt JcMjd1M54plM5RdqdszHg79v2o5cmZKWKWnoZDIRvr+rBvSAabJDQ2L61xu2yceocvQTKsLQwOkJ rXFvTW15/9FMziLaZ/bsLN2CAxDt6We2lm6v5Ij465gVgdZCwK5JkKBwcZqcmCCdER7+1Lzl8tmq jSBC1BOFOYq5hNQKT8X3TKU4GYvUG0hQfmd9svyJGo4jI4JkUnSoDA4NMA1Oq+BnrG9b2Fp463nt DAHW/WTZM3aAWAyz+rT0HJmTmSdbCkqkO1p6vTh6sKn2Yvn+WLHltaVr5I2l6yQT3SEE5LeLWl9t GxR/r0vt2KOweKP5DowKlRuQE6uiCCgC9oGA3ZOgBVNfmIpenDTKtFn6N/yEj/+1VOakZRjz6Bk9 OhlfISNLx8RHycyUHfI+yPJjhLH/BX/OEJhHj40JlaGhgeIP7ZKl16z8QtUQ7eNGPJKj4IMVq7q4 g/zoP/5zZ77MwEPT/Gy0PEJkMk2TL44cKEdDa+sNS4Ml1PpeW7waHU9SpVNggLx02gSTz7oNkZ0b cgpkdXauyQcsQg5hOwTTtEMADX3TVjcJHmcHcv8yQaQRKBSvoggoAq2PgMOQIKEKQ0DB5TBLDY+N kJcWrZa3l683iw4XpSvw+bCYCOkRGmS2SYism7t9p/xv+Qb5NgUNWDPzpau/jwwDIU6MCZEERJOa vD9zDWDIAhsqIbb+DXk4RmASC6il4X80XZKUtsOH9/vOPJmXlS8bofVlIfd0CO6fB8cNl7EdoqQr zJWWrEDawv9wr/24KUnSi0rlkr6JJjqU1gdLcpEXmINWSnl4TUMx7XVIk1gLUl2RkY1egiWmMTTv r0WIHs1D0QElwcNxpfWYisCBI+BQJGhNjwEFzyARmX7BZxAh+t6KjfJHUrocD98NE4r59M6aitzY 0mYJutR/tm6rTNu6XZaiUe8PCHboja4UR8NvODQM3b6hHVoEyFeTy3bgWOov7AgBEp8xTdqMqRTV aZblFkHry5VV+cWyA0S4G9rg8V3i5Kzunc3DVRw0O0s2Imn9NZQ+m7olVTYjh68/NMTnJo5Euk6c KeRgKyFensKNMgJdlCpqOgi7PTAtguS4ITdfliABfiea7lJDVFEEFAH7QMAhSZDQBSCKjknEI1Cq 6uctKUYzZJTeb9AKT03sJFcP6mme5tmqKQY+w3EwozJ3a1pSmnyCaNKp8P3Mw5N6MEpY9QUhjoL/ cBDMpQHI6eLiydg+Q4hKivZxp+5jFLakx/c0Q/JRpqiqVlYg0IV+vhV5xZKDyMySml3SET7mu9C9 5ES08eqI4JRAG1LjffIG/H7fo17nNvy2E+4PViw6pVvCHiS5tyGxKXSkLzdvsxvN9Gf3rDLRo8Eo +aeiCCgC9oGAw5KgBR8DY67EYsaehF+g0sYbS9bJm0ik/x6RotQML+zTFblXYYY060LRQ+QSlKBa CjPVl+u2oSZjmvwKzeDPjDzxBQEOQEPf0RHB0j/YTwI82iHYoS18RzCjsXEqGNEsrqoptvrda5Ge Zd5kwFMN/sM4YBa2ZoTnbJjAl0PzL6yuRRGF3eKFB54JnTqg319nYzoPQ04ffYOUGviJaVp/F1HG 7NjOQtURILDHxw+Vc3t1hc/Zp2Hfg50878EA5b+DhU9/pwgcFgQcngSJCpcxkiHTKc7q0QUJyRvl U2h7nyIxmVU7hoAErxjYAzVIoyUAT/zhCEpgrcejoR3mwlS1AInLv0Cb/AsBNbOyCmRmRr4hvi5+ XjIAkaWDQIyd/L3FG1GAHvicSdLQF82Cy8WXGodGnR6W+7PhoOQqNKwyDyM0chJzVggqB3mVQ7tK RirDMhAeIzy34j27jKBsj3n4mQSTOB+SRsVHSig6ZzCdwZJCaIZzU3fKO+j7Nzdtp1RCS4wC+d2L Pn3n9+6CwBc/ceNJVRQBRcApEXAKErSuDAsc84n9zhEDECnaS35FNB8T6RfvzJLZP+yQzjCP8qme GiKj+liZhuR5OlrTnNINPhwuiIg4nbolTeaha3cSfTlJGfIBugX4ItqvD8xiA0P94U/0lyiYtFiz lC1ymOfVvr6uI6NO64gRWuMR6nDhbHemRXR8JfGRAEl4jORk5xDWic2Ar21tfgmqBRXBv1dktD9P +HbbtXWTEF8f+PfC5QQSHxLb6b9jJKglxajfmg7f3NStKWhOu1XWwSzOcn3sBnEpkuGPh8+P/j1L S3Q2fHU+ioAi8DcCTkWC1rS4eLHVDKvKnNWziyzckSnvw8z1V+oO+Td6sj0xZ6kMhznsbCQtj0Zx bvptSIihWPhORcFibuXVNaasFUmRhLgOOWHrSipkMfxKJVUp4gdS7I7ecT0DfaU7ull04jFgPmWh ZZKiJ0iRJEmhCfVvclSt0bpOttodr5lFU0bDsyG8IlyLJBRM34Aoy3WI5NyI6MtCfOaNEnksSxaA qOEhcYHQ9KJMl4XeqC3r06hdUQlKk2UgNWEO7oHvkeg+C9ofdcoQ7/Z4AOool/RLRKf2KFPqTEUR UARcBwGnJEHby0dNbQyIjtsWlF37BgvgDPR7Y7uaG6bOEW+Yxo5BOgXrNvZBcnQYyrRRC2C1miGo SMPtFtSKZKTfYkSZLkCIOyv9p6HwcQY0x80IsPkQLXVqYJKLh/m0GzTRBD9v6eDrJXEwuwbiOCzA 7IXz0JzK9yRKE7xBrRGvdb7Geg3SifyNe/rt6kyZJDpLw2K+JjW7MpggSXrcCitrJB0a+Dbk06Ug Z28LUhJIgG7Q8Pw9PczDSkxQgIzw85X+SDwfjqLqg9HQlmbOxsJ0hWwca01WnvyMlkQ/IdClDNeJ 6QkDYCKfkBArk2EF6ImUGhVFQBFwTQScngRtL2sXmEPvGjlA7hjRH/laWaZbN/u/zYO29zl6t5H8 RiNHbAJ8h4NAfowsjYJpjUQaiAX4GKRkcKNQs6CmuBoLLBfZTXn5kolFe3NZlSyBma4QpMl+foFY tEmI8dg6ghyjoXmE4Vh+JEeQohcJ0miOfG1rSnfRH1kXlbpnII5FlvzSNnKV4zncKR2WV8xKO9gj 98746epSEqxAFfrtGGxC02UptnKz1SI6kp/VIkKzRrLKq2UHiIoJ6iS8bSC8wspqcYNpknj7o49e gLePTAgNQaRvoEl9YZk8psjQ19dYeL4dMHPuKCmV5SiS8EdymvyZki55ZZUSg4eTnvgd634aMymi itXX55qLns5aEbBFwKVI0Jo4NRHmhHErR+QgzaRMuF+FuqSs6v/LxmSp2b0LWgYb+kab/Vi/NAJE FuXjbRZ7X5jbaFLlZkkqtEPmlm1DiD1D61OKiiULRZbz0R5nFYI1ZiLophjao8CU1waaYRSiEyNA ihHwL0Zg0edrSHt3LP7uhhRJiGaDP8v62wPv6d+i/5NkySAdE71anxFnkaNh0HqxJcjGZGkb8rFH +Ed9jl0duaEqGEyUNTgmN0ZaMhKTGwNQSHTU6iyfHbU7BqwUw0+Xh4eBTGxZwCADhJeJaioZeF+L 71BWRXw93Y3PLhgPIANi/CQcmBDrzvC7JiCNoSsa0HbCa1PC4Bg+eLADexqiORdCS2e1oAV4sKnF 9UuAxtgnrC4imFrfRGzalkgXQEVAEXB5ErQFgL3emPzMjdodE+sZLcr6pCS0l5eslqdmLZYoLMoD USFkAFrd9EIABZOqY2CSYyAO65JSuHhzs5ViHDMZ5JgKYkwuKDIBGSRGmuoYiEMz68bSKlkIXyPf 78b+aBNvalL6gBDZGoq+xiC8DwA5MrGfJlxLi/QGkXi7gyQxhnYkRaR08JUkSeF/+bf1nikfdYEn OE09qVnjJdGxgo71Hb8n4VUzGIVRmCQ3mBO50azIv9kktgCEVoBxF0CLY4AKcRSSHH2iGHdQ+/ZG cwv09JSufv4yBH8Hkfhhloym6RgRmCwkzeIGfo18ebZYcjys2JKOVkVMYaAmviIj13RhT0cyuxeI lIWpadruizSX4dD2mAqxt2PqcqAIKAKujYBLaoLNXXJqd0yq50ahmZORpSux0G5ExQ+2cpqC6iG7 EZkYjEW7f0SYyT3sgVJs0TCbMrSeQTbcLL8XF+A+MMNxsxVLi8ksZS3JCskyryTHSpgEKw2RFINU SDJ8TzNhegk+ry5BGD+jJJH7xrY91gbNx5AOTKtt8WoRs9XhwCJBapHUHEl0JDhqcJbwmCwkTSHx 7eYxYb405yDRw3TL47cD8bavJ2JvEDQ1V18fXzwo8L2H0ZL9jEbrgf56IDtvb9MSKwJaNNNT+Lo/ psid0PCo5RGj9OJSWY/gJGrrbEKbDU27Lci0M9JXaB6lb68//HyD8aDCa6KiCCgCisD+IKAkuBeU 6IMyBZT7iSl9Rc2QZLgFpbc25hfIZvz9yuIdUo1Fuh0Wd/qtqM1Ypjz6oYxfEVsEIhhtTXGkIYsw mxtCKckP4fxF1LBAvMxpo2bJyFWaHivwWmY2kiI+o78NvjaSGf1jll+Rn1H4dzU+J8FRSJR1fe/4 TRtjeiU58S8PBKLwe/osPaGNMrCH+XV8ZToBA4f4yihM479jIjhIj+8bR2bu60bkHNibjyXF2JCW fr0kaM1bkfqwFRreNryvgAboBgwTUdVnVGyUdOvXw1QESkRPSX4Wju9UFAFFQBE4UASUBPcTsVD4 qkK9Ixs6fpOQuEAz4jQJps4kLNhcrDeim4DRFkGMbaERdoR5lG14mI9I8x+3ML5SO4KP0WhGWMCp WTUWkgm36L/LWe7XaI2Zs57oSGi2JEhyNFpeEyTIACCaUQ0J4n1L5slVQZvMBNGxFRHNweYVW2Z9 V4Ud0PRSYeIk+dUCO4HptBOLFKBbw0iYNU0tWPgG+YDRGb4+mlNVFAFFQBE4VASUBA8SQfq4WI6N G4XkQpMdTXjcdkBz2YoFnSS5DdsSmFWLEepPf18bmAbD602EJERqMawnyeAQBolwYy1LLvTW30GM KN3PruMkMjcbUrWtkHKQ093rz0pgsmXwD4tF87UAr3nY6OPMgwZdAPMuK/NkYcsug0+U5l8Q4S68 0i7ri3zLOPhXqdWd1KUjyK/uoSEaDxGMzqWZuamHhMMxFz2mIqAIuBYCSoItdL1pOqTGZzVf5WEZ aEI/Hxd++vpIEsxbY1AHoxnTkPy9HYnfTNMoB2lKG+hgMCl6YTM+NZAefYokP/rdqBWaZHyYJ/3g i2OyuI/Z6syTvviMJkpqcCQNyy9IrY7mTQqDZOq6oCN2BRohN8bQUDukGdUidH5ey4hPaHD0SZbW m15LQXhl2EoR+FKX8lCD99XGZEtTbREIr+4VZltsgr8pnjANk+jY97FfeBgCi3xMUFE4/IMkez4E sFUW/YVWIE8LXRo9jCKgCCgCzSKgJHgYbw761xj9yM1WmCRPc2oRNuYTWr4+alH0jdVt0JpgFuRr BvLeVuM1H5sw8pLBLNT0TBAMS7axfBte8RkJj/5GU9+0PkKU42D7njoTaB0JUpjKQPLjbkx3IOkZ 8qY5tb7xsIkMrQ/EITHuIlFyY7AMf2iiPkFgNPMyvQEpCTQdU7sNpcYLUmvI+SOZmyLSda/7Exxz GC+PHloRUAQUAVESbIWbgJqaZeaUgH8OgGRDDYsBMHUpCXWv/MzS2EieJdUIlKnXwEw0KTa+kmQZ NMPozzqyq4sm5XlJvCsQYck8wp7hQYagSYDtTSWbutuBBMqAGZKUKUtWr5H6Qjv1Y/QnNVG8Z7sg 5i2SfOuCZepf6wNnSMgqioAioAjYMwJKgnZ4dYz50q1OW9ofodZWl7zO17qgF5pirQLedXVL8SkU t1TU3rx2yl/mbzaI7Y6SYfyKWqMVCGPqeJqNWRd1yfnUIC3z6v6MSfdRBBQBRcAREFASdISrtI8x kpyYwgfK2udsaCqlBseKKkxSZ36jiiKgCCgCroqAkqCLXXkm2luaoRUI42IQ6HQVAUVAEWhAQElQ bwZFQBFQBBQBl0VASdBlL71OXBFQBBQBRUBJUO8BRUARUAQUAZdFQEnQZS+9TlwRUAQUAUVASVDv AUVAEVAEFAGXRUBJ0GUvvU5cEVAEFAFFQElQ7wFFQBFQBBQBl0VASdBlL71OXBFQBBQBRUBJUO8B RUARUAQUAZdFQEnQxS691WppN8qn8b2KIqAIKAKujICugk5+9dnDcBW6RlSjsDZrjLKDO1s37ULt 0JkpOySlqNi0TmIR7T7hIejn5+XkiOj0FAFFQBH4GwElQSe/G8rQfunWaXNNiyVfNOWtQksl9iuk PDd/BYppt0VLplrT5PbJCSOUBJ38ftDpKQKKwJ4IKAk6+R0RhHZMkb7e8tvWNMx0N1omsU0TWk6g TdKW/EJTTLsGvQl7hwWjq4Svk6Oh01MEFAFFQEnQpe4BLzTFvax/D5mblmGa8tIkavrHs4cg3rcl CaJJ7rgO0egCr6ZQl7o5dLKKgCKgneWd/R5g/8BhMeES4tVe0otrzHShBDYIfYV9IkJkUHSYs0Oh 81MEFAFF4B8IqDnUBW6KUG9PmdQ5Xj5cvVF2oeO81UGeU6+prpGh0eHSPyLUBZDQKSoCioAioOZQ l7sH2En+5K4d5MNVG2kFbRD6Az0RLDMgMlS8YTZVUQQUAUXA1RDQlc8FrjjNnzR5dgz0ky15RQ32 0KraXUYLHBEX4QIo6BQVAUVAEfgnAkqCLnJXhMAkenK3jvLCwlXICUSqfJs2sguBMv2gBaop1EVu Ap2mIqAI/AMBJUEXuSm8YRI9NiFOXiIJYs618A0G+XjLoKjQPXyELgKHTlMRUAQUAYOAkqAL3Qjd QgKkf2SYLNuZLVXQAofFRMjY+GgXQkCnqggoAorAnggoCbrQHcGk+dMSO8qi9EyTH9g/IlgSQwJd CAGdqiKgCCgCSoIudQ+wJmgNcgEpbdu2kYHwAbbDa6C3jwyMCjNmUUaJ8n9MpLdNn3ApoHSyioAi 4JIIqCZox5edBFUOs2UZcvnKqqux1ZqqL5Wo/1mNyE5Gd1aB4Ph3Bb4rq6mWcuzLOqG19bkQJED+ xti+QXLbi0pRL9TdBMb8kZwum/PqSqcxWIZdJdzbuZli2m4IKWVqhV97d/FBRZn2+NwDv2fJtfZu buKOVw+8euJzpldwH1an4Xs3HFtFEVAEFAFHQEBJsBWvUimIrQB1OwvQ6cF6La6qkuKqGvNZLgpd 5+H7/PJKySuve1+IrQT7lNXUSjn224VjCDcQpoCQBMRkXuuJiJqdqRVaLyQ61MyW4spqmbI5VTgG CkmxCsespdbI35IJQa6Cz8wG7VHYeskDhOfhId44hw9yDP1RmzQY1WhCPD0lGBGowV4eEoT3QZ7t xQ/f++H7QE9s7dvXveJzFvJWUQQUAUXAHhBQEjzMV4FmxoyScsksKZPM0jJ0cKgAmVVKFv7OwLYT n2Xie77nVlteAdKB5gaiaAvC8Afh+EMbCwCJ8JWtjqhtUQPjRlIzmzv+dmtnNDZ+b5k1qZV54DNL N+Nvikim0BbjUTCbmmY9C0olyK4GxGfSJ0CC/JtaKPepwPsKfFcOjbMcGif/LsdWiuPklVVKUkFx 3XHZpgmb4HMSclsQY4Svl0QhEjUCPkn6Jfk+DJ+FenmajTVL+V0UNjXHHuYbUg+vCCgCeyCgJNiC NwQJILWwGD37ykzfvh0lpbIdr2mFJZJWVCLb8ZqHzwRaGEnOD0QQ4e0t4b6eJmk9HH8HQ4sKgPbk a0N81KiocfmBEH2hidHs6AmCIeG1BmnQ5EpCJBGSBIsw7yLrFXMrxt/F+LugstJosVmleAjAtgWm 13ko5F0Ishd8J9QYQXwxaOMU5+crcQG+Egtijq7/LNoPn+NvapUqioAioAgcDgSUBA8B1a35RbIV 7Yi4uG9FJZakwiKQYAkKVZdKBnxvQq3O20sSgvwkPsDPpCfEYoGnNldnOsSGBT4I5kTrlX47exeS MLf9Efo12diX2m8+8Mgzpt0KfFYFzbdU0kGIqdAiN+UVyNStqbIbmrLgASAShBhNYgQJdgr0l05B /tIlGFtQgHTGKwuDqygCioAicKgI7N9KdqhncZLfr8nKk5WZObI+J1+25RdLKrS7VHRmT8MiTvNf MMqSdQ8JkokJsZKAhbtjoK+EQ9ML8/GUMJBhKDaaNF1J3OBLZAFvbiIB/5g6NcYcEF8O/J/UGNnw NwXaNB8wtmGbvz1DfkDNU0TsSCzw5cMEzbjEt3tooPRD4W/2QuR5VBQBRUAROFAElAT3ghhJbikS y7mty86TZJBdCrY8fM5FuTfqcY6OjZLeA3tJj7AgiaSvy9LwoN2p7BsBEzyDLQEEZytGewQ5ZkNr pK90Q26B8CFkdVaufLluq+xCcFAAzKUd/f2kI7TEniDEgVHhMgRpHx0aHWvfo9A9FAFFwFURUBJs dOWXZeQgdWA7EsqzDOmlw2S3AybOtjBTDkVfvkv6dze5dixGbTQcL2p41HJUWhIB+gG5dbbRHnNB iHVaY4XRFpfjWlFTnLo1RX7YsFWiQYgMruG1IRmOh0bOVwb6qCgCioAi0BQCLk+CjIJctjNHpiel yezUncYEx6AWpirQtHl8pzgZHQ9tDya3MPjyaNbUtkOt848pBD5UbokhIqPiImVyYoLRFLNhRl2X nS9z03bKX9i+3bBNft2SKu+s3CAJAf4yEl0yjsV1HIoycZrD2DrXTs+qCNgrAi5Lguvg1/t2/TaZ kbTdBLMwWKMKEY+sp3l5/x4yBsTHcH7mwDEyU8X+EGBwTry7r/ERDoLGx5JwDMBhSso8aIhTNqeY V2qLH6zcaCJPj+4YI5O7d4IvEUyqoggoAi6PgMuQIDU+hvL/DtL7ZM1mY0ozOW3ICR+MTgo3De0j 47FAxsDPxIRulhZTcSwEmJjPrQOCZwZHh8nFfbqZPMy/UnbKz5uTZX5apqzKzJUPEGjTFyR4do8u ckKXeAlAEn9rpJo4Fro6WkXAORFwehJkwvdGpDB8tnqT/ALNgIsiw/Z7hAbJrcP6yqTO8SaghXl5 aipznpuc15I9FLn1xLW+oE9XE31Ks/dXa7fKHJi+mbP4xBwvOalrvJzds6v0Dg82BQhUFAFFwHUQ cFoSZP1MPvW/vnSN/LZtuykHxnJep8MUdlHfRHRQCNmjsorrXHLXmym1PBYg4NYlOEAu6ZMoqxBp +sXazfILfIfvrtgg76/cBEtAtFwzqJcxraoJ3PXuE52xayLgdCTI0HqmNLyxdK1M35Ym7ojqZPrC hTCNndItAXl7XppT5pr3upk1jdyseToiNsJE+943ZpD8uDHZmMh/T0qXX5GwPwY9Fm8Y3Nt8z0Ac FUVAEXBeBJyGBKn5LUCfvBcXrZbpWMjo1xuOIJf/Q5DLyV07YuGzr6lmZ2dLWloaqoehfFi9eEJT jY6OloiIiD3uuIqKCtm0aZP5LjQ0dI/v2P0hKSlJ/Pz8JCwsrOG7KkS3JicnS15enkkRCAwMlI4d O0p71CC1hGMoLi6WhISEPdII+BnPFxkZKTExMbILWvS6deuktLTUvLcVHpv78djVKMa9ZcsWVEPz lA4dOpi0EltJTU2VwsJC6d69u7ij60RrC02mjPa9fEAPOb93V/gNU+T9VRvwEJUlk7+aKqPjouT2 4f1MJKpqhq19tfT8isDhQcC+mOEg5lgLElgNs+c7K9bLW8vWm6f847t0kEv6JcqJeGXLH3uUN954 Qx5//HFDbKZgNciFBNW5c2e5/fbbZcKECQ3DJrH069dPLr30UnnzzTfFAzVELeHvrr76apk0aZL8 61//Mh8XFRXJq6++Kj///LPk5uaaz4KCgsw+N998s3lPee+992TGjBny66+/otZ1nS+spKRE7r77 bvn+++/l2WeflfPPP998dtRRR5nzeiEvksRre/7/+7//k4cfftjsd8cdd8jWrVvlu+++M2RnCcnv vPPOM3/+8ssvhpTtSRhpelbPzogcTZBpsCAwmpSa4alfTDHm82sH9UbZuxDTjkpFEVAEnAcBhyZB pjZ8heohzy1YYcpt0Yz1f/0T5fxeXe1+saJWNXLkSEM0JMEadGqgpvT555/LddddJx9//LEMGTLE 3GkWQZFYjjnmGENMtsLf2yaEv/vuu/L111/LJZdcYsiLRDl79mz53//+J+VoyfT000+bnzf+Hb97 9NFH5dtvv5UnnniigbSorfr7+xui69279x7aIMdNbdEi2ltuuUXOOecc+eyzz+SBBx5A96W6W+zL L7+UzZs3yzvvvGN3BGiLJUnuBDw8HYeAKVameRcPV+8jmvSnTclyy7B+RmNkMr6KIqAIOAcCDkuC zP96aNZimYGeeL1QwYU+nCsH9jRteRxBSEwkj8GDBzcMd9iwYXLKKacYknvrrbekV69e4o3aoyQa mkhpcnzyySdl1KhRxtxoCc2OtiRIsrziiivk2muvbdhnwIABEhISIh9++KE5HsnJIkGSLD977rnn 5KOPPjLkRe3OOiY1P2qB/fv3Nxrp3mTixImGfN9//3059dRTZeDAgUKz6yuvvCInnHCCnHjiiY5w eUzKxLm9usgxnWJhZdiA6OLNct/0udASU+FHHCzHoBqNiiKgCDg+Ag5HgmzT88W6LfLIrCWmW8OF KGN2C1IdGNHnaNLYv8bx0yR65ZVXyr333mv8eSRB+vdImPzs1ltvNdra66+/vodZ1HbuJK0VK1ZI VlaWhIeHN3x10kknGTKtRVEAkiD34/n4N0mXBElz5jXXXNNkqTFbM+jesL7hhhtk2rRpxtxK4iSx UvOlmbexn9DerxkDY+4c0d9ohi8vWiXvoQrNBd/NkPtHDzImd0acqigCioDjIuBQJMhans8vXCkv L1xlqrk8NXGEXAPtz9mCFqht0b9GDSo2tk7jIBEOHTpUbrvtNqOpHXvsscbs2FRdzMsuu8wQJYNb aA7t06ePUBPs1KmTUFOzhBogj0uyIrmOGzdOrrrqqmaJimTZWEiMjcfA89AsSpNqz5495YMPPjCa KTVbR5W+yCF88bjR0jc8RJ6bv0Junjpb1uXkyb+G9zdpFyqKgCLgmAg4DAmyzNndv8+Xn5DoPCIh Rh4YO0SO7xznmKjvY9SM9KSmxihNS0hAjKi88MILTSDLY489JjSf0kTaWEO7+OKLjQ+PAShTp041 QSo0Z9IcSS3NiiL18fGRJUuWmPPwWOnp6TJ//nzjd7QVnpf73HXXXcakyvNZ56Q2SxMniddWLrjg Avnpp58MYZP8aF51NC2w8WXyxjW5EZWFmHLz1Nxl8uaClabk3r+PHoa80z2jdp3yxtRJKQJOiIBD kCD7993462z5Y0uKnIbAhCcnDEdx60AnvBx1UyLhkPRIhrbCwBVqhvfff7+cddZZ8vzzz8szzzzz j3QDks3pp59utpSUFFm1apX89ddfRiNjuoUVGEMiKysrk3PPPdcQ5OWXX26CX6g5Mu3BEu5HrZF+ SNvP+T21QFuTq/UbRpEyEnXu3LkmerVx2ocjXzz2i+yI0myP+PrIx8vXSVl1jfz32FEyAL5pFUVA EXAsBOyeBJNgAr1t2jwQYKqcj5y/p0GALITszLJ69Wrx9fVt0Ngaa3o0i1KjY2Tp6NGjjd/QEhIo P6fG2K1bN0Nc3E4++WRjDn355ZeNdsbj009Hnx21OB6D5MqgHAaxPPjggw0+R+b/cf/77rvPHGN/ hRogSdORzaDNzZUm0P8cO9JUHfoffIX3/OEmL00aLd2c+OFsf6+77qcIOBICdk2C7B9Hs9PUjdvk TJS6eu6YkaZfnLNIU+ZB+uiYysCo0eDg4Canyt/Rd0ftjrmGJLPx48ebfWm6ZHoC96FWZyvU2BgI Y6UtkFyZM2iRKHMTabZ8++235eijjzabpe3R7Glrnt2fa0Dy5O/46ozC6kP/Hj/MdB95f9k6eRx/ vwS/IQs1qCgCioBjIGC3JMiuD99tSJL3l6yRMegF9wyCYJyNAOmDW7p0qSEs2zxBaoKffPLJHhpe 40hSkheT2mnC3LZtW0MlGFZrufHGG42plITKABqS3PLly4X5g9QIuQ+FJEiCounVykVkwv3MmTPl oYcekh49ekhUVJQxefJYK1euNKRmGyDDcTPhPz4+vsk7vqkIWMf4p7F/o2SB7keOGiJpRSXyGUqv sQj3nSMH7N+PdS9FQBFodQTslgQZCPP47KUSE+gvD40dLAlOlqBMYqK/7Mwzz2wgJGpoXbt2NdVe bPMHSVYknsZmUSbbkwRJhrbaFj8j+XzxxRdmo1gVYxi1aQn3aUxSLMv2yCOPyEUXXWTGwfckTVZ8 ufPOO/9RMYZjsirGNL6bmxt3q9/1LTyAePgHHx03VM76+jdTjHsUelGOiv3bp9rCp9PDKQKKQAsi YJckWA7t4vO1WySlsFgeBAGyz5+zCYNFjj/++H/UDmU+ILUvW6FP7YcffvhHcAm1N1aXYTSnrSbG qE9qg8wLZJoFiY5lylgj1NZ/yDJsZ5xxxj+iNnm8P//80/gEqaXyePy7qdqhHCc1waaEwTAcNyNY nV1GgPTuGjlQbp7yl3yCtl1Kgs5+xXV+zoKAXZIgw87fXb7edHm/AsnwztjwlASxvxGTJC7m2zUl jCBlVZbGQoLs0qWL2ZqT5sZA4rMNZqE5dF+VYpo6B0m0uXE7yz8gax7sTsHO9l+ikMMMtO5iN3sS o4oioAjYNwJ2R4IszTw7dYfkICiGZdDiYGpSUQQcAQHeq2zZdd2Pf8ofyelKgo5w0XSMLo+A3ZFg AfoBTsOTdIyfLwpi72kWdPmrpQDYNQLUBvtHhkkQIpjZ07II97K/Rora9TXTwSkCdkeCxegLuAwL SBii7nqHNZ0ioJdNEbBXBCJQwL0XIkST8ouFOa79IjVdwl6vlY5LESACdkeCldW1sh3h5oy4c5SO EHorKQIWAn7oZxnj7yNzUjMkCyZ9FUVAEbBvBOyOBNkktxJlqNq1beNwATHMo2NTXFZXsXfJyMiQ goKCPRrf2vuYHWF87m5txAupLpVIaams+WfBcUeYg45REXAlBOyOBN1Afu3xNF1Tixw2EKIjRYay VBlbEg0fPrzV7yGmRfz222+mrFrjGqQc3FdffWXaHbHItUrLIVCN+5a1RD0RnevZzq3lDqxHUgQU gcOCgN2RIBeOeNQGLUElk4ySMon28zksEz8cB7Xy6lry2KzUMmvWLElOTjZ5e4MGDTLd3fclTK5n jh5TG5oiQaZQsMTagQiLbf/888+Sn5/f8DPWJ7VKtlkfrlmzxlTCYbI8HwgSExNN1RkWAGdJN37O GqS2v0tKSpJ58+aZFlKWTJo0aY8cQ36/fv16cyymXtjDw0Zj/Irg006HOZ+VZFhWTUURUATsGwG7 I0H2BhwcHSbztmfK6qw8hyLBpnr7Hcrlr6yslHfeeceQGbsy8G+2R2Ii/JgxY/Z6aBLcG2+80ew+ rCF6oMKOFCywzdJrlnBMtmRGkqSWaSXWkwxZjJvtm7jv9OnTJTU11RDpunXrGo5DcnzhhRdk1KhR DZ+xuLeVaP/ll1+a5rzEmCTK9lAs/D158uQDncZh3T+ztFzWZOTIxC7x0jHI/7CeSw+uCCgCh46A 3ZEgAwsmoYv35+gbODMlHe/tq2cg63T++OOPkpOTYyq7sOJK4/ZC1mVh37+FCxdKXFyc6eRAYjj1 1FP3+6qxszw7yL/22muG9KjdsUQauzzsiwS57+eff256/bFaDImDpk/2D2RpNmqWViHt/R0QSYya KAmoKaGWxnOSJNnwl0IMrIcDjoNkR/JjtRpboZbIPojPPffcPw7Nsf/nP/8xnTNYzo3y5ptvmvqo 9kSCNN8zsrmwokoGIlXCH/eyiiKgCNg3AnZHgvQBjkSljWjkWs1I2i7XoHRaBztJmF+0aJHRzKhF sVYntRwGmNx0000NbY+szhBTpkyRF198UVgGjWTG9kbUhkiCs2fPNtpSc3LPPfc0FK5mzU/LnEkT JjtL8Hj7Eo6PhMm2SwEBAfLtt98aQmXpNP6ezXZZe5TC9xxvU0KiZOsljoPv2Zvw9ttvN7vSFMr5 WA8BfDhgnVEen53qabZlHdPGwjqkjYXHtjChFssmvyz7ZhE1CZSbJXzPedmTpBeXonboekmMCJFj 7ezhzZ5w0rEoAvaEgN2RIMGJQ4j5NYN6ykN/LJL/oUXNE2hXYw/CxfmUU04x2hWF/itqJiTD4447 znxGomJnBWoq1IZosqOWk5WVZYpQU7iwW50cmpqXRaQsZk3TJwmF2iR/zxJq7PCwL6H2ReLieYqK igx5k5DOO+88Q1IbN24049zXeDhWS5PjGB599FETVcrf0ldJUmRRbmqXnCP9dizHRv/lN998Y8ye rJPalF/Sdg4kU86b2iYb/77//vtCPyHxI9nxwYANhD/99FOjEVOrvvfee/cFwxH7vpoFy1Hvdll6 ltwwrK/0007zRwx7PZEicCgI2CUJemLhPatHZ/l01SZ5GzVER8dFyfHwsbS2DBgwwBSjplmOCz4J ZtmyZWbRtsRqO0T/mWX6pD+PZjtGjlJGjBhhtn0JiYbtlvz9/Y0GR0LZuXOn0T67d+++r5+b7zke kiB/Z5kOqU1ybCyKTZk4caLZ9iUkozvuuKNhN86RjXjpqyM5MoiHASvUQEl6fDi4/vrrTaHwfTXW pf+PmyUkUxIfza9jx441OPAhhGZlXgOS+I4dO/Y15CP2/YL0TPnP3OXSHQUeLkPzZ6b4qCgCioD9 I2CXJEjYOqNz9x2jB8llP/0hj85abBKQ+4aHtCqiDOqgSZFkSBLiokwfGxd/WyHxUIOiBmgJidLS qBjcQj9fc8LvuNjn5ubKBx98YNoh0fRIoTbEFkfjxo3bbyyoYVnjsTRQ2/HQT/fxxx83eTzOkeRN U25j4RhJXHwQoJCsSXaW1kcCI2ExqrQxPvsaPE211Cbpe6XQD8omwYwYpdAvSZ/gWWedta9DHfbv UxANetfv86UA98FdYwbJgMjQw35OPYEioAi0DAJ2S4LtsHCf3bOzLM/IlpfnLZf7/lwozx8zSrqC HFtL1q5da7QPaj5sL8R+gDQNWuRm9eejz5D+MDaxpabE3/A9f0NhZ4ezzz672WlYvi6aVrlt2LDB kCA1wbS0tD2S8UmYPO4ll1zyj+NZ4wkJCTHmSnasv+uuu2TTpk1mDpZ2Ru2tufHw/Fb7JbZloomT Zl6aWhcsWGBMolZ0KImZuYlsCtynTx9juuRcqHnaCsmtsRBLRo3SXEshKdPsaUWHkry3bNkiEyZM MMS6devWPdpCtdY9wTSeW6fOlfmoEPN/A3pAC9w/Db21xqvnVQQUgT0RsFsS5DB93NvJvaMGyk4E HHyNHm0ebd3QYX64dA5qHSKkFsIO7VyIqSHZmu84Xi7aNGFS87rtttuM744aDX1pFqFxP+bNcduX 0CfITu8vvfSSPPXUU+b47PbOzyj0i5GI+vbt2+ShuD+1VJIk/XYcDzUo5uiRiKyGuswl3J9WSST3 zMxMQ1TFxcUmQIi9By0CptmShE+TqfU9cbB6HdIXSc2NxyChERv+hnOjFknzLH2pHDf/ZsCRRdT3 3XefvPzyy4YcGS3KHob8rDVlZ3GZ3DJ9rny3cZtM6hovj6LDPFN8VBQBRcBxELBrEiSMkYgSfWbi SKnCwvjt2s1SiqjHpycMb5XAAxLQv//9b9m8eXNDwjd9XuHh4eaKMz3AWvBJTAzrt3x6M2bMMKbT AxGaMEka1CrpgyTx0jcYGxtrDkOti2Rhdae3PbYVmGLtyyhRkik1SZIrf9e4q/y+xsbf0B/KhwES MLVBkrml4ZIUqVFSC6TWyqhRapmWpsxycow05d/U7BhYZJlZSXYkNaZucFwkOWq/1m/ps6T5lXhS +GDBEnWtJVvzC+XW3+bKz1tS0PQ5Wl6eNEZiUeRBRRFQBBwLAbsnQcKZEOgnLx83RrxBAp+v2SwM RedT92ndO8mRDj9gygO3poQkaQmDUZgKQYIiaVJjowZ5oEINsrkKMdSimFzeVHNeq6qK7floEuV2 KELTKrfmhEFATTX55f4k5uZ8mdSeSXLcmpOWGP+hzN367a9bUuWhvxbL0h3ZckKXDvLSpFHSqZWs Ey0xHz2GIuDKCDgECfICsavEq8ePkSg/b5M2cdlPf8qKzFy5aWhfCfE68Oonh/uiUytiFCf9ZTSR MhqzKb/doYyDGp3KkUOgBKblFxatllcXr5YCJMRfjTSeBxAIE+XrOKX9jhxaeiZFwDEQcBgSJJzB Xp7y1NHDEX0XJo/PXipPYFuCCh0PjR0s/ZGX5eHW1m5QJwkyx49FtamVMThkb7mBdjNwHcg/EKiB eXYNSvg9MnuJUAuM8PGWV44fJhf06iae7lokW28ZRcCREXAoEjQmNZgHL+rTzaRLPDhzkakqszA9 Q64d1FuuQHSevVSX4VgZVWlFVjryTeLKY08vKpX3V22QV+q1v3EdouWxcUNlSHSdH1hFEVAEHBsB hyNBC+5+KE318WkT5d2V6+WdZevlaaRRfL1+m9wzcoAch8R6bcjr2Ddma48+u6xcfk9Kl3/PWSrr cvJNas6tw/rJVQN7SqCn/ZnfWxsvPb8i4KgIOCwJEnC/9u5yM3yCJ3XtKC8tWiU/bEySS3/8QyZ2 ipWrB/aS4bEREuNArZgc9SZypnHvQNAVi2C/smSNTN+23Zg+rxzQU25BKbTEkEBnmqrORRFQBICA Q5OgdQU7o2XNi5NGy+TuCfLmknUye/tOOfOr32QsQtcvR/LyKJRd4z4qikBzCCQXFAtLn/1v2VqZ mbzDpOZMTkyQqxD8cmwn++pkoldREVAEWg4BpyBBC45xHWKE269b0+TrdVvlj+Ttcsl3M2RwTIRc CjIcBj9O73AEqCD/TkURqKiplfUwdS7ZkSXvrdyIqi87JB4PSxfC58xqRSd07SDsaqKiCCgCzouA U7LB8Whjw21mcrp8tyHJBM/c8MtMifTzlTOxuE1IiEWyfQjyD1U7dN5bu/mZpaI91ypEe07fliY/ bEqRFBAh2x9dM6SPnIX74+iOTeeBuiJWOmdFwNkRcEoSbNAMsZiNw8Yn/ekgwtmpO+XtFYj0Q67X WET58UmfxY77INI0CuYvFedFwHR8z86Tlej6/iuqvMxA0Is3yvKNjIuEyTwRJs94GRajEZ/Oewfo zBSBphFwahK0pjwYZlBuVw6skD+w+M0BGf4BLfHuqXPEz9dLxsZHmwWQhDggIsx0rFBxfARY3HoZ SG9lZo4s2J4lc+ErzoXvr1tUmFw7uJeMw3UfEx+FAgx6vR3/ausMFIGDQ8AlSNCCJhTJ9vT11HWn 4MKYIfOwzUnLkF9Qji0AtR+HggwHR4VLH5jHeocFSY9QdFRHSS8Vx0BgLbQ9anxMbl+CsmYLd2RK fmGJxCKy8xiYwUfERmKL0Dw/x7icOkpF4LAj4FIkaIum0fqwXdQ30SyYzAWbBzL8MyVdpsOP6O3j Jd1DAyUxOBCNUoNMcj67hbOOqYr9IJAKgqOmt5rXMDtfNuUV4FrmSWlJucThAebUbh0N8fGBpica 3mqOn/1cOx2JImAPCLgsCVrg+3q4m3xCbtQQuYhuzC2QxelZCJnPkq83bJPqFVUSGeQnnQIDTLPf Logg7IkFNhEkyVc31RSPyL1cy47yeYUmonNjToFswnXaWlAk29DRYUd+MRJ+3GDWjpDL+/WUITFh Jq+Pm7Y3OiKXR0+iCDgkAi5PgrZXjYQ4EHVJuU1O7GS6VewsKTULLnPI5kJT/GjFekExUESa+iCX zMskU3dEce8e0DJ6QttIBEmy2LfKoSOwHR3bN+aS9Oq0vGQQ3k4EuDDIhT0m0XgQUZ3BcmxnBLVE R8B0HWiKI8QgCthLa3oe+gXQIygCLoCAkmAzF9kTWgUT7LmNRrI9UysyEWixExs1RfoUV6KLxayU HfJbVbX4wd8Y6u0pQSipFYjGqnEBvtAc/aVTMI9B7TFAwvC9yj8RyCuvlC3Q5rbmFQn79PH9dtTs LKiokHx0a8gtr5DCsgrxwkMKI3lPRgNbmqb50MEODiyRR9xVFAFFQBE4UASUBPcTsQAQG7duMK8d hfSKYhBfYUWlFFRWCfPO2NZpBYiR/sU1WblSk7JbfDzaiQ96IFLD9EE4fhBaPsVSU0EATiy0lRi0 heL7OESjUqN01sTsXegET+2NmnU6tDvzio1El15cIrkguNLqGilBw+TSqhopAqbuMDF3wgPIQPht SXj98cri6HzACPD0UBPnft63upsioAjsHQElwYO8Q/xAbNzY4703TKHHoLRWCYixFFsZKpGkIhR/ s/EvFmLLlw3QHunLov+QLZ882rrVvWJzR2cML1SxoXk1EmQY6u1leiSG+kC7hIYZgi0Mn4d4tzdE 7FZfxaQNWwrX/b+uuTA+b+n6Jrt5XJAYX+ve8//mndTi86LKaslBsWlqa9kgM77PK6s073PL60yX TFUgyVXX7pIqmDCr4dvjayVw4jFYoqw7Hi74gJEYEmTeU5NmHp9v/UOEux21yTrIW0Z/pggoAnaI gJJgC10Uai40yVlmuW7wDR6dEGMW+or6BZ8aTiq0n+3QHFOhEaVBC9qO6MYUsxVLUkGhScdg/0Fq hW3BaPir/j0IDp+1w4fUKn3dPYym6QdSZCFxfmY2dG/3hinXA5tFjj4gax6Hf/NzL2z8o7Jml5SB nPh5LYitAu9rQEpMCCnHuDn2UmhnxRh3Cb4jkZHki0F8nEs5mgXX7Not1PQaNlIkOJLkthsbX3nu CJgsu8A0HAdtLo7aLzTieBBdLN4zYpPm5/Z4GOCrs2rELXSr6WEUAUWgBRFQEmxBMBsfiou5F4iJ G4UaD7UdChu1kkCs18raGgR7QGsqLYU2RY2KmlV5vUZVIVmlZZJTCt8YyIdElCXl5jh1OtnexdqH ZEeCsjQ50iKVStvv93UsS9Pkb6iRBoCAQ6m9Gm0Vm9FiPY2fjq+cM6vxkNxI8HUbyVxzL/eFtX6v CCgChx8BJcHDj3GTZ6gjA35ldSb3MH5BkZA6cgPL7AI9UcOiRgW+NO9rd+8yfjNqaCV4La6qMpoZ /zaf15tjq0CqxoSJ//A7/paklQki/WVzsvn7ONRXjQ3wkVocnN+xsDgJahd+5+XWTtqDuIy2Ce3S 8mtSq6QZ2B/kR3Jv16Ztg9baoMHi93yvoggoAoqAvSOgJGinV4gcQoOm5f+zHSZJ6WAlCb5KBu+Q TO8aNUB6wZ+poggoAoqAqyKgJOhiV96WVJsiWBeDQ6erCCgCLo6AkqCL3QA0g1pi+97FYNDpKgKK gCJgEFAS1BtBEVAEFAFFwGURUBJ02UuvE1cEFAFFQBFQEtR7QBFQBBQBRcBlEVASdNlLrxNXBBQB RUARUBLUe0ARUAQUAUXAZRFQEnTZS68TVwQUAUVAEVAS1HtAEVAEFAFFwGURUBJ02UuvE1cEFAFF QBFQEnSxe8C2oqdW93Sxi6/TVQQUgX8goCToYjcFO1tYLZa0yLWLXXydriKgCCgJuto9wCa3s1J2 mpZNHujXl1FSbvoAsmTab1vTZF1OgfmuDXpODI+NNL3+VBQBRUARcBUEVBN08ivNJrn3/7nQ9CVk 6yM2ua0ACbLP0tPzlptO9+VoltstJEBeDgpQEnTy+0GnpwgoAnsioCTo5HdEQPv2MiIuUj5ZvUkK KipBemjPVN/Qln0GWU+7urJSErvFS+cgfydHQ6enCCgCioCSoEvdA15ojHt6907y9fptUllTa5rm WsLGvqZpb3sPGRkbJYGe7V0KG52sIqAIKAKqCbrAPTAkOlxi/XxkW0HRP2ZbXbtLBuP7QdhUFAFF QBFwNQSUBF3gigd6esgp3TrKy4tXw/y5W2yjQmvhDxwUFYoO80EugIROURFQBBQBNYe63D3QHlGh kzrHySsgQYTENDSRZJCMn7en0QS5j4oioAgoAq6GgGqCLnLFe0DT6xkaJKuy8xpmXIUo0ZEdY+EP jHQRFHSaioAioAioJuiS90AQgl4md0+QlVm5zI4wJtHd8Af2Dgs26REqioAioAi4IgKqCbrIVae5 c2yHGCTML0dyfK3U7totEf5+MjQmHInyWkDNRW4DnaYioAg0QkBJ0IVuiU7IAyTpzU3NkCrkCPbr ECLjO0a7EAI6VUVAEVAE1BzqsvdApK+3nNm9s8xMShc3mEP7RYRIjJ+WSXPZG0InrggoAg2BggqF EyFQWVsrVUiMp++PwlqhrAzj4dYWpOcj3iif5oe0iS7BAZKDcmqsHcrC2qwt6gbLKH/ngSR7T40Y daK7QqeiCCgCTSGg5lA7vy+KK6skD+XO8ssrJY9bRYUU4bPSqhopramWMryWgeT4N2uAVtQTYDWI zZAg/lNZCxLEW7c2bc1vd4PoKqpr5Z0V6+UbVJKp3c0C2iTBtoYMua87qsm0JxGarZ14Y/Px4OaO 926GSFlhJhhboBdfPYXBNwEgVxVFQBFQBBwFASXBVr5SJVXVsr24VHbUb+l43VlSagivgezgvysF wZViX76WYWMJtCoEuOzGq4DwBKSGoqAiKIHGQtkkL9MyCf/xcfdoCH3xBpHRBMpjkQg3lOQbAiRl srB2DQJmcBS8rzXEKji3gFiFWiGO3wbH9WjrBoJsa87j6w5SxCvJ0QfvfYyW6S4hIMUoXx+JhuZJ 7TPaz1ti/H3E30NJspVvOT29IqAI2CCgJHiEbodikM6m3ALZklcoW/KLJLmgGG2NylDUukJKQGrU +LhPcVWVlOPVkBqIJdTbS8KQ0M6N5stw/E2Nyx9E4wty8zPkA+IB+ZH4qM2xJiiLZFsxn/zbes8C 2gU4VyG0y4RAf5wGBFqnMCJidBfIEMSJjSZSapM1+J7aJUmzuLJaijA+EjHfk6izysokFybVbLRs SsK8MtGqSfA9VEmQpDvG5yG+7fmKDWMMwBbl4y3xgb5mPl3QuaIrXrVu6RG6EfU0ioAisAcCSoKH 4YbIKa+QVZm5siEnXzaS+Aw5lILgQB4gkxKQUAne7wblhPp4SYK/v/SPDJUOSFnoEOhn2hmF4XNf aG1MbTAbCM569QCptQPZMbilNYRFt0mQVSBIo5GCJC0zLDVIaqpZpeXQcEskpbC4bisokc25hQaH NiBiao2GGEniIMoIzLcLole7hQaapH4G7fABQEURUAQUgcOJgJLgIaBL7WkXzIdpWOyX7szGliPL M7IlFVpeCcyI5SAE+ulIFCHQ5FifszsW+O4hgUYLoqmQ5kTL71b36mb8cvYsHJ9FziSx5oR1SkmK xIGvNLeyfdMOaMDb8opkPR4S1uMhYT2q2KxBEv/sNPgaMX+aWemD5APBADwcDIwMw2sY/vY1Wq59 o2PPV07HpggoAo0RUBI8gHuCi3oVNKBcmAEXpGXIzNQdsig9y5g1TUQmNCP66cK9vISdG1iNheXK EoMDjWbHtkYMMnEEojsAWJrdlVVpSGjcbKVPeIjsTti9BznmQnveYAixQNZk55qHinnAePGObBDu RnGHNswUj8EgxaOQ2zgqLkpCvTzxeV0wj4oioAgoAgeDgJLgPlAjsdG8txm+vJkp6fJncrqszsqD dge/FxdfECPNlyS9wdFhMigyXOKgsXhh0WaaAaMsVf6JAAmSATXcEM1jtGKSY3Uizax1muP2ohJZ Au16yc4skGIW/KhFxu/41fqtxvfZKzxYxqEKDrceMKPyWEzzUFEEFAFFYH8RUBJsAikSHyMz6dP7 YVOyTN2SKqlFxfDLtTN5dOHe3jI8Nl7Gd4hGBZYIiYCGQj8dtRKVQ0OADw3c6DMMgabXLyJULu7T zfggM6FxL4a5eVbyDpkLLXENHkaW78yVp+Yul2hEoh7fJV5O7tZBeoMc/RGAo50xDu1a6K8VAVdA QEmw/iozmdxEOELb+BWk9yPIj+Y5+rwCsaCOiY+SsfHRchSIrw8WWZo11Qx3ZP6J8OGCWwICZ7id 2b0TzM+7ZC1I8C+YpLnRv/jpmk3yxrK10glRr6cmJsgJIMXO2D8cpmi9VkfmWulZFAFHQ8DlSZDV VNIKS+R3lBL7dM1mWZieYcL6I5HXdlLXDka7mJgQa0yeKvaBAAmN/lWan7ndNrwfcivLZPq2NGjt abIKQTb/Axk+O2+5iTK9qG83cw3jA/wQcdt8II99zE5HoQgoAkcSAZclwUyE8NPc+RM0vk9AfgXI m+sIDeJkaBBHd4wxTWiZw6biGAhEwSR9cd9Es6XioWbq1lQ82GxHkE2e3PX7AuQntpcze3SS07H1 QIQu91dRBBQBRcDlSJBJ6nO3Z8iXazfLFJg96XtiGP74hBg5tVtH44NScWwE4gN85aqBPc3GB51v NybJH9D0v1i3RV5bugYPOPFybq8uMgYRpuysoaIIKAKui4DLkCDJjykN7yxfL3OSt0sstD4uhMd0 ipNTQH5ascQ5/xEwL/NebNcP7m0CnOjvnZ26Uy79drqMQFTpZf27y9F4AKIfUUURUARcDwGnJ0HW 4py2NU0+XLVRZm7bLtFIwL52aF+ZDLMnCVDFNRBgubZz8NDDjYE036xPQvBTklz5/QwZC83wwt7d 5DiYwOOgRaooAoqA6yDgtCTI0l709721bJ38sjFZwlG8+YbhfaH1kfxinfIK//jjj7Jq1SqprKw0 82MuXnh4uIwdO1b69u37jzkz+X/27Nkyf/58KS4ulqCgIBkxYoSMHDnSKfGxJsUoX26TuyfI9zCV fo28w6t++F0mJXY0JtSTYRnQ/E6nvgV0copAAwJOSYJMZn9/5Xq0CtqAQtFVctmgnsb0ORGanzPX FnnxxRcNCfbu3Rs5/KjviRJlJSUl8u6778odd9wh5513XsOFr0Dhbn7+zjvvSGBgoHggIra8vFw+ /fRTufrqq+Wiiy4SL1S+cWYZh3QXbvQF01/4Lu6XWSk7DBFe2i/RlGpTUQQUAedGwKlIsBYL/3sr N8ibS9bKEvh9RsDXc/2QPsbnt7cal85yidsjAvKqq66S2267zUyJJJiamioffvihPProo9K9e3cZ MGCA+W7x4sXy0Ucfydlnny0XXHCBIcKsrCz5+OOP5bnnnpNevXrJqFGjnAWavc5jPKKBR8RGICo4 Vl5ZtFpeQvI9KwPdMKS3iTZlTqiKIqAIOCcCTvOvm4nuT2Pxen3pWiRGizw4Ybic37urJKJYtasI tb/g4GAJCQlpmHJkZKT06NFDLrvsMnn//fcbSHD9+vVoEehmNMS29aXdfH195YEHHpDk5GQpLCx0 FdjMPEl0Z/fsjLJ3ofLp2i3y/IKVcuOU2SiRly93jRwgsTCnqygCioDzIeAUJLg8I0cen71UvoVv pzeSo588ergJcmDHAVeTGtY0bSR+fn5yyimnyCuvvIL+uLWG/EJDQyUlJUVee+01ufTSS4UESKEf 8bHHHnN6U2hz90VndPe4b/RAGYpasA/MXCivgAzZAuqRcYNlGErkqSgCioBzIeDwJDhlc4o89Ndi WYJakpN7dZWHxw6Svprr94+7tFOnTlJUVCT5+fmGACdMmGB8hCS89957T3r27GkCYo499ljp3Lmz c93lBzgbVqRhsQTmED44c5F8jmIKyYVF8vyxI1GKrcMBHk13VwQUAXtGwKFJ8LsNSXLPHwvQuDZf 7h4zWG4e1te021H5JwIMfKGWRz8hJSAgQB566CE54YQTZMGCBbJ06VKjKf73v/+Vm2++Wa644gqh j9GVhR3vXz5uDHo/+stz81fK1T/PkpePHyOnIb1GRRFQBJwDAYclwenI+bsf5qotaHH0FMyfNyL3 r64tj0pTCGRnZ4s7quMwAIZCs6mPj4+MGzfObDk5OSYw5pNPPjGBMX369DGpFa4uoWiGfO/oQaaY wiOzlsiNU2ebIKsJqEWqoggoAo6PgEOyxqrMPHl41iLTkfypCSPkFhAge/ep1Pn0GgsJj7mAXbp0 afD1UetjOgXTJCg0kXKjeXTq1KnCwBklwTokvRA0cyOijGt37ZZHZy+RG6bOkc9PP8YU51ZRBBQB x0bA4UiwuLJanp6/TOajp9xtCGC4DuWwlAD/vgl3oe+eJYwWZeL8X3/9Jd9//73cc889Dd8xMf7P P/+UadOmGU2Q5lIGzWzatEl4DEaVqvyNAJv13jqsn2m39SLSKO79Y6F8dNrREoyehyqKgCLguAg4 FAmi5Z98gPJnX63dKsfDL3MTNEBtjfP3zUcS++OPP0zlF4sAN27cKNOnT5ejjjpKzjzzzIadjz/+ ePn999/lhhtukMmTJ0uHDh1MWsRPP/1kqssMGzbMce/qwzRy9jR8AL7nDTkFaNu03STX/2tE/8N0 Nj2sIqAIHAkEHIoEN6IjwMcgQb/27nLX6AHoD6d1Hm1vEuYDUrN76aWXGj6OiIiQ66+/3gS6UNuz hOXU6PujOfTXX3+VX375Rfz9/WX8+PFmf9UEm/7nx471j44bKiszc9GRYq2cgdZMCVp8+0isVXoO ReCwIOAwJEgt8JfNqbIwbac8OH6YjIxVc13jO4Jl02jKtEyi9A9ys5LhG+9PIrz77rvlzjvvNL/h vswhVNk7Amy9dcXAHvIfRIy+B22QpKiiCCgCjomAw5DgziJ0g0hKk1jkbrHjuysmwu/PLUbCa470 mvv9wfxmf8bizPtc2re7IcDvUJydne21FZczX22dmzMj4DAkuDQzWxajHuhZfbqZzuAqikBrIhDt 540+hLHCYg0zU3Yid7Bjaw5Hz60IKAIHiYDDkOB6BCPkF5XIQJiiNBjmIK+2/qzFEGiHArXj0YHi +w3b0KR3h5JgiyGrB1IEjiwCDkGCNfBXpaAzvLu3l0T6aSHjI3uL6NmaRqCNdEdx9uraXahYVKAg KQKKgIMi4BAkWITcwNzyCglC9Q5/VD1RUQTsAYFImERr8YCWWVpuD8PRMSgCisBBIOAQJLhLdsuu 3bvEzUQ62m9bXEZYvvnmmyYfLyzM/huyzpkzx5RKO/300w/i1tGfuLVpiztTpBb3pooioAg4JgIO QYK+qAnqjxy3wqpqKav+Z6sge4GeJPjUU0/J0UcfbXLynnnmGVOk2jY/z17GynEwp5Cl05QED+6q FFRUondlGwlE7qCKIqAIOCYCDkGCbHga4+crZQiMyYFZ1J6F1VqYctAOY+7atWuTtTxbavxfffWV 6Qpx/vnnH9Qhvb29TYL8kZKCggK59tprTfHufv36yf3339/sqfPy8uS7774zpd24/4gRI0xjYPZG tBfZkl8orCLTKTDAXoak41AEFIEDRMAhSJBz6hYSIO3gD9yQnS81MD+1gynK3oTEZ7UrYocGNqs9 nDJv3jwpLy8/aBI8nGNr6thszXTMMcfImjVr5KOPPtorCX7++eeycuVKGTJkiMGU7Z4yMjLkvvvu a2gAfKTHb3u+WtRlXbg9U1hTdEhMeGsORc+tCCgCh4CAw5BgX1Ts74XF5o+UdLmsoLt0DrKPp+/f fvvN+AHLyspM93a+UsNi81oWrGYVFy7+O3bskKefflqWL19uSpOVlpZK7969G4iSRa7/97//yfbt 22XUqFFyxx13mLZHrAE6e/Zsef311yU9PV0GDBhgqryQIL7++mtT6WXdunXmM/YGbCwkDnaMIIlQ Q2Wd0KuvvrrJhHrWEmWneTbf5X6LFy825tyOHTua96+++qokJSUJy7PxGBzLgYiXl5fR5tauXSv0 R+5NiBHrmyYk1PXuo4n53HPPNZqkr2/rl8srgwb+69ZU077rmE7aVulA7gPdVxGwJwQchgS7I0H+ mIQY+e+cpcjL2mkXJMiFnAQ4cOBA6d+/v1B72blzpyE9amhsScQyZDTtsVktC1TfddddplPDk08+ Kbfddpu5F9jmiCRHUqFp89tvvzXERWJjn7+HH35YjjvuOEOY9OGReCdOnGiKXFdVVRlCYtHrxsIx PPjgg6Y3IEmVJDpjxgxDIhdddNEeplqS5BtvvGGOQ+2LXSfef/99U1KN53jggQeMSfKcc86RLVu2 yKxZs8x4p0yZIo888kiz9zSPQdK0FZLsvqTxbyoqKiQuLs70RLQH+XVLqiTlF8uJXTvCHHrkTMr2 MHcdgyLgTAg4DAm6Q4s5vksH+RodJF5bslZGxkVKt+DAVr0WJKvOnTsbsqIplP345s6da0iDREh/ Gz/funWrLFu2TN555x2jVVGrYWcHanmUL774wizw1HLo82JNzxtvvNH8zc4QmZmZEh8fb1oejR49 2miR3IdEQaI78cQTm8SBATm33367xMTEGOKj1shz/vDDD4YEbYXdI6KiouTee+81RBMbG2sIk/vz dyR3fs8eg9TSLCIjYVLbbU447kMV4vfEE0/I5ZdfbhdRt7llFfKfBStNUMxVqCGqoggoAo6LgMOQ ICEeEx8lk3t0lv/OXWbqNj44Zoh4ubdewWeaLkkKJDoKCSEgIKChgLV1W5AwSIwkQArNgiQwBrVQ qO3R5Mk2SPyMZktqj1Zfv8cff9x0fH/22Wdl8ODBRpskCbJXII/bnFALJUmSUFevXm2ORwK1TIy2 v6OW2L179wZNixohg3yogZHQGfVKPx5Ntj179mwYQ0hIiNlvb2M4lH8eNPvSJEvN99RTT23A+lCO eai/JQGuQheJc3t1keHqDzxUOPX3ikCrIuBQJEht8PIB3WX+9gx5HhX8e4UFy4WoJdpaQs2PBGYJ zYT0CTbu7k4fIYkyNzdXSBokIxIoe/hRGERDfxfbHZEgGQ1JcrMiTUkAJFuaU5l2QUIiGdk20G0K AxLerbfealIgGFDCcX355ZcmNaKxcFz0Y1qSmppqCNPqRDFmzBgZOnSo+Yy+wUcffdRosD///LM5 dnNCE3GvXr32+Jqk2lSRb2JHzZN48JVmYvpRTz75ZIONPcgXa7fIW8vWSay/r9w1agCiQ1vvIcwe 8NAxKAKOjoBDkSDBJvHdPKyP3PLbXLljxnwJQym1SZ3jWuU6MBDlrbfeko8//lgGDRpk+vglJycb bYqLOLUwmjM7deokXbp0MQs6F3MGmZCIbr75ZjNukhQ1PZpMR44c2eC7+9e//mXIkH3/GHTDQBmK ZUYlCS9dutT4GNk3kFqorViNdfkZtcKUlBTTN9AiaWqd1CYpxx57rPFL0ofHwBz6OtPS0gwpcw4c O8mYplUe1xoDoz2pATcnHKMlPA4Da9jol5oux00zbXR0tNmFJk+OjZrvjz/+aMzMnDfHQ5Moz8kH h9byC85K2SH3/7lQKmpr5InxY1E2TQu5t8o/PD2pItCCCDgcCXLu5/TqKtuLyuThWYvk+ql/yesn HIWgmSMfoUdfHHPfSBgkFJIifXYkHG40L/JzEhR9c1zczzrrLONTYzCNpclNmjTJvH/77bdNwAxJ 4eKLLzZRpp6enpKYmGi0LWqdPD6PRSFB0MzJYzI45bTTTtvj1iDBMKDl5ZdfNsemiZPBLdnZ2WY/ mlQtbZQkWFJSYgJyGCHKudAvSOLiXJjXRw2UUa4kPR6XQpLktj9CrOiL5HmoCVpYvPDCC0YzZiQr CY/C9A9ix4a/fGAgPjzPN998Y4j4SMtcWB9umjpHUgpL5NHxQ2RyYl3UqooioAg4NgIOSYIsnMYe boXQYp6bv0Ku+GmmvHzcaDkRgTNuR7CsGrWWCy+80JgyuUhTQyE5WJoWtRnrPf2BjBBlOTX6CG+6 6aY9fGlMByARkXT4G0vbIQGREM877zyjCfFz65j0zdFPR/Op5ZdsfDvyuNTWOD4rid/S4q688sqG 3XlMBt5wf5IvUznop7Sa7LIUHH1y/C3PdaA9C3mi4OBgE1VqNe/luK3jkMwZZGRVr/n3v/9tHghs mwTzGEdaC2Q+4B9J2+XmqXNlS16B3IL77sbBfUySvIoioAg4PgIOSYKEnVz30NjBprnuCwhUuOj7 3+UxdPi+pG+iBHge2TJWzRGQrW9w27ZtJoWC5k4GwNBUSo3QViwNsqnbqrnFnySyr7Jsjcdnjaux 75IpHdQSGTjz6aefGq2REaGWHCoB8Xy2Y7V9T/LlZolFvgdDti31z7IYhds/XbtZHoQJtATv74AP 8O5RA8XHwz7SNFpqnnocRcCVEXBYEuRFIwGSCMN9vOQ/0AhvnjpbNqCtzZ0j+klHO8vdommRPj0G tkRGRhpNkLmF9iTM+6M5lDmCzEGkz7Kxn9Gexns4x7IdJfqeQ/DVy4tXSaSPt/x7wgi5ZnBPaa+B MIcTdj22InDEEXBoErTQunZQL+mCCjKPzV4iry9cKeuyc+WekYNkXEK03SxazBlkcryVIH/Er/R+ nJDmVfoDXVlqd+2WWWiS+/Tc5TJtU7IMRj7qo7AwHN/l0PMdXRlXnbsiYK8IOAUJElyWruoY6CdP zVsmn63ZLKd/NVVuRBQpUyh6I6JURRHYFwK0Iny2ZpO8uHCNlFRXycUDe8odI/pL73C9f/aFnX6v CDgqAk5DgrwAXYMD5JXjxsio2Ch5a/k6eRrRo9O2bpcbh/SWk7t1lFA05VVRBBojkI+WSD9vTpFX Fq+WRcnpMhBFGa6GdeF8RCH7qv9PbxhFwKkRcCoS5JXyQuTiZf27y4jYCPlw1UYkNq+Xy374XSb3 7CJn9egkJyCC9EgHzjj1HeTAkytGf8pft6TI1+u3mc0HxbBvGzNILunXXfqGhzjwzHToioAisL8I OB0JWhPvgYLbTx49XMZ3jBFW+fgEJtIfNibJad07ymnI8Zqc2Emf8vf3LnGy/diY+Sf4+74B8f0E DbAaaSkX9Okq50Hzm9Qp7oim2TgZtDodRcDhEHBaErSuxLFY1EbGRsqZPTvLV+u2yUerNxrT17dY AI/BdzSTxqEElorzI7C9qBTtj1Jk6pY0mZGUJkyBOB/kxxqgo2ECDUQ5NxVFQBFwLQScngR5OenX Ob5zPHyFkXIWyPCbdVvkM2iHU9AO5+PVm2RsfLSchJY4o+MjXevqu8hsl+zIku9hBWDZs6UZOSbh /0wUYif50Wwe7KW+Yhe5FXSaisA/EHAJErRm7d/eA2QYBzKMkCsG9JTpqATyEfyGz8xfDp/QVhkY FSbjOkSbSNOurdymSe/VQ0MgpbBYpqLp7czkHbIcxLcxp0C6hPjL7aj4chweiHqEBir5HRrE+mtF wCkQcCkStCXD4SDCwdHhRhtYmJ5p0iq+25CEaNI0eWPpWiySwYYMjwVpxqu51CFu9oySMkN807el yxrkijLhvaiyyrTgumf0QBkRE2GKKHhoyTOHuJ46SEXgSCDgkiRoAdsOtdeYVsGNARFb8gtNSsWP CJr4fuM2+SN5u7ywaJX0RJDNuA4xMrZDpOkcwEo1Kq2PAOt6bkJuH5PbZ6fsRI+/PMlCOyamPPCa Xje4t+kwwkIKkb7erT9gHYEioAjYHQIuTYK2VyMMpde4DYoKR45YTxRLLpSfET7/y6YUmbIZZjX4 k7xQMiva38cE2pAU2VA10LO9iSZkl3GVw4cA/Xg12AorqmTRjkz5E/l8C7ZnShqCXcoR7VmKjhPR 0Ngv6tsN/t0OkoiHlWCv9nZTMejwIaNHVgQUgUNBQEmwEXo0lVFr4DYEJHf7sH6yPjdffk9Klz+x rYfmsRnbJwio8UJeWXf4Dgdjv8Egz/6RIRKCIAsPkKWa3A7lthSkLeySKqQu5JVXysqsHFm8I1uW 7sxGSbx8KQPh1aArRhv8ryt8exPwQDI+IcZUdgnw8JD27bTR7aGhr79WBFwHASXBvVxrFku2NERq fyyhlVVaLnPTMoypdEF6lizLzDHb67vXYkkW6QIz3BAE2AyIDJNeWJSZfuGFRZnEyOMdyVZPjnAb 06RZVVMrlSC8yppdsr24RNZk5cnyzGxZAnw35xcZwqMJmkZof2jek+LjkP8ZC408QqL9fMQT+KqJ 2hGuto5REbA/BJQE9/OacJH19eDmLp2C/OW83l1ghquVDXn5srReS1mJKMSdxWXydcE2k5zPhZ0V bLqFBErPsCDpARNdL9Qx7YTgDB+PdnXEiAW8PbRPvndmqYJmRzwswmPCelJBkazLyZf12PjKCE5W cSGp8YGB2nQczM99w0MRxBQmA/FgQRy9oYEr6Tnz3aJzUwSOHAJKggeJNRdhv/ZtofWFm41SC41l CzSXZRnZsjIjFwt7HiIUSyUb2uOvBcWmQkkpFnlKLDTEhAA/iUfR73h/P+kQiL9BjmHe6NRuNMc6 YrR9tdeFn/OuBMlVm1cQXb0pswIaHjXnVHRjT8H8k5G2kIqN5JdeXCpo2GBKlZHUaFqO8oMJGppd TzwokPgGRoWaoBY1LR/kTao/UwQUgX0ioCS4T4j2fwc3EGMitD5uLMFFqQQRMOqUWs4mvsK/mAxC KKyohumvVDYhAIc+rlJoRhXY2iLIhiY+9rALQcHvCATrhGIzr/A3RuDzIAR8kCAZ3eqOc5Ic/35F kI75DK8w0IJn9gjcoUnRMsnW4stdZCLYcXfBLMn33J//pZmyBmRWg89ojuRGkqt73W1KjRUgCjOz tAIkX4aoTLyWlRvSs17TCkuRmL5L2oPgSHZ1hOeOhwcPGYaHAHb96AbzMTXlbsFBMCX7G0JUUQQU AUXgSCGgK85hRprmTppAudlKZkm5pMH/lQ5NMb3+NRWvJBCW86K5kNoTTYWMfuTf5SDUXSBMqJwi IAtPmGZ9QSo00fp7ephXP/zd3t3NfO6GiFWSGjVLd5Am39P06of9+L4U5lxDvCBBBqFQc+PnJMTy GkRcVtWgpVC1lEB7tbZi5N2VU5vF78Cm0sbS5GD2penX0upi/XyN+TfM10tiQOqx3EB8fE8/qaYs HOYbTw+vCCgC+4WAkuB+wdTyO0WAHLgNRhBNY8mlVlVeIQWIjMzBaz62HHyWj/SAnPJykyZAQqQ2 ZpkfK0BaJErmyFGDI6mBKk2wDiMtqdlRC6TZsqiqiuoeNDJ343+jMkjCbEdSq/+Ne1uYYtu1Nb45 kmgAtDe+r/Nh1r2yAk8otNJgaKyMig1G0Ip5xWfUYmnaVVEEFAFFwJ4RUBK0w6tDAuG2L6FpksRX Rq0N2mNpPREy+ISfU68jqTHqkvtS40tH4M5Li1ab+pnXDO5pgnyMYgkTKkmP+/O/ntTsoFFSs/M2 72nOdBdvBPRwXxVFQBFQBJwBASVBB76K9AVSG+MmPvs3EfrsPluzBZrhLvRX7GzKiKkoAoqAIuCq CCgJutiVp4ZogmCw8b2KIqAIKAKujICSoCtffZ27IqAIKAIujoCSoIvfADp9RUARUARcGQElQVe+ +jp3RUARUARcHAElQRe/AXT6ioAioAi4MgJKgq589XXuioAioAi4OAJKgi5+A+j0FQFFQBFwZQSU BF356uvcFQFFQBFwcQSUBF38BtDpKwKKgCLgyggoCbry1de5KwKKgCLg4ggoCbr4DaDTVwQUAUXA lRFQEnTlq69zVwQUAUXAxRFQEnTxG0CnrwgoAoqAKyOgJOjKV1/nrggoAoqAiyOgJOjiN4BOXxFQ BBQBV0ZASdCVr77OXRFQBBQBF0dASdDFbwCdviKgCCgCroyAkqArX32duyKgCCgCLo6AkqCL3wA6 fUVAEVAEXBkBJUFXvvo6d0VAEVAEXBwBJUEXvwF0+oqAIqAIuDICSoKufPV17oqAIqAIuDgCSoIu fgPo9BUBRUARcGUElARd+err3BUBRUARcHEElARd/AbQ6SsCioAi4MoIKAm68tXXuSsCioAi4OII KAm6+A2g01cEFAFFwJURsHsSLCoqkoqKCgkPD3fl66RzVwQUAUVAETgMCNg9Cb711lsyZ84c+e67 7w7D9PWQioAioAgoAq6MgN2TYHR0tHTv3t2Vr5HOXRFQBBQBReAwIWD3JHjeeecJNxVFQBFQBBQB RaClEbB7EmzpCevxFAFFQBFQBBQBCwElQb0XFAFFQBFQBFwWASVBl730OnFFQBFQBBQBJUG9BxQB RUARUARcFgElQZe99DpxRUARUAQUASVBvQcUAUVAEVAEXBYBJUGXvfQ6cUVAEVAEFAElQb0HFAFF QBFQBFwWASVBl730OnFFQBFQBBQBhyHB3bt3S5s2bfSKKQJHBAG9344IzHoSRaDVEbB7EkxKSpKX X35ZxowZI5MnT251wJxlAHygaNfO7i9/q8H9yy+/yO+//y7XXXeddO3atdXGoSdWBBSBw4uA3a+C 06dPly1btsi9997bgARbK5WWlgqf1r28vMTHx2cPlCorK6WkpETc3NzE399f2rZt2/B9WVmZ+a2H h4f5nS0R8Hj8jsfnb3x9fc1+exP+hu2eqqurzf6enp7/2N3ah8fiePcmBQUFUlNTI+3btzfHs9V+ eQ5+zzF7e3ubffYmeXl5smvXLjMmHstW+HlBYaHk1FRKe3zv5+fX7KE4fh6LwmM1xpvjIt61tbUG L2K+N+H1KS4uNvNofH04LuJJDDhHbk0Jz8XjNPU9rx+vfVVVlfB6UzguHpPH57UNCQkxn3Pc3J9i e76RI0fKu+++K1OnTlUSPLxrkB5dEWhVBOyaBLOysmTDhg0yceJECQ0NNUCtX7/eLE6zZ882i2CP Hj3k9ttvlwEDBpjFjYv1448/Ln/++adZ2K+44gq58MILG4jw/fffl9dee80stNQwTz311IYL8Ntv v8knn3wiq1evNov90UcfLTfffLNEREQ0eZG4oH799dfy+uuvS35+vowePVoeeOCBf+z/119/mSLg EyZMkI8++mivF5yax6pVq8zc5s6du0cfxRUrVsj//d//SXl5uZx22mnyn//8p9ljcWycd3JysiHL +fPnNxB0e8/2krp1i9xxxx2Sv36NJAJDvh8yZEiTJmc+GBCn3NxcM7eZM2c2nDcjI0OIKcmCGMTF xcn1118vxxxzTJOaZk5Ojjz22GMya9YsCQwMlCuvvNJgw2tHMv3000/lzTffNA8jw4cPNw8/HTp0 +Mc8idGdd94pfEhqLA8++KAkJCQYnHivUDg2Pgi4u7tLUFCQUNMjnjwX7zEK53/VVVfJwIEDJTg4 2Nx3GzdulMzMzGbvgVb916snVwQUgUNGwK5JcPPmzWbh5cJvCRdzLp4kE2pVn3/+udx3333y3nvv SWRkpFn0SJ4kpzVr1pjPY2NjDaFRLr30UjnrrLMMQWzfvr3huNQsuDCfeOKJ8tRTT5ljkCwfffRR efXVV5sEet68eWbRvvrqq2XUqFHy0EMPyTvvvCO33nprg8aXlpYmP/zwgwwdOlR27ty5zwtmETQJ k0RgK/379zfkzoV72bJlez0WSeXjjz82czzjjDMMqTZoqdDsqCEdd9xxcuVrL8uUX3+VL7/80uDa rVs3c1yOlWRhaX6cAx8OSHC2/rJ169YJie2ll14y+JMMn332WUM4NGFzXx6LTZFJzG+//bYhpO+/ /97MgdeR1+eoo46Sn376yYyDhMzffvjhh2a79tprGx6CrElzPiSnpoTHp5bJ++Kiiy4yu/D6P/HE EzJixAhD9IsWLTLXliT89NNPm3GSGFeuXGlIkDJ+/HgzRj54NfcgtM8LqjsoAoqAXSNg1yTIxZPm qsTExAYQL774YqM1WCbOa665xhARzWs0rZHIuIh27tzZaBBcpH/++ecGErRMXo3NcDSfcVGkpkCJ iYkx5EGtsjn5FeTRu3dvOf300425jYs1j0GCjY+PNwsr/Uo0y11wwQXCBsH7EhIRCaQpMx/HFhYW ZrSU/fHncT+aABubaDkeakonnjhBQnE8YnrPPfcYbdEiQT4MkMxIxiQNmg9JBI3NwySvsWPHNoyH x+L1SElJMUTGhwsegwTHsbNBMrW7jh07GozXrl1ryIfHWbhwoblulu/3tttuMw8tW7du/QcJ8vo3 Z6omNvyeZlvLdMtXnp8bNURq/Dy2RZK8LnyY4XgtoS+QDwt8kFFRBBQB50TArkmQCxBNZLaLXePF /9tvvxVqSFykubjt2LFDevXqZa4W92VT3sWLF//j6lEraSwWAfJzmktJqMcee2yzV54LPU1o1vh6 9uxpNEiOg8LFmxoUiZHvSYr7IySpve1ru1Dv63jEr7GQ1DjGUjxgiISZhZ5aHrU1S/r16ycBAQF7 /LSpY/HhwVZmzJhhrgXN1BSei9eHWjvPSfMpcaIQbxIrz00hWVO743n4HbHkd5Zfb19z3dv3xJMP BJRC+EL5cNT4AadxsBDvH94njTXyQxmH/lYRUATsCwG7JkEuSrZBLY2ho0mNZk9qFlx409PTGxZQ a18rQOJAYKdWSfMeF+znn3/e/JRmRWpKFC7iJFqSle346HvjAs7PuOD++OOPxrTWp08fQ862BE4/ lLX401TalN/rQMZ8IPt6YJycDzXT9MEDJBWaDh8Ujj/++IbD0Ix8oEJNjqbjc889VwYNGmR+Tvw/ ++wz857+yaYeaogjhQ8cxPvhhx82uC1fvlwYHWz7cGI7pr09KOztOxIbg2EaB/g0N9+93YMHipHu rwgoAvaFgF2TIE2D1A6oldlGHHIRo6+I/kCaPhlAQeFixWAYPulb+1P7aKzR7O0S0L9FMyAJlb4i +sUo27ZtM744Cs2dJEEe11rA+bkVfGGN+YUXXjDmNvoJly5dakyE1C5p+uMCz88pPMeRJMFdtbsk IjxCKnZslLdBhKNgthw8ePB+k0JT+E2bNk043zPPPFPOOeecJiG2Im4Z4WqZe0lG1vWhX5UPCi++ +KLxzTHQqG/fvk2aPff2gMT7o7GGajsgkioDrXg9eI81J3wY4r40K6soAoqAcyJg1yRIvxFJjVoK /UoUEiI1C5LJM888YxZJS/hkT58WNcQbb7zRBNUsWbLEmCwbi5WCYPt5amqq0WRIbAywsTXD0u9F U5+tUNtZsGCB0fJodqXmZ42Zv2V0IYMqqPFxn+zsbBNoQRJkRCS3poQEQTJobvGlz3Bf6RHWcS3/ oe2DAINKSAIv3XmVMOb2iy++MFqaLU70dzLilsEulpCsOS7btA0ei8EwvCaMbD3ppJP2mBIJacqU KcZvSMLp0qWLwYm+XJo7+TBgnZcPGvSl0qdIYfQrNUJ+1lg4L27c9/zzz2/4mvcKH2AY1NKc8J7i taG2z0hVXjsKTdb0QdMUTOG14rWgn1JFEVAEnBMBuyZBLj5chLkgWyRIM90tt9xiQvD5OX2C1DC4 qHJh54JIkxoXQvqXuGAzcMUShvdzY9oCv+fCd/nllzeE9jOIhhGQJFiaNBm5yDSLpuTkk082izhD 9anJcdHkb7nIUhOxwvP5WxIzNUtGju5NGD1JMmBk6/333y+dOnWSm266yRyPRMV0BD4AMHeSZkMu 9iTVxkJzIFNArGPddddd0q1LZznmnAvE08tTtmDeDz3yuIRWlcmGLVtNxKzlS+WxiAnNpQyQobZG wmC0Lgmd5+W1oZZLHGn+5DgZ5EKNl+e2jkcSZFAQA2JoFibxU9OjFsYHAz4sMN2DwnSE7777zpCS FZDCa21LxNY8eV0uueQSQ77UGklWvF709ZE4SXK2Qi3d8mlSU+fYmUrxyCOPNER+MhCL2qhFgtRu SfxWsJBzLgE6K0XAtRGwaxLkwkZTJ0mN/jiGtzOi8F//+pcJ+ScRUKwcM76SHLloUzthzhoXXVtN gpokCZImOy6KfG+ZNIcNG2YCOqgNcJGm7E3j4lhojmWkIf2HDLcnaTRV3o2k0RyZ2t6C1BZpkuXi z7HyuJZ/i3PmeEkmXOj5nia75oQkT3MwiZckkJ2VbcZm/ofXooJC8W6zy5yL2NoK8x2t4BYrzYFa IAmZ57U0S76S+BmsYxv8YwUH8ZpQ27JSDJiWwetDgqHWzOtDQqMwQZ1ERO06KirKkK1tZLDt+Hhd +MDDYB5G4HJMDL5hZClJtXFxAM6RRG1LotQ0SaIkb+LBhwlePwotCNQq+XC1v75D115KdPaKgGMi YNckSEhpRuMTvhWcQJ8Tt70JNTRuTckpp5wi3JoSal4HKjTvMT9wX0Li4rYvYapCc0JC2J80C/6e izrz4hpLckGxIUYSzzP33CBR7Zqux8p0D0tILv/973+bHBaDerg1J7xuJE5bIUlZ2p/t5yTUyy67 zGz7K9T4Gmt9Tf2WptrGQi2vqc8t/PidlV+6v+PR/RQBRcCxELB7EqRp0baqi2PBa5+jJUFSc6N2 GBWmQR9NXSX6e60IV/u8ijoqRUARaAkE7J4EW2KSegxFQBFQBBQBRaApBJQE9b5QBBQBRUARcFkE lARd9tLrxBUBRUARUASUBPUeUAQUAUVAEXBZBJQEXfbS68QVAUVAEVAElAT1HlAEFAFFQBFwWQSU BF320uvEFQFFQBFQBJQE9R5QBBQBRUARcFkEDgsJsswWK4U0bubqsijb0cR5TXht2E5xf4tw29Hw dSgOggCrDDXX9NhBpqDDdBEEDgsJcpFl/Uv2l2O9yf1tJusimLfaNNvIbkkvqzLFqWt376prWOvn jU9VFAELgTbi1t4Dm2cjSNrIrppqqUXJvd24d/YmrEiUl5dnipmzqL2KImDPCBwWEmSpMxYdZocB FoA+kE7o9gyWo4+t7S6USnNrLwWeYYb4fkMR67DaStndpq2jT03H30II7MKNsaF6tyyr2I0y63U1 aCk1+Dweq8VQcKN33RfNnpEPwewZWVpa2lA4vYWGp4dRBFocgcNCguz+cMMNN5hNxb4Q2FFWKYs+ n2I0wdvOuEi6BvrZ1wB1NK2OwAtL1sj30+ZJWxCdWz3ZVaLH5sBeXeSek8ZLaHv3Vh+jDkARaCkE DgsJttTg9DgtjwDbR9E8zY3dOVQUAVsEanFf7MJ9ASeG0D5gayNoA0ey6cmoJKg3jRMhoCToRBdz f6Zi659VX+3+IOZa++zrntjX966Fls7WGRBQEnSGq6hzUAQUAUVAETgoBJQEDwo2/ZEioAgoAoqA MyCgJOgMV1HnoAgoAoqAInBQCCgJHhRs+iNFQBFQBBQBZ0BASdAZrqLOQRFQBBQBReCgEFASPCjY 9EeKgCKgCCgCzoCAkqAzXEWdgyKgCCgCisBBIaAkeFCw6Y8UAUVAEVAEnAEBJUFnuIo6B0VAEVAE FIGDQkBJ8KBg0x8pAoqAIqAIOAMCSoLOcBV1DoqAIqAIKAIHhYCS4EHBpj9SBBQBRUARcAYElASd 4SrqHBSBFkKgHXoBtm/nZvpN7tFsGX+0a9tGfD20jVILQa2HsRMElATt5ELoMBSB1kKAZLcxp0Cy y8rNELbkFRrCa4u2ulZTXfd2bSW3vFJmpeyQQM/24gWi7B4apKTYWhdNz9tiCCgJthiUeiBFwDER YHukL9dvlUdmLUIj3bbiCYLzcHPbYzI+0AAXp2fLOd/OkPLycjk2MUHeOWmckqBjXnIdtQ0CSoJ6 OygCLo4AO8if3bOTvLN8newoLhXTWLd2D2OoQciYSPFdWxDk5O4JEuvv6+LI6fSdAQElQWe4ijoH ReAQEegaFCDHdYqXj9ZsAtEJzKD/PCA/qkZ3+YHRETImLuoQz6g/VwTsAwElQfu4DjoKRaBVEXBD QMxF/brJVxu2SmlVtTGLNiU1NTVycrcO0jU4oFXHqydXBFoKASXBlkJSj6MIODgC/SNDZURcpPyx bTtMn7sZFrPHjKqgBSaEBMpRHaP/4TN08Knr8F0YASVBF774OnVFwBYBH/d2cmX/HoYEwXfi1kgZ rIGGeGKXDjIoMkyBUwScBgElQae5lDoRReDQEKDmNzw2QgZEhcmKjJw9fIMMlokO8JNxHWM0IvTQ YNZf2xkCSoJ2dkF0OIpAayIQ5u0ll/ZNlBt2ZIkbomMsk2gltMCxSIuYABJUUQScCQElQWe6mvsx F1YEoaeHG9+rKAK2CJD4xnWIkU6BfpJSWGLSInZBCwxAgjw/Z6K8iiLgTAgoCTrT1WxiLgWVVbI2 Kw+5X7sQzNBWtheVSfXuWqmFz2cRnvZzyivwvi4nrHtooFATUHFtBBJAgOf27iqP/7XUBMBUVlfL mM7xMqlznGsDo7N3SgSUBJ3ysv49qWo8xd80ba7klJZJeyxozPMqrKg0sX/3/7lI3EGMlbW1CHkP kucmjVQSdPL7YX+mx3vipMRO8vrSdVJQUSHuqCBzVMdY6QhyVFEEnA2BFidBVpSoqqqSajw9qrQ+ ArurayTW011W7qyrBOKGmpDu9WbQYlwnJkbvgrY4KCxIgqAhlpSUtP6gdQStjkAkqqYdExcun6zZ Kr0igmVkWICUlpaaijEqikBLIcDatO3bt5d27VqcivZ7iC1+5vT0dHnllVeksrJS2qrPab8vxOHY sY2V7dXeTzz9oqUWN5ytF5CaIaXWw0dK1iyX1xdNl5q2LX5LHI6p6TEPMwJuu/BA1N5f2oV1lXZZ O2XKay/JL43qiR7mIejhnRwBPlDVwgrVq1cvueqqq1ptti2+4uXm5hpWv/vuu1ttUnrivxFgAExW ZbUc/9U02Y66kI3rYVXV7JL+UcFy/xkTpX9IwJ7tcxRIl0WA901qSZnErU2SMdFD5bj4SBMgo6II tCQC27Ztk6+//rolD3nAx2pxEuQIqN4GBgYe8GD0B4cHAS8sXid27ShvL18Pc9auhvY4PFsNzNYD UClkWEKceKrmfngugIMetQf+Dd/p74fIUE/x1z6CDnoV7XvYQUFBe6xHrTHaw0KC6jdojUvZ/Dk9 YAY9oUscSHCdIChUrCY59BF6eXmgAkioEqB9XTK7GA0XhziQoIoicLgQoDnU6ll5uM6xr+MeFhLc 10n1+yOPQJ/wEOmCTgGb8goaTl5TUysj4qNklHYEOPIXRM+oCCgCdoGAkqBdXIbDP4ggL085FRU/ npm3zKRH8P98CusTFiw90SFcRRFQBBQBV0RASdBFrroXcr0mJETLfxasQIDDLiTIt5FgX28ZHB2O KN4mmse5CC46TUVAEXBtBJQEXej6dw0OlEEojrwYlWKq0ReuP9rmHK21IF3oDtCpKgKKQGMElARd 6J6IhOZ3Ro9OMi8tw+QL9kNAjFYBcaEbQKeqCCgC/0BASdAJbwqWQbNyuhgBWoUAGIp7WzcURvaX 9jCN+rX3ku5okFqIajG1KKXGFDB+zqLabKjKMtse+FsNpU54g+iUFAFFoAEBJUE7vhmKQFAkKbOh 3mchkt5LUOqsDKXQykFsFdW1eK2RUuT6VeBvkl8lXvndHiSIzylubdpKHmpB0gfIGqKfrNksv21L M/saEkTNyHaoCsIUl7ZIq2DxZG93N/EEGXrivSeKIHjhb293d6GPkX/7IX8swNNDApEb6m9ePcQf m4oioAgoAo6AgJJgK12lGpBQBipyZJaW129lklVSLrno6kDSKwHRFfMVfdz4nuRXUkXCqwHh1RjC q0W1F4R4IuO9pm4WLGsFTc6jXVtDYnXEh9p8VotwfOTt1k4CQF7l+F1ybr6s2fl3jddKdJPguPhL apAkSgHRmpYT/JDHB/m5YWPJNW7e6Ebu195d/ECMviDEvzecB8QY7NVeIny8sHlLhG/dayQ2FmlW UQQUAUWgtRFQEjzMV6AANVST8ovRmw1bQRFKl4H4ysqloKxSCkBsloZnaXu7QXpGLYPGFQCNKgAk EwByCcPWxd8Lmlc78TFamJt4gUi8QWjeID1We6Epsx1Izx2aHgM+WeSKZs12NtGfLJ6dj3MUg1A7 +HlJFQmuXmpwXkuD5BCMKRXESDKsxH4V2MqgZZZS2wSJUuMsBilTQ82vAJkXFmFO1VKEY8MGi5Nj ENQUOQ9u9Zoi3wfifYSPj8T4eUs8uhN0RNfyBJhqSZoqioAioAgcKQSUBFsQ6S35hbIxt0C25ReZ jU1J2a+vAKZMbvnllUazo+bWDppTlHd7icSi39vPUyLD/c37EJCDH4jPEwTnAcKiFsdX628PN5Ac zJokNtMRAqTH9yQ7q7KjbcWepqo9kuzYQ5D9BRv7/Pb423QWr1MCSY41OFgN0itqjMbIv0mSdQRp Nus9XkmuRSDIvIpqycC8M81WJalI1t+Jh4CqSpAkCNwHWiQbtQZh3kF4DUE+Y1yALxL7/SUByf3d ggMkEVGt6pxswRtVD6UIKAINCCgJHuTNkAdSW52ZJ2uyc2UNmtaS/Eh49OMVQzMqgpZXAxIIBbF1 hMY1JNBH4mNDJcbbU8Lwma/xs9WRG/1t1Oo8odG1B+G5sYYntTKMjRoZA1XY95avJDWrjjFfSTwV dS6//RZDdPgPtboDEUOI+A9NrG4gY0+Tc8/gmTrNk6/8noZOlkKiaZUmVvorqUVyowbJV2qT2cBw BzTitNIKSYFpeENmDj6rgkUXWjDaP9G3yI3E2BWE2ActffqEB0svJPhr898DuXK6ryKgCDSHgJLg ftwbJJ4caC8L07NkwfZMWZaRLWlFpXX+OpBdcb0JMwE+r77+PpIQHSId8D7O11P8oO2Q3LwYWFJP elY/P2psJDorMIXvSRC7bUyU+zG8A97FaIcH0RDgbwKu/3HDMZo+WB1ptoG51k18YN6ln5KfWf5K y8xabhEkiLEEWnI6SDEJ/tFkmI63YluQky/zt2eI30Z38YF5lcE4MX6+0j8yREbERMpQJPxHwqyq kawHfCvoDxQBl0dASbCJW4AaTBkCQlZl5cpcLL5zUzOg6eUb0qtgZCa2QPjmekC76xEVJN3xmuDr g0r7bnUmzHozJn1zFEuL4yvNiNXo1eYKUkeadURfR7p7kiXR4QMBzbKoJW+0SUov+Agt0yrNqsUg x2SQ4vqCYlmfXyKbCktla16hLErPkA9XbhRfaItdgv1lNGqgjo6NlL4RISZAhz5SFUVAEVAE9oaA kmA9OjTZMYhlDghvypYUmQfyK4QPy/jA8J0/NJnB6Lc3MNTfLNIR8GFx8Sbh8ZWEZ7q002RZb7qs qD0IdcuF7leiw+CbxgRJkypxpeZMr2Uk/qaWPTI80PgaSZDZ5dWyDqS4LLdQVsH/Oi9lhyyGpv5i m1XGxzgsJhydMzqAGCMlBCZor1bsXO1Cl1Snqgg4HAIuTYLU7JiSMB8mzl+2pMrs1B0mLYH6A6Mt e/p7y8AQfxkA8kuAX4+LMjUXKxDFIjyaMyuV8Frs5jeRqWRGG+2RSqItMYbjIaRbgLecGBdmsE+F prgUhLgsr8hoir9uSpZfNqeINzTCkbERchL6KY5Bxwz6F2lOVVEEFAFFgAi4HAnSD5WN3Lwl8Ot9 sXar/J6ULmXw6/nAZ0dz5gh0WR+NAIx+MK/5QfszQSDYaKqzzJqMrKw5GKea3nMHjUBTWiOviQkq wl0c4OEnPYN85cLdMSYqdTW0wzmZ+bI8t1hmJm2XqXjIaY+I3PHxMXJ2z04yHMQYCg2RuY4qioAi 4LoIuAwJ5pQhAhG5elO3pconq7cgd6/I+PWoUfSPDIepLQgaXx3x1cU51gkXX2p6qujZ3z8SPpSY K4T/1wXc1AXiBCPtYiyCZsZGBqO4QK2sRJ7mXBIitMTZyWny8+YkiYNJ+6zuneWUbh2Qn+gHQvSy vwnqiBQBReCwI+D0JJgMvxG7Jny2dotM37ZddiEoJR6FpE+JC5ejofUNDg0QX+TlNSSJc1m1gjkO O/x6gpZCoHHkqpXOwWs7Cg84o7ExJYRE+GdGHjTEInlp4Uq0llopxyRQO+wiI+IiTG1VFUVAEXAd BJyWBDchb2926k55a8V6WQifXzRMX0Og6Q1HcMWEqBAQoWeDhsdoUEvrc51L79wztSVFS6tnlZ3R EUEyBubudFgGZiHPkybTpYgy/RH+wwFRoXJF/+4yrkOMNhp27ttDZ6cINCDgdCS4GonrfySnywer Nsry9ExJCPCRcztFyzExITIEWp8PogRZ3YRRhq0Vu0lN08sLgTaennvcivy8msWwUeR6l0XM+Kwd C1X7IW0A0avl5eX/uH19fX0bfkdzIMUd/i8e363e58Uu8jwuj28IH8fl99yvpKSk4ZjW5xwfz8Vz 8pj+/v7mtSnhPqWlpeZcHAuFf/Oc1m/46oMyaW0RWFRcXGzOf6TEOpPR8I3pdLepznNRpxg5q2Ok LMkplBk7kA4DUrz+l7+ke3iIXNYvUSYmxMoAtJtSUQQUAedFwGlIMBX+vu82Jsvb0PzWwPzZDWW3 LuveAeQXKgMQ5IICJ6bE14FWSTkcl57ks2rVKlm5cmUDqVkkkZiYKP369TNkQcIiAebl5ck333wj PXv2lD59+hhiovA3JMvffvtNwsPDpVevXlKFIJ/2KFydlZUlS5culR07dpj9oqKiZMCAARIZGWl+ z33WrFlj9hs5cqQ5H4/l7e0tW7ZskXnz5pnz9e7dGykiNfLxxx9LUVGRITZb4bE55nHjxklubq5M mzbNEPywYcMMyXJ/HpsE9Mcff5jzTZgwwZznSBKh7ZitIBtWryGt01w6IixIVsJUOn1HjswGGd45 ba50QWWaqwf0kMndE6QzKtaoKAKKgPMh4PAkyDSHKTBlvQfNbypIMB6a3zW9O8lEmLb6BfuZQmPU +v7uldD6F5Ha0pQpU+Tdd981REMiIVmQ9EgYZ511lpx77rmGAD08PCQzM1MeeOABQ1YvvPCC0bYs ciFBvf766zJ27FhDPAUFBZKamiqvvPKKbN682Wh6FJJjQkKCXH/99dKxY0dzDJLSnDlzZMSIEea8 JK3t27fLY489JklJSXLfffeZ8xcWFsrDDz9sCJQaqS15kThPOOEEmTRpktEEf/nlF1m0aJG8+eab ZjxlZWXm2CRjHoNkPH78eDPn1iLBxoTIKj0kQwZGcTsJ/uLfd+bKjymZcsdvcxBIkyJXgAxP7tbR FAJXUQQUAedBwKFJkAnt767YIB+u2ozcvlo5p2uMnIzghiFhASbJmu2GjpzRbf9vCi7+3EhcJAZL 66PGR03qnXfekejo6AayIJGRNKjZff7553LdddftYRYloVGz4zFJRJ999pkhnWuvvVb69u1rPqfW x+OSMJ955hkzWP6Gv7VMoDt37pTHH39c0tLSDBGOGTPG7EeiJQHefffdhrRJfBaB8T2PQfINCAiQ G2+80YyPmmv37t2NCZT78G9qoLfddpvZj8e0J+F9YpFhz0Bf4UYN8ae0LPkmaScqB2XKub06y1Ug wzHx0fY0dB2LIqAIHAICDkmCLD32yepN8tT85bIhI0fGxITJGfDtHIWQeH9EA7L6y98Ngg4BncP4 UxIDtSqSnWWK7NSpkyEt+sx++OEHGThwoNGcqCHytUePHvLJJ5/IoEGDZPjw4cbHZyskSm6LFy82 2uQpp5xiNECeq0OHDkazJBnR10cfnyXUAPPz8w05btiwQe655x5D0JZmyv04RhJhbGzsHiTI76iV cuNxaa6lFvvBBx/IcccdZ0yf69evlx9//FFOPfXUBlI+jNAe0qFtyXBIaKB0h2VhBMjwu+QM+Xj5 elmAqjS3DO2DAJoe0h6BNiqKgCLg2Ag4HAnS9/fiotXy5tK1pp3CTX07y+QOkdLRx9OU07IHn9/+ 3hIkJ4toSCIkLBLVySefbDREmiFjYmKM1hQYGCgXX3yxPPvss8bU2LVrV/OZFehie06S6++//260 NvoXeUweY8iQIYZMbU2R1DJJujSf0k/5r3/9S4455hizv2VytY5tkZ2tJsjvbM2anMPZZ58ts2bN kq+//lr69+9viJfaIj833SXsTAts6nqRDEsxTlYIOgHdP3pDMxyAknlvbkiVf81YYDqH3Dmyv+mB qKIIKAKOi4BDkSA7CTw6eyl8fynSA/6+a3t2QK5fCMpptTGteezR9HmgtwYJhVobiYLamUUwNCV2 7txZLr/8cnnwwQflq6++Mv4922hRkhOJ6tJLL5XnnntObrnlFunSpYsJbqH2SM2SmhqjQS3TKQnw rbfeMprbqFGjjB+PWh+1TNtoUO7PfWn2tA2O4TlpVmUwDPfhuMPCwsw4n3jiCUOuM2fOlKuvvrpB izxQTFpzf9Y2LUHCPXs/XtIlVrqgW8Vr61PljSVrZBN6Iz40drCMVfNoa14iPbcicEgIOAwJ/rY1 Te78fb6s2pktpyREyhWJ8dIDpipWcqEvx5mEwSgkImpVFgma8H4QDrW0BQsWGNIiqQ0ePHiPqZOg Ro8eLaGhocaHSO3ur7/+MloZyZA+OxIjCY7ERV8h359++umybNkyEyxz5plnNkR08uDUJEmcjz76 aAPZWSfluBgYQ8Jl9CiFBMpoUR7riy++ML7Fo48+2hzTEbTApu4lptWwfN4EtMmK9fGSDzZvly+3 pUt6UZmM6xhtmv+yUDcbA4eiPinfs92TL6oSqSgCioD9IuAQ/0JZ6eUmROltRgL8ZSC/K7vHSxia rrJwslXpxX4hPvCRUdsi4dFvR+KwhKTIQJOLLrpIVqxYYaJLqTVaEaDczyJLmkGZMsFgG6YurFu3 Tt5//31jSqVJ1TJLkgh5PJLUHXfcYb6nGZW+SUZ2Ukis9BvS18fIUiuH0RoX/ZqNNVIS+TnnnCOz Z882BBscHGxI3ZGFWiE7gySicPctvTqaXENqhRvz8iUE5OcBHyHNp6xHysR8L/inWbA7zt9XOgT4 mtduwYHSE42BtYi3I98JOnZnQsDuSZCNbG+bPs8Q4NUgv6sT40zCe0VN6yW7t9QNYAWyWK8kPG4k uKCgIOPzsyJJrXNSy2KADE2eTz31lHz77bcmItT6LZPUmU5xySWXmJQKkg9zCElqPM+rr75qfI08 No/VrVs3EwRDwr3qqquMRkeyZHoEozit85PUqGHSx0dStDRUHpPkRhK0NZ9yH5pF6QukVsox2kNK xKFeO+b4894LRc3ZixGN7AZT/GsbUpCDultGR0eg4z3STIpLJau0TLag5+Hi8ixDjl7YPHHf+oAY feGH7RDkJ32Qh9g/MkyGRIeBJP0OdWj6e0VAETgIBOyaBJMKi+SRvxYjCCFXLu8WZ0jQB13aaZpy BiEpWARoaXHM8aMJkWZOklBjrcuqKnPiiSca8yWjRUlA9OdRGBTDhHRGlzJ4xkpHIDlSK+Tftonq 9OeRoGjupL/wwgsvlJdfftlEn06ePLlBE+V5qRlyP1sStK5DU9VkaPrk75ra35GvH33PvAd9QWoX oBoRq9C8uj5FCisq5bFxQyQWGl8lfNRM0ckvrzSF25MKimQbmwJn55tmzZvyC01ZP2qNJMYeoUGm Qs3RHWOkO967o22XiiKgCBx+BOyWBLmAfLBio/yGvnAnIv3hSmqAWDCcgQBJGNTcWJnlp59+ajBN ZmRkmKhOal30y5GsrEhMW/8gI0L5Hc2YmzZtMpVnrKos9N/93//9nzz//PMmgIaBLjR5bty40fgS adK0cgpJTgy44TlIhDwHUysWLlxoNEb6DhlQw/GS/P78809JTk7eg5g5FpItq9E0NneSAG3Hffhv 5yN7Brbl8ofP75yEKElDe64fQGofoNP9c8eMbBgINbz+KL1GU2oV8YYWWVFbI9tQnWZFZo4shY+b +a5z0jJkPsr8PTVvufRF2barBvaUCSjsHQAza9PF6o7sXPVsioCzImC3JLgIpc/+u3C19ERD2yug BYagPY6zBMCQfCIiIoxZktGTltDfx2AXamNWhCjJiT4/5uhZdUC5P02ZDHQhqTEx3ipRRu1r4sSJ 5u/vvvtOPv30UxOMwlQLkibTL6z0B2qNNFVawnGRMK+55hqTojFjxgxTEo3HovmUuX62Pkrrd8xH pOm1MQlyvBw3x+8MptCmFgFWI6J/mpaKdWjZxG4lo9C8d3Jiwh67M6iG3e3Z+1DEQyJ9vGUEehry 9+W4PtQOp29LM/0tl6HX5WU//YlSbf5yJcjwNFSqifLzcdY1SOelCLQqAnZJgkXo7v7Byk1SVVMt kzvGS1/4T8phXnIWIfkxZ47mRtt0AxIMtTRqgpYpkWRHTeuNN94wn1v7k1RoBqVZlKRn5fvxcx6H fr6hQ4eaPEJ+Rg2RZGYl5jPdgQErp512mvnMOi6JjJVe6Be0hMTIKjTNmTV5bisy1JZQSbAcN79v nNjvLNeSplHWpO3q720Ctu5asFa+BBGe0CV+nw17qWEz4Z4b0yxGx0XJvaNr0forW95Zvk5mpuyU W36bi/fr5cExg+U4HNNDzaTOcuvoPOwEAbskQQYUfLV+iwwOC5QTY8OMCdQZcgCta05SIqE17iLB 761cP9v7gxqVRYy2n1tmTAaf8L3lP+SrlQJBsynFCnCx7U7BY1p1Sxvfj9RKLX8ev7O6QzR139qe 2/Z7qyi4s/kEG2NQ19xXZCi6lIxD9aI5MIv+jojmE7p2OKB/5m3rtcWx0CS5sSPKi4tWyVfrtsqF 38+Q+0YPkpuH9TWRpyqKgCLQMgjYHQnSd/JHyg6phuY3Ar3/whCF50hVYPb3sjRHHE393kpCPxAC siWw5sbUOOjGlqQb5/MdbH7fwf5uf3G0l/2oDUYhMnRSTLjMWLhW/krbKcdDc2uu/dT+jLsPUine PmkcapVGyUMzF8n9MxeKL9wCVw3oqYEz+wOg7qMI7AcCdkeCjKb7E/0AI5CD1Q8+kWrrMXs/JqO7 KAKthQBTJxjP2cHXS8Jw767KzJUcNO4NQ2L9ocolfRMlGAEy1/06W56ds0yGx0TIoKiwQz2s/l4R UASAgN2RIFsjrc7OkxBE3XX083LKZHi985wTgRowYWD7dtLZ30fSikolCakRLUGCRIttnGgefeSP BTIjabuJINU0Cue8j3RWRxYBuyNBhpFnFJdLTIifBMP0s9uBUgKZcM5cOgajHIoZ7HDfAlbrJCuY xp7HerixaMnjs3qRN/y3TKTfjnJqebBqtKQwZeIjJNjPhKXkYmiHUb51/l4VRUAROHgE7I4EyXnV u9CNHMlR7vgPO0PYu1gkwiR3RmQy/cEefGEkZSu53ZboGIG6evVqYV4ia5FanertHWdHGB/v23b4 D9t91bbwvevj4W6CYopgLalp4WM7ArY6RkXgcCBgdyTIBSQAT9IMNCiprhEPhO/T32LPYlV9eeml l+TJJ5+UuLi4QyZBK9WBFV4aa2pMYyC5NafBWU16//vf/5o0CJYvsyVlRowycZ6Ftdnjb39I0Oo6 wfHYiu1YrO70VtQpz0nN2IoOZZQridmKSGWqiDUHvjJalgRtfc8UEKtVFI/NcVt1Uq1Sbc0F97TG /YJujqZ8WinuW2+kpHgjNaQlZX1OvrCV2KndEsRfO9y3JLR6LBdGwO5IkAnFnRAQU4oFcGdZlSQg 0MBREiS4wDMfryUSw7nYkyTY4Z0kZZEQSYL1O0lu+8q9s8io8f3NY9l2ld+f+5/jYdk1Nt7luCxh pRgm93MsLM02ffp0WbRokUmcZ8UZJuezfimFhcGZhM/zM/eR/RFJkCQ9znHu3LkyZ84cc5z4+Hjz Wyb5cx8en8n/rI7D/XleNu21p0R81hHlg9v20gqJ8EfDZLRdailJh4+R1WgYOHYiUi+UBFsKWT2O qyNgdyQYgCfcYShE/M3aTbKhsNQkIdewX5KdCBddEoiVdM7FuSltxNJsuL9tnhwXeNt6oU1Ny8rp o+ZEEqA2xPdMSGdJMyavk2ybE46H3991112SnZ1tCIm/p6bFz5nz15is9+YX5Hg4D9Ykpcn3yiuv bGjMS4Lj+TimX375xbRP4phDQkJMSbe3337b9BZkEW+OoVOnTuZz1jxlEXCrSg0JkMXA2ZGCv2cV HPY5vOyyyyQhIUHeeecdU1icv+d4pk2bZkiVhcIbN/ltrVulHcg5G4UethaUyLkdYlusKHZaUYk8 OHOx/LJhm5wDXyB9g1pKrbWusp7X2RCwOxL0wWJ7fOc4eWPpGlmIYsMnxYVhwTVN5FtVrHqfixcv Nos1yYUlwagFsfWQrbmRiz2J6+OPP5b58+ebEmixsbHGNMhGuFz4qaU1JzQD8ngklltvvdXsxuR1 HouNdlltZm9aoNWLkF3iqW3x3CQMEtKSJUtMoWxqdZYWxde9jYfjtvIOqd1Rm7O61dMsS82Qv6d2 x1ZLbONEomVtVBImNTb6SWnOJDGzvRKJ0Hp4IElzjCzrxrJxNLlmZmaaGqisecrjTpkyRW666Saj HVK+/PJLU9WGJMhr0xLa96HcYCyLVlRVI0tziqQtHjSGIV+wcVL7tvwieXPZOjmnVxcZiHqi+yO/ oZTa8/NXyrTNSXJ0p3h55KghEoh0CRVFQBFoGQTsjgRJeAMiQmUAWswsyi6UZbmFMgj1Q1u7bigX cJr6qO2wwwO1Kmom1Gi40LPrO4ULMgnw+++/N343li8jobEJLkmTRa0/+ugjQ5DNCU2g1HhoIiR5 kVRJuuzQToIgEdn272t8HI6BBDN16lRTiJskw6a6y5cvlwkTJhiNkhobi2vThPvhhx+arhNNCcmO LZtIbiS6zZs3GyIi6XAcLP1GUuV42L/QIiSS4/bt241GSDKn8DckcZZssxWOj/NlWyeOm6TL33Js rG/Kz/g9NVH+ng8ROTk5RkO0jtsy/xwO/ijtUc5sI7qefIVGu/2iQmVS5/iGg1GTe2/FBvllS4os QmuwXojw3BcJssPEp2s2y08oIJ+O1kwX9e8hDx41VLrAVaCiCCgCLYeA3ZEgp0ZfyrUDe8lVP/8p XyRlSCJa03CRYTWZ1hISEomO5jku9iTFY4891vTfW79+venxRyFh0eT522+/GS2FXdf5Nxf1rVu3 GrJgbU6aApsTFqu21SxJPmyKy9ZJ7Ay/v5GnJBCabtlUl6RHLZTNc0kk1NI4J2qU9DGyf2FTYpU+ IzHRTMlaoFbACv1zbMJLbXPIkCHmeNQAn376aZk3b54hcPYoJIHuraGu9eBAsqS2ykLdHDOLg1Or 5HxpUmXQEc2xJFMSJHse2gMJspFuXmW1fJOSKTlVtXJj146m+DXJ6+0V6+XXzSmyDlaNYrRaatvW TXLLyk3+K8uk2Uoygl5+3pSCItppshLJ9klovdQrLEgeHz9UTkEwTDCS8FUUAUWgZRGwSxJ0w6JC k+iETnEyJXWHKaB9Yedo2c1O8i07//0+GrURFoTmwv/cc88ZIiHBkNgYpGIb5UhNkJoKG9mSZGjK ZCAHtSiSAaNHqdk0JyQTq6A1SZWaEwmQUZ4kWytikr+3ujrsLUqSx6PJkoRCQqYfj+9pXuV4SO7s FrG38fCc1H5JopbPklousaCpcsyYMeZYPNfxxx9vzJoMkKH5mL0Oo6KimvSdWuckfsSK+5I0qbWu WbNG0tLSzEMH2zjRrHzUUUeZ48yaNct8RlNpa5pDSWTEY2ZGrnyzbYeM6xAjx3aKlSfnLpNvNmyV LblFUghMPHAdvYwJfLfsKCk1nSPc2rRFK6Us9BXMMO2UtuQVSAZaMhVVVEk/WEPuOWmQOZY23N3v f6a6oyJwwAjYJQlyFjEBvvKvEf1lGXquvb0pTaJ8POXYqBAphymsNSqpUcOhH+qbb74xviuaNrkY P/TQQ3v456zUBhIfTZj0hZEc6OPiYk1zJk2TDPpoTl544QWzuJMUaI5MSkoyhEWzq0VA/C2PZ2lY e4uStIJiOAbLlGo7Ho6FGlZTwuOy3RMDVkhw9CVajXipPVJrTU9PN2RMoiR5k/w5bhIttUSei8TP 73k8fsex872lBVLb48Z5k/TY1Jc4s38hW0ZRk73jjjtMXiOFY3jttdeMptlaJMgyacxlXZxTKC+t TRE/L0/TQf7GqbNlI8z4BQiS8cD3tqkSbUF8M5N3yNk50yQNATQFwLS0uhZbtUQiEvpc+AtP797J mEw1Gf6A1zP9gSJwwAjYLQnSUMSn4AdQOf9f0+fJC2u2mWocI1FUm10laE46ksKFln4uEhMJgeRG Hx0JigRgLeYkAasvoBUBSeJgeD9/Q02Mvff2pnlZxMnjcn+aFmn+s0yD1rxJqI888oj5jmZZ29QF 7kPSIbHweCQS+iJpok1JSTEmR5pBeXyadWnObEo4LxIdyZcmSpIl/YqM9mSkKjVj+ghJbNTMaAKl tkYciA+1Z46Tv+dDAxP0+XBA8+rOnTvN7zg+khyDYEhy/IykT6LjefhbkijTJ/g3j01MmEZh+T+P 5L3Ac5mkeGCzMq9YnlqVJBnQ3thgdz40ukI89OCOQK7gP7s98L6lmXMLOs23x/XtCbJjx4hxHaPR XT5Y/JAQ741O8yqKgCJwZBCw639tNDVdPbCHZJaWyXNzV8hTK7fKnX0TQIRB8A+KqcpxpISL9rhx 44zWwwhHq2cf/XtWQ1uaK6l1cfGmBkT/GcmJ5j2aP62oT2pQ3Lc5oXZHwqCmRFLZsGGDsHGtbd8/ fke/HoNFaCZsbA4lOZAwKPQNkvxefvllufbaaw0BkwBJbiRKEhWJaF/j4XG4H02gJHYen+Oi35PB NtQy2Xfwq6++Mofi34zoJIFxfNznuuuuM+ZdYsHoTwbn0IfIOTCQiNGwJG4S3BVXXGHImxoof/fu u++a7zk3BuPQx9ka6REkP8piRII+tHyzbC0sMdemGNGhNHe6w+/XXAoD/dosCPHacWNlIlIdaCZl FGk7/F5FEVAEjjwCdk2ChIOmpHtGDTRlol5esEoeWrZZbu+dIBOiUUC4vjzVkaBCkgWJiwsvF28K ye/qq69uyOFjxRiSEwmTUZEkHGpp1FyoFdK0Z6Ua2DbTbe6y85z03919993mXI2DZaiFMVhl/Pjx e0SL8tgcx6uvvmoiOqm9MgWBqQ18z+8s8ykJaW+tmqyx8Zgkd0aDMuXBOgeDWUgAJCpGa95+++0N FWh4bgYQ8fgkdmqEfDAgiVlpJBbR07xMvCxs+bnVC5HnIqE+8MADDccmHtyOdMUYVjBiNaP52QXy 2IrNklVRI91C8TBhOsTDrImSZiWmkTGCpHB/MnWCD3O2QTA0ffaLCEGgi+eR/xevZ1QEFIE9ELB7 EuRomUD/yNgh4ouF8T8gwnuWbJSrEuPkzIQoCUeJNbZbOhKRo42b4XIBtrQzfkczKBdsK7Gd+YQM EElNTTWBHgyg2d/ITusq8fg8bmONh2ZMkh83nq+p41rjsfyIJBWrWa4tuR3IvwmrWIDt7y0iIrlZ 5+D3lgnUyuHj91b1GOv3tn0PSai2TYBt58z9Gh97fx4kDmRue9uX5k8P+PNyQHI/pmbK6xtSEaTV Vq4f3EvuHDkAkaAlshLBMcvhw16blStZqBrDPpilIP9cVHmpqYWWiPnX+S/bmOCYxJDAlhqeHkcR UAQOEgGHIEHOjcWDHxo7WKL8fOT5BSvlv2uSZD0qypAMewWhAgoWpKoj0IG+cTNcW03EIiJ+xgWb miODN7jwnXTSSTJx4sS9pgo0dw2bW+xJfnvziTUmxpYgjb01A7YltObmsreHgL2Nb3+OfZD/Bvb5 M1O/Fv/bgHy/tzamyY9pWZIQFCA3D+kj1w1Gg1uYPyPQN3AgclvrbAQiO0FybH3EvoIrQIwpSH8o hN8wH2kSmSVlsjWvUMbFR9t1t5F9AqM7KAJOgIDDkCCx5oJ/9cCe0hvBBAxB/wX5VxuwuFydGC9j YF6K8m5vTFVH0lfY1D1AoiBBnXHGGXLWWWeZXaxFvCUrm9hGijrBvWh3U6Dvjz37sqHJzcsqkDc2 pMgWtPk6uiMCtsYMQjpEdLNjjvL1QXSnD4K74sw+NJduRArEapDi3O07JRykySAZmktVFAFFoPUQ cCgStGAaFRcp75w8Xv4LjfBjVNW4Z/EGmRQbLmd3ipaBIf7ij+g6RpAeCRPp3i5dY62pJQmw9W4Z 5z8zTZ9eeIgpQYDOosxC+Tp5p/yERPgIWCFuHtrHpO7E4P2BCMmUD2/czuvd9UB+qvsqAorAYUTA IUmQeND89NSE4TKmQ5S8j+r6P6HSxl8Z+XJ+5yg5LjZMegX6ig+i7spbIZ3Cul5Keofxzj0Mh2bw inc7BPngnlmZXyzT0nPko83bpQJBLqcgd+/Svt1kMl5VFAFFwHkQcFgStC7BiV06yBj4Vj6HRvgJ tnfWp8p0LF4nxUfImEg8eYMMfevJsLU1Q+e5bZxrJiQ/L2hqrE/LerXzUeLsu+RM+PFKZShy+C4G +V0A7U0LVzvXddfZKAJEwOFJkJPwR9DMVfAVHt0xRr5at1W+25wsr61Nlh9gwjo2JlTGotLMoGB/ CUAyMyvOMJpURRFgio0na70iinNOZr7ZfknLRKRnuQyIjZDLBvWWs3p2RhJ703VVFUFFQBFwfASc ggSty9AlOEDuGT1QTklMQBHi7fI1+q+9t2m7/IRovvEgwqFhgTIkNEDiUYKNNUgrW6kEm+PfNo47 A8ahsFILg17SyipkKWp7Lob293t6tmSWVcpImNdvGTlQJiGgpQ+CrVQUAUXAuRFwKhK0LhUr73M7 oUu8/IWWNN+CDL/dth0mrp0yCETI1kzD+ApC9HV3M6kV1bvRv14VRKe82xl/ySotTHWgv4+kNz+n AL3/CmQ5SLC8VgzpTU7sKEejiktXPEypKAKKgGsg4JQkaKsZUjvkArcyK0f+TNkhX61PktfWJctP CKzpjUjSfsF+MhCmUuYasvhxNdIb6DskISonOuY/ApN0UF/bkyZPEt9aFKteBsJbhW01gl6Si8uk A3L9rkTLrokJsdIfTW7j0LJLRRFQBFwLAacmQetSxvj7CLeJCXFyYe9uaF+TLT8gmnTqVgbRZEvH /2fvPADkqso2/GV7zSab3nvvIQkhofdeBQEpvw3FgoqioghKEURQBESQJgiogPTeO6QnJCG99769 7+Z/n7N742TZTXY3W2Zmz4GbmZ25c++5773nvOfrql/YRyrSMSJM1KUj26W6fI6QIebDIFm3J8Xw HBwB6ZG0mvAGShSh6p6/K8+mSdr7XKS3SqS3Lq/QSpSt5TglZr/6iL42SdXfB2e28wmrw/O2+l55 BJoFgVZBggGSCfIAJGcj28mDetvKnTn20bpN9ppUpR+uU023LVn2jALue6QkuRCL0ZlpIsR0V8ap QmwYkCCv7i8vLTbLQxp6koDwlIBsT5Jql3paX2xTRhYkPkhvoQhwrUhviwLdS/Xlwd072aWS+g6T t+dASYDd6xnn1+wX6k/oEfAINAsCrYoEQxHtmppibAfLC/CiUYOVy7HAPpL98BVJh5+s3yJbUbZl rI+3tirr08NJiWk2RtXCh4kU02VHdI3EyFUHrSRIr0ZtzKe2JsKrQtlhnV9WoYxB+SpnlOO2tcrX iadnlvJ7UsF9oojvBwN6G8kVekrVSZYWqsD75hHwCHgEAgRaLQkGAJC2CqmAbZzsQl8bNUilmwpt +oYtqvi9xT7ZsNlVDJirSTYxZrMIMM55lw6TynRIhjZNrh2TEwxadNURXJLkyqP/z67oyXFfQ646 2YXihyq6DKclHQBJb1lOvi3OyrelesWulyMiJL6P0Jdi2XMrRIK927V1mV2+OmKAdVfqMu6Lbx4B j4BHoCYEWj0JhoICgXVKSXYb6a3OGz5QFb/LbI2KoH6sYql4ms7atNWmixDnSuWG/Qk7VCdVshjS NsWGSoU6UK+99fu0hFhHiMGGSz5B2ahRnTq1Srfq/m4FalVoqJKLKtWYvHev+g+iw/4K2ZU5p6Td lqNq6+u1GFmmmL0lwn9JdoHKFpVYufDCTst+KYoPPUiSPDk8x3bpqGruWfbQnEW2fFeOS7L+wdqN 9s2xw1SwtocrVuubR8Aj4BGojoAnwX08E2maONlI0XaQVGuXqcBvnlRtyzTJzpZzzVyVzpm9WfFl UqVultv9ewq2dk402ijx1Cc92frqt30lZfZNS1aC7wTnpg8xQopBvTnc94NEypWEWGV/rCLHcLZB BjIW0lYlqVX+ExBc8DckVy72gugc4VWVvyLh+dbCElsl+x2S3Wq94sSyrVg1+XQoV4tPmHH8rpK6 x3Tu4CR2vDmHqo4f5JYklTX4QYbnKK3ZS0qsft+shfbO6g32zqoNbt9vK5nCSVKNUsOPxYtvHgGP gEcABDwJ1vE5YJJNVT1Dti6yJU7t2VU14qhYUaGyOQUKwdihenLbbYFSbq3YlW1ZkloW5BTanF35 qiCwxUqktovT5Euliy7aumky7iqi7Mp7bZ2SEl3qroAY9xBlFVmGkmaVW47ruRMoQyTJwH1nL0/W kD+qe7juxQchf/zv7ZfJrYrnHNuhqAwIDekMoquU6qpe9TchCtuKS2yzgtE3adssZxUcVtx7lRYq 0T44LcUrews2u1htPTPSrb8cWJDInTNT1w5Otcn3LBpqUnFCmNj9vjF2qH1lWH97dflau1dkOF/3 5rKX3lPsaKZ9S2R42qA+zh4M1r55BDwCrRsBT4INvP9Mn1QGYOsvhxm2s5SpBkkQdd2G3HxXM26Z 27JURifb1qseHYVW1xZKmszT5I8dS3/jzg95dEyK15ZgmZJu2iXGW6aKCbeXE047XvU3GzZJR4hV 6tVYFxJQqWrlfVDFPNT9g8/+J7FVqnADAg0N/3ClmarwIKOOK//ktsowkSBkpPK1kujypLbcIYLL KimzXXrdKUk5u7jMdkqS20VBWb1uk6TXpipFWYJCTxJFdpAe73u3y3DhK4MVnkKQ+iAVmiVsoXta JUmFVmSvz61qK8y+OmKgnaEA+NdXrLP75y6y2Ru32Q9f/dD+Mu1zu2zcMDt9cF/rJbKlL755BDwC rRMBT4KNfN8rScisT0aa28hAEjQy02wUOVKFfL17LbANIsb1cvLYnF9guSIR1IObRSxrihTTVp7n pCjIkq1UhImqFUkpReSYIjJxr1IHUv2AvykBlKT3qF0D9WSS9lH5XTfZI0VxDGixVK84lbAfpBaU n4ISitQP+lugckJ4XBZIksX5pJBq6dogvwp9z8XGi8wSqoitkuAgOkguwbolJdvAjvHWVepgyg/1 kErTvSo2s2d6mnNIIiazqRqq0jO0ODm9igwfUcWRz+T09LO3PrG/TP/cvjVuuJ0xtK8Nat+uSfvR VNfnj+sR8AgcGAKeBA8Mv3r9GhLqqxALtpraLqkItxYU2o7CItup9zv1ukPqQj7foc/5LBuiJM2b Kx5cSVQUbC3Q++xSvZcUVqmSrPSo5J9KG1yF5ei3rmKCpElsj7x3pKjGv5Cr40i9j1PAOZJYnD5L iJX0mRRjmU4Vyd+VEjBE21bSaYfkZGsvdW4HxVd2SE609to6SN2bmZRkneRJy/uWbpD+ibIJsr2/ ZpM9Pn+JvS9Hp9+8O93unD5fatJhdqbIknR7qLx98wh4BFoHAp4Ew+g+Qx5sdWmFktAK5LmaL/Vj vlSRSGz8XcgmSa1UUlulQ40Shevv1dk59rsPZjpnku8oaBxihMSQwpwDikiC96hWUYVSXQF1ZYoI M1Xq2RTeI3Hqfao+4/NIbUcoSTYbEuGTC1e4ZOs3fzDL7p6xwNkTz5TUOL5rJxF8QqReou+3R8Aj UEcEIncmq+MFRutuySIktrpKWbPkxfq792fY8I6Z9v0JI6MVlnpd1+QeXYxt3pYd9t9FK+z1levs L5/OtXtnLrSLRw9xZDhZIRh1xbheJ/c7ewQ8AmGBgCfBsLgNTd8JwjjilEUlLYIluKZCKUild9Go Ifb8kpX2irxKH5i5wB6WM81XFSuKPfFwSY7d5J3qm0fAIxBdCHgSjK77WevV7JJtEftfhmx3vtWM wGCV2LpqyjjnVfry8jX28rK19sSCpW47TUR4+uB+ruJEbTZdj6tHwCMQeQh4Eoy8e1bvHuMEk624 RZxaMhSC4du+EeitsInLVVX+rCH97S2pSF9Q8P3TX6ywF5estmNUlutUxRlSq3Kwwjl88wh4BCIb AU+CkX3/6tR7PEMrJUG8OT0J1gk07dRVsYoXyTZ44sA+dr6kwxeWrrZ/L1hmbyvJ+tPKToOnKXGI o5TFxjePgEcgMhHwJBiZ961evSYGEEmQArMZCZ4E6wWedu6o0I+zlY7tKOUgvWDkIHth8Sr7p8jw 49Ub7dklq6Qi7eHyzB7UrVN9D+339wh4BFoYAU+CLXwDmuP0jgQVI0gcYLqXBBsMObGQJ0gdOqVH V7tA5beeW7zSCL6/9aPZLl/pkX16uCokU5RSzzePgEcgMhDwJBgZ9+mAeklMYJZIME551TIU3O7b gSGQLgwPVY3C8UrMfeHIwfbi0lX2wNzFdo8y0Ly+cq3yynazS8cMcZKjz056YFj7X3sEmhoBT4JN jXAYHJ8E11nKNkOIhPcObbwbQsKA8d062ojO7e08PEolDf599hf26LzF9vbq9Ta5exf7+tghdlz/ 3j4/aePB7o/kEWhUBDwJNiqc4Xkw1KFZxcWVNkGvDm30m0S+1GEd27sE4K56hRxn/qaA++ckIVLT cLxshV9XJppT5GBDaS7fPAIegfBBwJNg+NyLJusJeUSznXdorLcJNhnKyrcqm2tfVbUnLR2ONG+s WK9UbPOVq3SjTVOKtpHyIv0/qUn5rp3si15V2oQ3wx/aI1BHBDwJ1hGoSN6NRNmUOeqmGnrtE32w fFPfS/Cm5uTFowfbaYP72FvKTXqPJEMKMP/49Y/sr8pG840xw+wcSY2dUpL3JDFv6n7543sEPAJf RsCTYBQ+FSTSLlLSbDLEUIQ2VzX98pRoO6GtSi2prJJvzYcAEt9Xhg2wUxRg/7Yq3d8nMpy+cav9 /K1PnZT49bHDFF7RX6Wl0rzdsPluiz+TR2APAp4Eo/BhwA71oPJekmCbfJfUIqQ0EpUnnlNcW1vZ pdJkG+yoEkcUtMWm5VvTIsC9OFU2QQLsP1B84f1zvrCP12+2a9+bbn8VGX5j3FA7b9hA69c+3d03 3zwCHoHmQcCPtubBuVnP0lkqttmbttuqrJy9auOt3JVjFzzzprNFFcpGeJwqqz9yxjEiypRm7V9r PlmcVKUUWmb7eN1me0ShFe9p0XLTh/8r5fTV4QNsSIf23ommNT8o/tqbDQFPgs0GdfOdaFSXDtZd EiCkR8o0V2Fek2/QXC1B1Qec0L2TJ8Dmuy1fOtNUxRqyzdGC5dH5S2U7XGe3fzrP/qa6hpeOGWrn jhhgo+VMQ5C+bx4Bj0DTIOBJsGlwbdGjYgc8qHtHm7d1u6s6H0qAOG0UyWZ4SO+udunooS3aT3/y SgTGKdaQbdH2XfYvpWN7fcU6OdLMV8zhQrtImWm+opRsExRm0Tk12UPmEfAINDICngQbGdBwOdzh vbrbM4tW2qa8Qjlc/E8KpIo8FeQPViD3EF8FIVxul+sHsYbXHznJxRQ++cVye01k+I/Pl6iu4RI7 VyrSc0f0t0N6dLOesuP65hHwCDQOAp4EGwfHsDvKZOW3TFZGk3Jli7EQv5ciOccM1WSLx6Jv4YlA P8Ua/mLKeLtEkvqzyk9KkV8SdT8lKfFkVa0gtOIIVbEY0D4jPC/A98ojEEEIeBKMoJtVn652b5vi Mpiszso1pL9AFoQPR3fqYJN6dK7P4fy+LYAADkvfmzBSIRQDlKB7rb0qMnxeZPjKkpV2lFKxnaWg +2P697ThWtT45hHwCDQMAU+CDcMtIn51eO/u9tn6rYoRrKwgQahE17Q0TZ79XPygb5GBQEd5+5Jp 5kxJgedKCnxZZPj0ohX2rl4ny8uUIr+kZBurhN6+eQQ8AvVDwJNg/fCKqL0PEwn+Zfp8lVHa7TSi ZXKSGdghw07ShOlb5CHgAu8lFZ6gWEOkQxJ2/2vhMrtm1Qb7r+y/fA5RHtyjS+RdnO+xR6CFEPAk 2ELAN8dpR3bKtExNnFvyC6xUoRId5V14ysDeqi7vkzg3B/5NdQ5KOZ2k+4hdEDJ8ZfkaF2Jxy3vT 7Hkl7T5WJZzOkc2X7/fXtuQVWBcfJ7o/mPz3UYyAJ8EovrmpCXFOKliTlWe5JcXWo2OaK/rqW3Qg QCmnw0V0k3t2sXMURvGaJMOHVcbprk/mOpXpEb272VdV4un4Ab1kE/5yuu7tBUV25ZufuCw25Dn1 zSPQGhHwJBjFd52YwGNkM0JVlqpUacfJiYI0ar5FFwIJSns3UXGE45Qk4SzZDN9QaAVp2R5WbUOS d7MQumDkINkO++6Vn/TpxSuc1+mHaze5nLLeYzi6ngt/NXVDwJNg3XAKm73KVBYpr7hMkl2pFStJ 9u4q38+islIr0d8ExlM/kCTaLP7JGFNuFVKBJtiYLpn2+dYdmghjLVb7aTeLVwwh6jXyVabGezVp 2NzoBnSEUk6owPEWPWNIP3tHhX2pa/j0FytU13CTPdBtkSPDc114zG59vtKK9Byt07Pyy7c/c+E0 SI6R3Hjus1UxhYTxQcMhjM+RnPu0S7e0Wp7zHYVFtlPFpwNvasYIvwnGB4tK36IPAU+CzXxPd4t5 KpiCqoiKgYdaarted+h1mzZec1QEN08DN79EhMegLi11A5kBTdozJiz3X9WIFTfquPxR2SBCGi8l cojJriix374/0xFjTIhqDNJksDPAY1V1AjLEZkjxVyYAiJFCvJlKtp2ZnOhK/2SmJLrk251ULigj IcFVq2B+4Fh+mmjmB6qG03EvB7Rvq224nSwnqPdUz5CKFW+uXG/TVdfwUQXg91LA/bKdWRavxAl4 DpNi7+p3RIR6YC4UUbZkc4s4Leh2FBS68QAxbZdde4Psl+2TEpxE27UWO+bj85epVNV8t0jkuXZj QFuBxs9AhQzddNTBdmivbjVe3odrNtnNH8+2LTpvgjDh5zFKPF+hwdVZz/rVU8c5PGtqm/Lybd6W HTpnjOtbB40Vxgxe2G5s6EehmZtaEl9/7r0R8CTYyE+Ek7yqSIqqDRty8m1dTt5e24acAtuqQZ0v UmPAs/Gb0PeOLDV6K0mzkux4jxSXJpKCqJJi4zVIK4mOwPhETWi8Z9Cx2oXUIMv1uXmqFBFnKfq+ zJFvqTsX+5WU7RbhlmjSgXBLJTVWxtY7QqsizEqiZEIQWeqYAWlCpvFxMapRmGTd01OsV0aa9VJJ IF7JatK7bZomgyQ3yfIb+uNX0438wO3ncD3SU+1rIrUT+veyD9dtchUrPlX1ik/1TLFkQXqkJen5 WZ2da79+d5rTHlw8ekijL2jK9CyWk8tWz1IlOXx5ycQ4uHPafLtn1gIr0oKvjZ7nYGwg3Y1TGMj4 rp1qJUEWZOyfrkVcQmzltcVrzMS0SbGeejbJllRbY/ygMSmuKHckWCgiRruyVURcor6TgrC29vmW nQ67Ndl5bvHI8w62jNPebdPtexNH2HH9etX6e8a2J8nmHRvB2TwJNhB3pCs8Lks1ULOLSm3Frmxb smOXLd2Zbcu1rdGEsi2/0El9oa1SQKtUYiJldUxJqtqSnXTVOZW/ky1DXp1pSGIazAxMSA1HFwa2 I6NqUld1KSz4HhLcKMLtxKq0alJwhFolNdIPCJHPeIW4A3USJA0xZksq3VHAVqQJodAC6RWvUwh0 l1bqVKyw9f8Lymd649hIlBBkf2VBIU3boMx2NqRjO9XPS3WEzmRIv4JVewNvh//ZfhDgOTtLKtLj +vW0Wz6ZbXdPF8logmdhQuPfJGkBmMR/o/JOENalik1s6H1BVQ+JQFzLQ8bGfElL3PtfTh1fY9o+ +sFCq7SswmkgSBjQoWqMIFkNkTTXU4ur2hrqXlTBVZdVeW1VY4UxsS8SPEbYTFFCcwipcpRWLjDL JQmyYEAtWlsjr+uRfXrYCo39narQwlhhnDAHMHZyZcKorS3Tb15bsdaNdRKm99L1JYuQGReMD6RL r4ltuiHuSbAO2LIChByQljblSu0hu9oX23bZsh3ZtlhJjzeLDGis/NicpKRRCJFRrw+JiAebwct7 PmPQpIjYKgmtSsoKUU3WoVt13qWtVEgH2gIpFen0f+93u8lyV1GRbRQu6zSBrpPUuVav6yUBr5UE zESwSllrVuzMcbkwIWUWDxD6IKX9GixiHKptTNcOjiAhTVSyrKZ9a3wEwJf7lFNUYkm6B6Gtkghj de/ypDqf7u4zQfqBtFjX3iBJ/nvhcrv10znShOQ51QT1LCFcnhcWkCyuamqMh8vGD7NvKH8qchzj KFj0uVfoaB86d/q/L6Lb1zWwwEyIbdhYGSOnpJGdJu+l0UHrsl0kCCn2ky2ytrZCquh7VDlkvcYQ cwFam77an0XjMC0YyQxEXlnfmgYBP9PUgCsSEBIOtrglO7JszubtNmeLNpW82Sy7RJI86ZioKwdN rJvI+8kGM0STOKnKsMf0zkh3El2gRox0e1kwEdX0GLYTyZLv0qq0PXskS62lmew25hY4IlwqGxQr ZTCFNBn0TAB4KLIfxX1HyLEDldc4qbwgRmojsgJHKvCq1AOfBMhF+pGcZGpTvcEviXq2N+je/O79 GU4K+ubYYXuIMHA8YSHTRfcGFWL1Fjwr7NtHzwXjgQXOYCVqGKC/++rvHvvwUo7EosLumjXYq8uK 7fTc7q8NFdH9YNIoW8TCeleWFiEF8hModCaU1yUhju7csVYSRPWL5Frfhcr++tSavvckqLuNs8kO qfR2SmpZqAeRYqefyG6yQBIfkguSVLocQHigmaTxwEOlNzCzcnB3TUuuMQ6rNT1IodfqyEr/x+of spywDe/U3k6x3nt2Y6GxUmqy5ZIQIccFW3c6NfKOwkJHilRPgBiRoHHxn9qzq03q2dmpx1CLQYq+ 1Q8BiOtFxRKu3J5lcZICC5HGAiNyiEYCgmRSZZFywwezrLC03I5SAD4LGOyKhFTgrPLYWcfYFN2X mkjwFKVym6pyXdw/n6Jv3/eprxbM31eO2KCxeMC8sET3CVXyeJXZqq0t2LbTXlqy2sarNigLDMYG 6mPvoFb3sdFqSTBLKgpWu6sVSD594xb7SIP7s/VbnNoTVSVekIfIPjBYkh2kxzZK+noeMN8OHIFU qTvBky1oqMoWy64KIc53Kued7h7N3rzNZUUp0KQ9RGSKd98hmnxHdc50pIiNyUuJ+78nAZnhRAUB 7sLruLjUPfPYB4u1GMTGXSDSy1W+WQXYOPyvfPPjKjtZmz0ewuCO5F5bw5OYzbf6I4ApgMU22/4a 5phrZcOtIC+wyPRQJUg4VPPWuC4dXSYg1LBoq3yrHYFWRYJIeriCY897Z80Ge1M2qo1acaWL8Hrr YTlcD9BwPXgUMB2vzdfba96hg2dfsOA4vypeDQeDuVJFzxIRzt28w1ZpZfyasqE8qEBw3NcPk7Rx nDKiTJa0iEoaBxzfakYAT8WLVaSXLbRlEYJAqE7gyKFXHKDweHxz5TondeOcRYgBqdgIzB+pxUtD bW/+/jQeAjjS3Hj0wW7huFJz2TRpsJ6WPdZEipPlqPP4WcdZ//a12yMbryeRe6SoJ0Fse6gMUHO+ v3qDva5BvV1OG91EehAeGTZ4kCC9sTJue916eD3MSN547bHRcOpAMpwrO+1C3dclck667j3ZrqTq O1QJw9mPSXqoJEZsUb7VjgDaEKSEdpLY2Aba3vUJd+n75xavkiNXivXNaCsv31TnuORb+CCAw0zg NIPUPmvTVm3btYDZ4WzpLCx92zcCUUuCi6QmmLVpm9JGrXPZ9rdL7dlNhnkqqo87qKN7PaRXFxfH 5lvkIOBiEbXhBk/DaYm4t5kbIcZtcuaYLvdVEaLIkPJCk2VHnNits3M/960SATQhMzU2cLo4TNoP KtnXpNpsL1su3/kWGQhgFuiR3s9OH9zPeeFiX89Mqnl+wz5MGBeLIDzWW3OLKhIkvg273iey772s AT5L79sr0wN19SYe3MkO0mR4sIrJMrh9iw4EKj1JKx0H5kltOmPjVkmK2/UMbLar3/jIOigc5dSB fe3Ivt2dg01rdTXfJvXmjA3bnMMX+USnaVOmA5fUgAkz0ZuNomNAVF0FEmAXzX21tU3y2P7Rax+5 cKWTlEAdrdhBcq4hVrm1taggQcIWXhXpvS5b0ZuqrbZTsWoTtMK9+vAJlU4UmvzaeyN91D/bY+QM wBYQ4qdaBL0jFfh/FRbwyNzF8i7topp7vewkeS7yTLSGRrgKCdQfnbvIPpW0vEM21d7C6DuHjLHD enW3ST06ucBs31oXAgm653iSEjLzpp6PrvJyP6pfdzt/xCA7UWW6yJjTWlpEkyBxNM/LPfilZaud AZ/4ojNVNf14pYia1L2zDfUBpq3lOf7SdQaESELoaRu2OgnoBYVe3PDONPvPwhV2yqDeTqVal5p7 kQ4iMa4vaaI7WgV3TzvsIOf4NUmLgCCtWKRfn+9//RHoIg/424+b4vLEoj0jLOlfcxa5/LLMnz/T IolY3dbQIpIEcY54QhW1X5Hk94G8PFnRfH/CKDtjcF87SCvbdole3dkaHt66XCOq7xMl/bF9VQVo 31eS5CcWLLU/fzzHntMC6liVlzpXzlHHaeBHYyN05Otjhor4OjvHr/7eWSgab3O9rwl3GULBKM7M hoPgpzIjPTxvidOekDKvtbSIIkFimciA/7iqaH+gyayLclJerRyEp4r8iIsh/imc2tatW+173/ue FRQU7MlHmCiCHjVqlF1yySU2aNDe2fp/85vfWF5enl1//fWWnr63W/Pbb79tbL///e/3XGJWVpb9 +9//tnfeecdyc3OtS5cudtJJJ9nZZ59t8VXlYnbt2mUc96c//an161fpTELbtGmTO0/79u3t5z// ubVr187uvfdee/XVV63ExYjt3djvkUceccd96qmn7IUXXrAf//jHdtBBB+21I33kOFz3UUcdFU63 Y0/sFYRI0PfDUpHeP3OBcxA5Q84E3zloeJ1is8LqourQGbIYsYVbu/POO+2tt96yUiV0pxGk361b Nzv55JPtnHPO2au7n376qd122232wx/+0I488si9vmPMXHfddXbxxRfb2LFj93z3wQcf2JNPPmmr Vq2yBCW74Fm94IILbMAASklVtrvvvtuS5DzyrW99a69jPvroo/bSSy/Zj370I5s6daqtXbvWvS9W Ht0gt2joD+gX/V63bp3dcMMNNnLkSPvud7/rzhu07OxsN+Y4H/vEhJHKkQUS29FyKNullHqka2st LbxYYx+oo+68d9YXbsIiVdCVk8fY11QNe6Rc4cM1GHTnzp323HPP2XnnnWcdO3Z0g4cBy+B67bXX 7Pbbb7fDDz98z1VDQLNmzbLx48e7AR3alixZYi+++OIeEoRgf/vb39q0adPskEMOcQS3ZcsW+93v fmeLFi2yn/3sZ5aWluYI+Omnn7avf/3re0hwx44d7vv333/fTSwMShoT0sKFC91gplXIaB68QpJB 41q4hlh5lv3jH//Y83mhvNHuuusud4zMzP0H+rbUIEMaYjtKcVQfrN1of542z+6aPk9S4ka7cNQg l7uyfS1edS3V532d90NdA7laz1N1+SAhdjj2s3qf3njjDVu+fLkdf/zx7isWX+vXr3eLstmzZ+9F FHz+zDPPOMIcPny4de7cec/hICa+O/roo/eQ4LPPPut+z0JzxIgRVqT8tq+//rp75v/whz+4MUaD KFlwhpIgxPnLX/7SLSj79KksncSikYUf47Jt27Z7xgbflSnZAJ/RMjIyjHHPuY844ggbM2bMnn6+ ++67dt9999mvf/3rsK0Y0Rpjo8OeBKnTdfun86TCWmZULThFnn4/OWS0C3EI9yTL5QpYZdV57bXX Wv/+/fcMdFaLV199tf3pT3+ygQMHWvfu3fcMIAiJQTpp0iQbMuR/KgkkyGCgsTMS1+eff+5I8bDD DjO+z8nJcUR54403OiLjGKw2GZgQFg2J8ZprrrGPPvrIrYLPPPPMPYOUfc444wy7+eab3Wd7sumL vDlOIF0yuH/xi1+4/jORBZMY5/7kk0/s1ltv3Wvwh+uE3FuhFhcpcJzKAf9SHbo7VWaI7BvYRX6q RRZqonBuxMDe/tk8+8e8xc4ePlbakGFaFEZK43lCa8FijsZ4Qbvxyiuv7BkDPI809kVS/Pjjj+3B Bx904ydofM4zHjyf+fn5Thtx6qmn2g9+8APr0KGDI8+lS5c6gv373//uvqelpqZaSsr/vChZ3PFs n3LKKfbHP/7RaUhoEB3jEUmua9f/VZoIxklwbsboLbfcYieeeKL99a9/tb/85S+WnJzsiBHJF6kS iTJSyyZlS0qcpgxbpNGLlnR4YU2CrHApBPuedNRD5ORy67GHyLbT25UeipQGeTDQArUIr8OGDXMr TaQxyAhJkYbkhRoRKZHBdv/99+81QEOvec2aNe6YrH6DAYjKEjXr4sWL95og+AOSZKUNwSFxMlBD CTD4ASQcqsKpCWeu6aKLLrKXX37ZDXRIEFUP/T300EO/pMoK93tFlpmrpqhgqpxl/vTZ5/YvLbiI pfvJ5NH2PeV0JMVbuDXSyl2rJAHYxZOV0P2HE0cpaXtkxXuxyKr+vEEYl156qS1YsMCp+k8//XRH GGg0WNQhwfHMTZ48uVZ1O4S3cuVKN74CiZEF3ujRo506df78+W6BFxBR8MpYhCRZVLK4DNV+cP85 RuhYru2ZYGEL+bKYZTwyJlggQsKoWUNJN9yeq331B0/ju1Sw+O/SyJ0lB8RrD5sQFWkkw2906y5g +2N1+/uPZrmqDefLg+k3Cneg5E6kNQYbq8jqjQGNWpHBHpAgK2FsCdg1rrrqKmd7Y0KoqQ0ePNit ZiHTyy67zHr27OkmFAYq9pFgYLsM85ISkACR0B5++GGnqjn//PNrPG5N9o6aduR82AR/8pOfOJUv q+/Vq1e7Caq6PTMS7hmeknjD3XPS4Ur83M1u+nCm/UaV1ok5/K0GOwnTw6FRhujpRSvUv1kuz+rR fXvaDUdNUgxsp4hcmfPMV288r8cee6x7tiE/iCdQOUJi8+bNc1IaY6VTpy97MLLgwzwAkbHww1zA MfgcCQ9bdagkxiJy5syZ9v3vf98YV4yTmo5LP+s6Pr797W879SnaFoj4gQcesNNOOy3s7OT1eaZx shqteEIKMN8zc6F9oYQkNx11sPPEj+QWdiRI/bmbRH73zFgou0yC3SiQv69Vbjiuxg/kxiNNYTdD TRI0V0Ve0uCFF17oVEKBqhNVanX1CerOgHSwh2C7mDhxolODoq4MjO6QIvYQVEj/+c9/HCGywq1J HcO+OBGgcqIvoepQJpAJEybsUavSZyYU7Ii/+tWv3OoW1RWTVyQ3Uk1dNm6YS6X3G1UKf1KepEs1 2G87bqpUQJVq65Zsd06XCvyj2UbR2p9NHmtXHjJWQdHJLdmlJjk3iywIDMcuCIwGIaJFwcnrm9/8 pj300ENOdckzHdqQJm+66SanMkWzwqJs3LhxblygIkWdGTSea0gV6fCLL75wanxs6dUbYwN7PmOD xWtgL2c/iBxVKU49QaPP2P7oJwtFTBUsbCNVDRpc1ymD+sqenmHXyGzw4tLVdlHWW3bzMZPtTDmW RZI9OvT+hhUJIvVd9danzvtzjLKA/EHgHitvpWiuEFB9UDCgGHA4uEAyvDLYA5tecPOQ+q688kon 0bGK/fDDD5097p///Kcz8jMBMBD53bZt25ztDlUotkScYaZMmbLHFhkcEyLDoYBJofqKl4HPMZhg QvvAuVDf8jnON+Hk8dbQ2ZnnbYoC65845ziVEprp1D/ffPEdu/ukw+xkpWJryUbSB3J4/kQ2y0vl GBbNuW5dDc6QCro8k6g6zzrrLHvvvfecjQ1VI1qV6o0F4fPPP++cxIKxgYkBD2fsdIFjDOMINeh3 vvMdZ8fjOxaLkFdogyxxjkHFiuRYfXxg1/zqV7+6128wVbAoRQXKgjbwC2jJ5+dAzw3RjVT1lodO P8puVZjRHVqUff+VD4xE94TixEujEmktbEiQen6/lPrpMRHgkcpU/+cTDnUuu9HaWEmyyu3du2bn C9Qy2CdwYsG7E3IJnRA2btzoVsA41WA3YYWLl9y//vUvpw494YQTnG0DUsVYz+C9/PLLnTTHJMKg vOOOO/ZaRbPSRf0K8VZvnDvwIg39DrdzPFyZJPDCi6ZG0djbJQFSVuvWT+bY5S9/aPef1kbBxC3n MHPJqCEK9O+rnLeJUU2AeIPyTGHnDm2oRSGhK664wkllLOhQjYY+m3gpMz5wSuN5Z0PVia0cWx3k GXg1sy+EieoVSW7u3LlubGBzDH2e2Q8SQ8VJKFL1VtPYYMwQksHisTpBRvo4yVT87fVSw5PH9zcS XJ5TsD01JMlfGmktLEgQ1Q72v0cUqHmk3NbvPeXwqClj5AqUVlPX8JB89tlnRqjCvojja1/7mhtA 2PAgulApi8GP8R97HI3vkMa+8Y1vOHJj1UqDbJEIIUQaAx71DI4xrFTxzgtasG99bXo40gTOOZE2 APbX30StbK+TPRrp8GapIa947WN74uwUG1+Vr3R/v2/s71lpd40i9Wd1DQd4sXDjucfmF6p5CMUS 5xMWiag70ZSwAAyORUwf4Q2MDZxhaDyjvGccYWrgWWfMoHJFVRqoMll04jAGEYY6pgW2dWyF9Rkf kCNjA0KPtkZqtW+NHaYKI+mWqDRsaCgisYUFCRIAf4+ClnHx/ssJU6OGAAMSQsIKgmwZdNjyGGQM qICcanp4UE+iZvnKV77iHE4YrEFDAsPjjIGKLQ5pD5sJsVAQb6B6CbXrBb8NyDVY8QYhGkwKOLhU DwjmGHxX20AOtR9G4iCoS59/deh4V+n+tk/n2tXSWPzzjGNcxg3fGo4AzykSFs9bQH7YyAlTwIOZ xdy+bGhIV6gyCXnA8SuQxnr06GG9evVyDi6EJ/E3jXGHyYCFZ21qezQwaE2wOxIv+H//9397LhAp FO1N9XEAofJZTYTOd4Gtv+FIhe8vIT8kwEhuLU6ClDz6g1RNFO28WcUhR0eRCpRBQTAwGVsCYzok g0coBEewfKiRHuM5TiyhjcBgVrxIeMRQBQ174Zw5c5wbNhMGx4dsMfBDcvwuIGF+F2Tl4DPOSZ8g TxwLsIPgpMMgxyYYZLgJDZZHLQVp1hQ+wXmjcaUbeh9iNWFfLSJcoQTUTysP599V1Pca5eH0reEI 8EziAQ2x0FggosZkzBCUHiRt4DuIkjCc6rY4Yu7QqmAXDzxNcWzBKYVnG5s1alFIjxAFFot4bgaN Z7c60WISePPNN52KdOjQoU41ijYH+yJOYEiCoY4xjBvs4aGJL4Lj8x3jr65epQ1H0/+yoQi0KAlK wHAr6/VKhP0rTShkL4+mRpAujiuQSqCehESQ7CCq6oZyVJOogEIbA/Tcc891gfGhcUu8JygeewcD lgwyEBmDn5RTgXoSVSgxfdVdvgnaZaUMkTK58FscA5gsgr4G/aAPTDChAz+0j8ccc0yNq+Boupdc CxXWrzt8os1XFW80F8RKjZDLeFO0EuFdqgGSWoMqvSnO1xLHZCGHujN43njO+vbt61ScqC1DG2TE uKluWkAtCjFBpqG2OmJX+RsnF8iPY/MZNjp+EzS8masv4Fi8ooGB7LBN0pAmkTwZyyxkq49RJNqa Gn1g/EX7IrElnp/GOmeLkiAVwt9UXbMR8jYiKDnaGsTz+OOP1/mycGipqbGy/fOf//ylr1D/QLK1 xfzxA8gSibN6Y1Ko7gHHqrl6DsW6dD50ZV2X/SN5HzzjvqW0ar9TEof75DV654mHNsnlzFVl8Iem z7eTlNj4dOXGjXTX+ppAwlGLrS4Ns0FtpgMcvdiqN8IdQtOW1XQevEJraoQ8oGYNGiEbBO/Xt0G4 2O99C18EWpQEH1MMFq611x8x0Vd4D99nxPesGgKXjh5qj85bqhJea+znU8dZz0Z2CCAzxwfKY3qf wjPi5YV3GiTo74JHIIIQ4BlGm5EUAZqMFiPBXUXFrvo3pW6O7dfLD/IIesBbe1c7KW3f8SrB9Igc ut6RJuOS0Y1bdmabFoafqMZbe2XiIEA/muNkW/uzFI3XP1dZlu5WerUjene3ryk3b7g/vy1Ggp9L 3bMtXzE6GujYWnzzCEQSAocrlhWvZkp6XayB3pjqyg25eTZj41Y5iWUqFKN1FDaNpHvv+7pvBFZl 5bpwtx35xUpC3yfscz23GAku25ktl/MyV/09ErMM+IHQuhEYnNnOKDS1dKc8//TamOpKMvVvzMqx IyUFEozsm0cgkhDo1y7dRint4CY5EJEGM9wLHrQYCe5ShpgSxdB0SElU4t/GnEIi6XHxfY1UBDql qpKJ2G+7VJeQYGM2EshXyFzQVp7EhGb45hGIJARSE+ItTdtWafoKSr9cPCDcrqXFSBA9McO7okKJ msMNlX30h9yDxPORzT7cGzFQBP2SMzSci9yGO4419Q/DP61J7B0MDB2+rKqocaTgQzwcsXmkMQut fRmu/afCAyFExPj51ngIUGcwqDUYCWu4FiPBTOU+RA26XeJyGeV+Gu8eNOmRiNfbvn17k56jPgcn WJ6Cot/97ne/9DOCkUluTdYM3xoXAVa5DPBOyhrT2LKac7wZOdDGqzxSJDUC2nneqOAQDo2am8QQ snCtKXXhrFmzvlQzMBz6Hel92KmEH8zrJHun2HO4txbr4WDVBkRkpnhpidQ/SVWVz8MdMIJ7G7so JtlbKFAbtKBS9n//+98vJRCujg+1CGsa4OzH56zI61vZgZIy1B0kJRW/peIEmTmIlSKbB0HLocck TpGsNqGNTBlUuXj//fddFprQxACkrrrnnntcQmOSA5DLtHo8F/lSSRx+3333uYwd4dbIdIQuY5jq DDa2NIg95ZGzjrU05ZyMpMZzy/PWmE5CCxcudNljQscGSRuoZVlbrc1gX+r4IZnWlM6MfZACa8tN WhvuBMozLgnOJ7sNJcxYgBKITyOrDLlMaxo7LEpJCffEE0+4vL9kbiItG8kwaJA2ib1JfsH4IU0i 10nMIo3zkbWJDDmkOiSpAAkuwq2t2pVj+HycM7S/Sz4f7q3FSHB8t44uEfD0DVtkPJX9I8w8RMkM QRonBjSDpTaiYUAyMHiFHMmsQlaY+hAPAepkeaHxOwYJ5Y/qMplQPDS00Q/UoEHZmYY8gNQnJBCf JNu8QtBkomFFjRTM8cmmT+M81TP98zlJAhj01CckI02wL5n/OS4TG2mpPv30U5fyKpQEKYHD9a9b t862bNnSkEto0t+gCH1fXqHoLI9QAd7GbolaEHZNTWnswzba8ZigGR88azzr+1oUkgaQjf2CMVRT 6r3aOsfzDanQGA+QDFlganrmqh8DggsSaAffBblKea4bksqM83/wwQeu9BJZZFjQBYksIELGDteH CYLzk6ybscM1bN682f3NwpUgerRKkB7zDBmkSH9ICjmy1XB977zzjvstC0aSXkCAYE8eYfKgMi4x c9RUSqrRbnYDDrRkR5YV7spVNqX2ThoM99ZiJIiYfFTfHi4F1UsqzvjDSaPCAisG9vTp0122CFKK 0UjhhKQTFPcMOgrh8XBTsJYBRfow6vWReJcSSTz0taUaIyVTYDdhNckWNB52Mmmg5txfg0gYMKx4 GSAMGGoKkqaJ1GgMelKo0VcIpbaBz7mCYqKsMJkkgsmN7xi4HD8oqRQkJWagV5/UIDBIkkwy5DLl dzRsRhA8q1eyf4BB9dRxLCiYSCgNxUAPzXm6Pyya6/tNufn2xsp1lqEY16P79mqu04bFeah8Qn08 pHuSXfPcMmmTvq/6og3CIAsSmgWkeRZQkBJ1/VgYsZiqqSG5kW6M4/EMjh07ds9us2fPduekSsT+ 2ooVKxxZoaLlmJRJoq9IYRTYRR3Kc0bjWmpLfQZ5BynZ0FxggiAlIo2+Ua+QfkGCjFvGXjBXQF5I eiT4RvKDHMnzS0PSgwhZGEKCpHQLpGm+Z2w89thj7rf0gf3AndRyBx98sCNPKmWEEwkiAb67aoP6 G2vdlESisU0F+7vnDfm+xUiQzn51xED714Lldt/shcrD2N96tm35Uhw4vTzwwAPuoSSLPQPmb3/7 m/sMlWBoQ2JhNQYRUdWB9GQUpA2qMVCShRVzTQ3pr/rx2A8ChdRIgF0XSTDUPkktQVaPqBIHDRrk JhsGEBMJBAj51EaCZM4P1EuBEw0laSAurpPkwAxE+gZRkXMRYmWgotKhfmGQrxQVJrkeIeEgiz7X hkSAKodJIsjDCLmiDg0ag54JhEkOybMhq/WGDIT6/Ob+OYsMIvzhpNHWAZ7l/1kAAP/0SURBVC/R VtR4PhkjpBBjAYRUdtddd7nUYEF+TBZFkMqf/vQn93wgKbGg5PmiugMNp5Ta0pBBHEhF1Su8MxYh LgisLqW7WECR+xMC5JX+QDz33nuvvfvuu+75CtKtYcekfFNNjQUtFVsY1ywOQ2sHYh6gLzzvtOpj h8UgC76g3FhAgOyLepOxFFSHCRa95FJl3FERhuK/QXL76n1jQcL5w6WVS4Cg2vxbqi14ycSRdurA vuHStX32o0VJENvHaUP6KgfjQvvztHmqJH+ICoW27NqBAcigJSE16jgatjDUHpBWKDHxkLIChuxo 6O9ZdfJgM9hR9dXWaiI4Bi0TA6RSPeF1bcdhAAZqJggZcgrsBNjkIB0mLWwIrITr0x+kSypeQGQU IoWQIFfsNEh39JdBjvQJIVKVgpXtsmXLnD0QSY/PA4mS9wxwVtGsYElszMKBCZH9WbkzyaEaZgLk +PW12TT1qPtM6vsHRIId5LzyzbFDLfLqaB8YQizekPSZpJmEUWNTzov3AcHxPCLFL1myxEn1TPxo DljwBJI9DitXX311rZ2pyZyAfZlF3WmnnVani2CMQcy88kzy7PGs8lwidSFVBdIoJL6vBVdN/dmw YYNT7bNgrZ7wm4UxWhCeecZO9ecYvHj2ec5DyzVxYSS2ZzHLtaIVor84HWGbRwrFlIDaFJNDdXNI nYBpop2yiksUN5tt3eXvcY4EHMLfIqG1KAkC0I+kBn1H4vP9Kk0zuUcXO3f4gBbFjYcWMoGMWKkx gFDdDBs27Ev94kEcNep/alwmAVaJQdUF1KpBeZfqP4ZYUWuENs4LCSNV1qcFhEp/QskTtREkyfcM ohkzZtR6WAZToOIMdkKtiiTLap+FASoYBm2oDQj3ciY71MCQIFIgEwsTJattJkucBKjTRuOaqe7N dR5yyCFOhYwjACSIlAERghm/RcrFXogUGg4u95vzCuw3701X/FOB/fHYKdZXQcHN1Qg6Jm6wpRNL IHlgKuDZ5pnieef+Q3zBcxg8b0j+oZIP6kCIg4ZUV71aSYAlzyyLy1CHFn7Hs3DkkUfuJYnVFX9U nSzmgoK49BHHmWB8cg21eX1zjYzJ0IUrTl1oXHie0WRUJ0lUxowdnulg7ATnZnGNWpQGyVWvMAEh o+pEGoa0USVzHjQ7qJdZbKOWRfpsbCe9uuJZ036ZyUn28ylj7XwRYEsVnW5I/1ucBPu1a2u/OnSc fe/VD+0Xb3+q6sQpNrVX4zsb1BUc1Dg8bKy4WHEySPi7JgJBTcJgZnXLwEVnHxTdZALAqF2bneGS Sy7ZK4M+x0CdyTmrkxGSJfYVJoaaWrCChciQ0oKq2Rjw+S2rUPqFXbO21S5xjxdeeKE7PM4sTF6B 3RKVDKtZjsv1oFpCIqQhZSI1B3URGaxIg4RlcC4mLyZN7CKoexi8qFmDslCoaYPJgUUEg58SUfwW QsSGyG8phNqSLUvB69e8O93eXrnezh42wC4dM6TRvUJru77PlEf09k/nSGvSr9HzlNYXU0wD2LpZ uDABQ4qorkPrYAZkg1qbZwE7IISA3YzFHw1NAN6/NTWeDb4LtcEztiCpmqpFcA5sdqGllKofFzU+ RIVEyLPL4gxJjUUYjQUf0ldNjT6zEAwWt5g8GA+MC+JwQ1tNY4d6nYFvAOcP6nfynIc2yJGxytjj FVsfpAe2zEMsLtGa0BjnHOeoo46q7y1ssv3R4fXXfM4WSa3FSRCwztPKYcmObLvpw1l2+Ssf2oOn HelyirZEg8ywYyC9IAFCiqzmunWrJObQemJMzqzaCHFgckc9ym944BnAtQ2qmq4L1QwPek3hAEwe V1xxxR5HndDfByTHZ5AYq06M/1wDx2S1zYodkkKlW5eG/QN1DR5sXC9qXaQ8yArpGFspEjBSIYsD BmegEr7qqquMLWi4d6MuQwUK0UPyrG6RAlGZMaFcdtllbnfqrrEFDSyQEFueAEvsBj2bD85dZJP0 XN5y9ORmzXdLOMYrS1bbzE3b5EWdaGfKhNBSjYUWCz9st0gw06ZNc0QIwbBw4flnIQNxHH300W4B iaqQ54bnLwh3gDyqE0ht1wQ5IBVhYw6tqcn+nBMzBQ4w1UuKMZ6C8YjUNHHiRDdWqWPINTDGAxKp a2wji1HGPSQFgaKSZLxzbM5BCARkHYwdzBGMHcYKi0X6iJaEfgS/RZ2KpIm6F/MDf2NuAFv6x9zD 2IEAGdecm+9YVFKD1LcDQyAsSDBGPkSI0Tul8rlTNdS+9eJ7dvdJqh/WBO7n+4OLQcbAZcWLFMJq DwJCP09DJRj6nkkaSYcVHrY4JvXaPEL3dW6IhAmiuoqUc0GutT3sOAkEDgSoDSFFVDHY2/gNVbXr W9ATouIYkD8DjnOg9mQlzGqb75FaGeyQ3DXXXPMlV/TgWrHvBRMXCwy88VhYIAmgZvrGN75Rq6cf 5wn1mt3fvWuK77coKP6Wj2fbHZ99bqOU0PouPZcDM5t3pfu1UYNcDsZr3/3MrnjtQyvUBHmBFo4t 0bhfEB7OUiz0WPzwfDEhc39xeEKNyXeMG8YRpgWeTZynGuLoxNjAHIFNsXoj5ACNTPVi1OzHc0d/ GI84l0CWLOB4diFotBXVQyj2hykEH3ircl3B9aCuhwR5ZnG4CcYO1w1mYIJEx/PMQgL8gnkC6RYS PO6445wDG1Iw6mUkQTyswZbz8D0hFRwHLJkv6hNusr9ra63fhwUJAj4hEzceebC7D3dPX2CXPv+2 c5Q5U9W7gxQ8zXWTID6kl5pa9YGIXYHAchpkhSoz1Husrn1moNTUGHRIcbWRYPXCuKim6uI+vq9+ MUhrK/DL4ITs6xqki80jtDGB4ghQ3Rmgpv6gTm7J9oUksN9LAnx83mIbJ3v1X0863EmCzd0SNIES QkR84vWySV7+yvvOLkldw3ZJzVuBhQkZMgn1bA7U6OBCyrSgsWjCyxonEdToBJUHzjP1wRACrMkm zzE4LudHeqrecAbDrBE0xhGOLAfSmBsIlq+tsYitbexA1jgK1dZYYNYmIYMlIRhBUP6BXENj/HaT 7OPkte2sWO9Ib2FDggCZnhhvN0vV1EEG1ts/neuI8Gdbx9pl44crfCI8s+ljd8PLC4kJN3DUeXX1 7KzLw4MaEUcS35oXAQrmXq+itjPWbrJjB/exW7UgG9e1Mr6rJRoB9FdOHiN1aLz9VlXtf/z6R7Zi Z47ddPTBlq7MS+HYUKlDikhkOJJAoKgGG7ORvci35kXgTcXI3j1jgXVJS7Y/H3+opcaHFY3UG4yw 632KAL3msIOkcspwaqgb3p1m87Zsl7p0vBxmutb7Apv6B4Qk4HRCyiNUhqhfvIqiqVFvuuNvKyiU p/Ii+5MWYdly+b5CavofHzzacOBq6cbK+zvjR6iSfZrd8skcVWEpt91KQB+uDa3IySefbG+99ZaL hcOWhnret8hEAOcwamj+6bN5tkY+HN+aKO1EVSL5yLyiyl6HHQnSKXIxXjhykPIytneD/UkVaFyg HKNMAF/T5z3CIKg+uOmod7AL+hb5CBDo++Dcxfb8ouU2ILO93XrcFLtAiazDLQnwKYP62ID2bZ0q qm0zq0Prc5dZDGIDDrKy1Oe3ft/wQuAteUXjGPbvhcukqUu2P550qF0yaojL/xzpLSxJMAAV9dNd Jxxqh3TvYrdPm2u/ePNjpata69zTzx8+qMVjpiL95vv+VyIwZ/N2e1jkxwDfJlvHhbK1/UjZYCb1 aH77X13vCcWoffMINDUCO1Qv845pynEqu/h6BcIfrzAdNCMnDezd1KdutuOHNQmCAqvdH08ebVP7 dLV/zF1i98/5wqZt2GqvLV9nF40aHFU3o9nuuj+RQ2Btdp49vmCpPbFgmS1Q+MEkeSP/RYuu4/r3 Cvtq2Pu6hRQyXZutXJVpqc3uOOMfrehCIFE5QD9at9ll8rrj1CPtjMF9mzVJRHOgGfYkGIAwsVtn G9ahvZ0qJ4U7tTJ54vOlyuS/0Y7s08POHdHfTtPNIdTCN4/A/hAgye8TIr+Xl62VFLhNhJdsfzh+ qp0zrL/UjPtPWr6/47f096uzcuyyl993atyvKLCfHL3N7UXa0hj48zcOAqg7/3zCVHewsV0qk4ZH W4sYEgR4bshJA3rrZnS0D0WA90tH/S+psN5evd6psy4YOdgFEuNJ55tHoDoC87eqAoLsy2/IvrFk Z5ZsG4nKVnSQI4rhUi/GtnDe2sa6Y6zeGSuvr1hnMzZttSc0Rk6THRHNSde08C3R1FjX74/TuAhE K/kFKEUUCQad7qaBTJaZI1SKacbGrfaA8o4y4D9Veqm/zphvJw/sY2dJdz1EBU99a90I5JWU2lur 1tuTX6xQxpWttj4nz7ore8fvDp+oyiX9rI/yf0bboqlPRrr94/Sjba5snfeqQstrGhuzpe59RAuA 4/r3tCsPGeM8TH1r3Qjkamy8rFAgwoGO13NxyejK4r2trUUkCQY3qYvshadqhUvoxFyFUTwim+HL y9fYAtUofEC2wwkKbL5gxCDVLexuqVoZ42LuW/QjUFpeoTR8WfbUohX2igb42tw8yy8us5GdlTVk 0hj3zPRQjto4Be5HY+O6kPhOlPPCwT27yLN6p92gmMc3VeKmk0o/YTP0rfUhUKFwhnKF1CzS2HhS 2oFXl6+1dVoU7lRYUEZSvCfBSH4k2qu46VGyDU6SF+mvVeftBbm6P60JEOnwbVWooII9BXxxLYcY 0xPijCwcvkUHAgzuwrJywxb2plSdr2gh9IUm/sIy5XBV3Omp0gygChwjNTq2MUJwWktjbBymhPRP nnO8rdyVYywQuu9DCixTirFoXRy0lnte03USz4cT2GPzl0lDsMOKlHoP9f8kZUK6SGFnOIO11hbR kmD1m8aEN0hB9j+RC++3xw2zmRu3yR6y1N5dvdH+88Vy++f8pdZJThBH9ukmB5u+dlC3TsrAkeAm ytY0MUbDw14k0qv0gsyx10V8rGoXyObHfYzR4CbG9FzZ+k4d1NfQGGAna82tnchwvJ73fTWSA9yl 3L14ZLNo7KSaianKB9rS5Zta831rrGsvFwnO3bTD5kgtjiPYmcpzii18iGr/RXrGlwPFKKpIMACD iRByO7pfDzuiT3fbpvyC74kI0X/Pkl3oRb1S0b5dcoKrYXi49uG1R3qq+100BIAe6IMRbr8vkQST o0marBXzRHYfKZ3Zh9pQeybFxliK1N2jJekd26+nC5sZ3ilTtr7oVHc21b3JKipx4SIrJVGD3fiu nexokeHU3l2d12zHKlJsqvP74zYMAcZGtirFIOVnarGTVEMas9g2MXbx6MF28qDeexb/fuFfiXdU kmDoo4TI3zU1xRV6ZNsu/fcH6zbZq3KPn71pu02XY82bcpzAgWJwZjs34A+V+ggPVFRJ5DPNEDH6 B6ZhA7Shv0LKg/TY1iie75P1m51H8AytZBn07XRP2sqOcWjv7nasbL7HD+glm18HHyTTUMD1OyqB 33DUJGdGmKlxsTIr1+ZMm2fXvj9d0nSK3XniYXZeCxe9PoDLi4qfovovlhYkR/MVxLcmK88+3bDZ 1bncqQXibSr2fILGQvWGBWBsC+a+DWfwo54Eq4OPKuDsIf3dhvqHwY5XKRLiag161Gq40VfIgDy0 U3tnRxqvbaRiZLopYWx7lf9pLwkSNZFvjYMAdiikkF0axDuVoWKZwhfmyNFp7pYdUuFsd4O7vWx5 qOlYnIySg8vBktwn9+ws9Xe7xumEP4ql6Zk+Z2h/t+E5OENJKZhgKerLvUneh0qZ8k5kF8EBjcWj b02DwBolQbhn5kLlU97h5qyduQWWJgmdogPd5Ozlnf/qj3urI8FQiJDwjpH6jI2GpxQhF2zz5WG6 WSm0Plq7UU42y624qNTapzMJd9Ik3MGGKvyir1zRefhwtsDmwqt3uNn3Q8jCA5UmpJetbaM8N5fu yraFcmTBYL9U5YtonSR5dJYn4ygtPvorT+ZBUs3h6UjMknfcqP9Ar+8vqEyBOYGNtlM17OLb1G5X xe7+Z0mN3eWVysJxEOpT3b8MjQtIMVMxmdEWilJfTPe3P1oPFnydtVCnkEBNbavqWz6sFGbMXaTO 6ymHFhaGlPia2L3Sx8G3+iHQqkmwOlS9VK6J7WythGl40y3escuoK7dke5ZLs7UpL98el4PNDtVz M6ns0jToB0oaGaBCqwM18Cm42l3pqkhszAOZriTClL/hoW0tkzeq5UCVidrGDe6CYlslW9NyNtnx lgvb9dpUQtuSJeGR4qu7VrJjpLLG/kTwOs4twzphuPdSd/2GdePvnSkNyL4a95xFDfGIj2qStuJS i9d9JWZxSs+uLt9kS5aianxEGn5EnLqQ6HJZEDI2CotdmjsyGc2XBuQ3R0x0SUFqajiy3K7E7n3a pruQH+y0vh0YAp4E94EfEggbwfc0BjqOGEu1MaGvVzjGRqkjKHDK4H9FqtRCSY8qwW7pcrIhFq1b 1eQOMaKuQKXXTpW4UxWmweSOEw6rPl7x0kpSqqtwbXiYgUFBaanll5RZvhYB/J2vv3M06e1U9XMW CRuFy6bcQtvIe22bhJHpO5NE0FmLBmLYIDfiN7sLJyRqiA/pmkWIb5GHwImyQ1H+bKlU2atZ4PAM aCys0vvNegZKy8trvajpG7ZI7bpVi8U4Z25wzmkaG8kaDyweGTNJYe7dy9go0JjI01jIoxC2nnEW wDU15o7vvfKBm0cYH6YFomk+yNRYaKff5Gks1dbQOF3aSoPam2pUhO+M21RXfADHhagIq2ALGrYQ 1Kjrc/L3vEIC1KXbLhvJDr0ulhS5XR6qpVJlWPlua5Mmu+IeNREqowSnVsXu1c7ZHBM1CcQ59RGD PxFylLcef+Pqz2cJMbFyXY91iW2pKBcn4kXSDELg2BdnHr5jAmKQ0njFsYRIOYzs2OOK9XeJ9sHg XqT3xbqmolL9zWfauEZW+c5mp1Ur6sxdUo/t0mf8zeeFSMb6van/7bQ6ZYWKi/2Erp2tw4AkF6vZ Q/FpvVQGiwLJkF00VKU+gMcpqn4KcY2X4wVb0HiemPCRfCDI2hqq1F++9YkZz5CekwyV6snUeGBx OLJze/vNYRNshLx9ayMUxhfPM6TJc5/gxofGi17RLtSmSaB/O7Q4c+NBB2A84GHJK5XcWbjiGFdT 26AxTkxqtp59tB0sAFHx79A436Zx/+up410YVk2NczGX4MGMKYZxwGKQMdFD2+B9YBVVD02YXIwn wQO8ESQpxquULbQhHTEYcPSADLdrkOCZyns+D+xiWfLw2igCXSgbJIOoUH+bXuWZI2aTDUYDu41W xSlV5MfEwJao8zLg4wMS1KBPEFG2qfKPRNLke0gPqQ2yY6Io098EytLgRQqzMklBdBBfgYu/K7VS /caRGvvSFw3aGEfcqHcr7Z8dNVFh+8Hug82HwdxRExgEiKdh8N6rbA7wIYvQn0NCdSn5dKxSdt19 8hG2tWp8sMBiLGwWKfK6r7rBaF+ue2+Gleo5RvJiPCbFa3GokIDOcmS78chJspXVXBJrlrQ3lAni vPEaP5ULxHJHhPT9NyruXVsQOTbsb734rpXLnm169tFyOI/lKhNIkY7DsrOmtAxoPqhWwmKWMdNa zCTh+hh7EmyiO8PqMzUj3qn6qjdWmrlSeeSKbLALQFLYzVAtok7hswKRT6FIib8LUEFCVFI/EjrA BpE5Sa2K3Aq0r6s0zipW/7HC3Sp1FFJkT60ycdjZrf+YHJgkaOyXEhev2KIkt4pO0ecpmkSIuQvI lknFXYu+Z1XMRMMqFscJ91r1Wbirq5roNvvDNgIC1bUrwVjAXsbz3H8flT2QEAl9wqHEaS0YG9py NaYCqa62LqLBWCFJFS1HfGwb51npkirs1siokghr++1Q2ebuOukwNw4D4iMTVZrGB2OjV0btan1M HphZfAsPBDwJtsB9QE2JCpTNRFD7a4RrFIvgUNugwmErFfmx+lVmMLfaZBXLZ0680/E/WLPBbvl4 jo2T6vYaVUqA5JhQGOiBBytqGVahSJCoVxPiULmyxfksIfu7Kf77JkMAUmFDRbi/doRqQJLoAm0G UhxjJHjl+WYBWFsjzOZ+1cirXDgybBgbJFgQCfJbqUNra721uL38oBH7657/PgIQ8CQYATeJNGDJ MXFS9aizdQzBysGlnUTKCjUgwbhvHoFoRADiQgvREE0Eanqvqo/Gp6J+1+RJsH54RczeJJTGJoEt kFVyQyaJiLlY31GPgEfAI9BABDwJNhA4/zOPgEfAI+ARiHwEPAlG/j30V+AR8Ah4BDwCDUTAk2AD gfM/8wh4BDwCHoHIR8CTYOTfQ38FHgGPgEfAI9BABDwJNhA4/zOPgEfAI+ARiHwEPAlG/j30V+AR 8Ah4BDwCDUTAk2ADgfM/8wh4BDwCHoHIR8CTYOTfQ38FHgGPgEfAI9BABDwJNhA4/zOPgEfAI+AR iHwEPAlG/j2s8QpImUYjT6lLCuybR8Aj4BHwCHwJAU+CUfJQkBGfahSxyjNKozwMBFhUXmZrsnId EZIomITZFOasTBTsm0fAI+ARaN0IeBKMkvv/wdpN9u8Fy1VNosIR3RYV8C1R3tAFqlP4i7c/FTnG qGJ1iQ1WCZgbjzo4Sq7aX4ZHwCPgETgwBDwJHhh+YfNrKtF/un6TrVGVbQrxQoSURaLy9aJtu5wU SHHc88cM8cm0w+au+Y54BDwCLY2AJ8GWvgONdP4pKpc0XrUD1+zMcdW1qYdGFQlUotQSLJZatFf7 dnbRqMGNdEZ/GI+AR8AjEPkIeBKM/HvorgDio0joe6s3usrzFM8Nbao1ap1Tk+3wXt2j5Ir9ZXgE PAIegQNHwJPggWMYNkc4YUAv+4/sgnO3bHdFeING1fkMVeo+vHd3S0+MD5v++o54BDwCHoGWRsCT YEvfgUY8/8hOmTYgM8PmbN4mXaiUoVXSYJnEwHaSAk8f3LcRz+YP5RHwCHgEIh8BT4KRfw/3XAHO MEf17W4frdtoOwuLLU4kiF2Q1jM9zSb16BxFV+svxSPgEfAIHDgCngQPHMOwOsKJA3vZA3MW2ebc AotLiJFD6G5rm5RgqEoTY33QfFjdLN8Zj4BHoMUR8CTY4regcTvQv12GDe3Y3uZv3WEVUomWKW4w LT7eTh/Sr3FP5I/mEfAIeASiAAFPglFwE6tfwskDe9uHazba5vwC5yU6qEMlMfrmEfAIeAQ8Ansj 4EkwCp+IEwf0tjumzbP12bmWmZJsZw/t7wLnffMIeAQ8Ah4BT4JR/wx0TEmycQqcn7tlh6UoUP64 fj2j/pr9BXoEPAIegYYg4CXBhqDWDL/BnldcVq5ML2wVVqqUZ+XaSvW+TM4uJfo8p6TEsuQFWqD9 aOxbou8Jky/VPimyBSYocfabK9fbx+s2K2TCLFWkuHt3G4uXZNg2Kd7aJSS4/eJi27hUa1Sf4JUE 2zjSkHg7qEjRDJftT+ER8Ah4BJoVAU+CzQr33icjfCGvpNRtuSK0AlWBgNi25BXahtx828SWV2Ab te0sKrKcohLLLi62XXotV1YYaxNjMSKroHIE9j/SpNEgruKyMtteUGS/fOcz5yRD6CCOMuzhnGZE lGJWR45pqiyRIS/SdomJ1l6vHaVG7Z6eoi3VuqVp0/tOyclKwRZraQnxezbvcdqCD5A/tUfAI3DA CHgSPGAI63aAchHO9sIixe8VWZZIbJtKHS3bmW0rdmnT6zK9rpENr6K41Ewp0JIlnaUmxDl1Zqre J0kig5h6iJSQ7pIkpUFGGSKv5Kp6gUhvCfockuN1yY4s69e+rcXokwqRH30oEDHSyiRV5upcOSLg gtJSJ0EieZZUlFuWqk1sVhWKaRu2WL6+yxfhlougaR10/v465gBtgxSYPzCznfVqm+rKM2UmJ1qH 5CTXL988Ah4Bj0AkIOBJsInuUq7IZYskOEoabcrLt4UqaTRP28JtO22pyMlENHEijA4Qh2x4BLOP 7NTBSWIdU5OsqzK8dNLWWcRHzk/SnqWzSX2ZJnKsS4O8UH/WpaFmpc9IokickPXW/CL1v8DVJtym 64DEc9RvAvE/E0G+vGyN5eo7Max1aJduw+WBOrpLBxvTuYMj307qexf1vWtaSl264PfxCHgEPALN jkDdZshm71ZknnC1iteyLd2ZZbM2bbPPFatHvF5+jgLXRWx92qZZD0lNY0UUEEOfjHRJUWnWO4Mt XWrHxiWLuhIgaGMjRJJjs4za8Yco1+fk2brsPFuTk+sK9m5UYD5kySs1Df+aPUfSbKwNECmO6pxp E+SkA8H3FVH2a9fW2vr8pZH5gPteewSiEAFPggdwU0vliPK5pLvFquE3f+t2m7lpu83YuNVyRBDt 2qU5VeFJA/po4k/X+wwVtM2w/iIBCC9SW7pUncNEbmyhDQlx5a4cp+Jdqm2V1LurhcPnm3fYc1+s cLlMR3TtZBO6d7LxXTu6uEVynWJz9M0j4BHwCLQUAp4E64k8xWlnb97uKjVgM/tw7WZbLOJD8hkh Ce8UBaqP0uuwDu0d8WE/w64X7a2tVLVjRW5sQUNiXCFiXCz1L2rg+cLs+SWr7JHPPrcMLQam9Oxs U3p3s4Mgx26dpf5NinaY/PV5BDwCYYZA9M/OjQQ4DizvqlbfZ+u3OPJbsGmrcnMm2JF9uts5Rx9s wyXVDJGkN0Tk5x1DKkHvKVUv2xHCiLYqS4QoqRmHHSpdvL92k726aKVlSh18SI+uLsH3oSJFMA28 XBvp9vnDeAQ8Ah6BGhHwJLifB4MitW+uXGfvrtlgn4oAaUf17WHXH3OIq+Q+UjYvbHu+7R8B7IFs J0laxrb4BdKh1Mkfrdtkrwvjlxctt15aRBzRp5sw7mmnDOrjHGt88wh4BDwCTYWAJ8EakM0qKrbn l662N1ass08UZL5aNq4R3TradYdPsEN6dpW01845efjWcASwLR7co4vbzh0+QBLiLqlMd9kr8jj9 98IV9vSiVfbo50ucFEkdxIO04PDNI+AR8Ag0NgKeBEMQxfX/P18st2ekopspdSdB7KcO6ms3HDXJ TcI4c1SGovvWmAgQ/hEQ4qmS/n4waZQWIGvt8fnL7IO1G+0pOdYco9RvF40arP18TcTGxN4fyyPQ 2hHwJKgngJi4JxYssyc12c6V00uFStFeOnqIXTBykJP6iHfzrXkQICaSbUrPLnax7sEHazbZ32Yt sL/OmG+vLV9rx/bvaZeOGWKTJUH65hHwCHgEDhSBVk2C5fL0fFKS3z0zF9g8JZsms8olowdrkh3q QgC8g8uBPl4N/z0Zb4JQDAoFk/+U+/TAnC/sDdkPzxjcz3508Chvj204xP6XHgGPgBBotSQ4W96J t34y1zm9FCpd2EWS+r47YYST/EhT5lv4IIDj0bfGDTPqJL4km+GfPptnf505395Zvd6+N2GkJMbB Sh3Xah/l8LlRvicegQhEoNXNHOTtZAL9++wvlKC6wDm6/OrQ8XaYXPMjJZ6vVPk8CwoKrEx5QIlb pMVKckpWguukpJpj7SrIFZqba/w2Rsm12S8lpXEz1DT1809g/bfHDbfj+vdyUuFDcxfZz9761BHj NYceZBNlL/Q226a+C/74HoHoQqBVkSBpzK57f4a9JM/PHsrVecsxk519iaTPkdReeOEF+/73v+9I rI2qRkCEvB8/frxdccUVNmHChL0uB/K7//777fnnn7dNmzZZguIbhw8fbt/61rfs2GOPdaQYKY0i GWTguemog+3MIX3t9x/Plq1wjS1QqMXVh46zi0cNccnGffMIeAQ8AnVBoFWQIMmhn1m8UgQ43Vbs yLbjVXn9t0dOdFlKqioP1QWrsNln27ZtjvRuuukmR2jlSt+2efNmR3KXXnqpPfTQQ3bwwQe7/iL5 3XHHHfbf//7Xvva1r9mIESOcRAiR/uxnP7Pf//73duqpp4bNtdW1I1TMmNqrmz1x1nH2t5kL7bbP 5toVr31k8zbtsF8ddpArA+WbR8Aj4BHYHwJRT4JFsvfdOf1zu/6DmcpsFmNXTR1vP508xlVuiNSG arNv37523nnnOTVo0P7v//7PkeB9991ngwcPtvbt21tWVpY999xzdv3119vpp5++Z9+TTz7ZfvSj H9lLL70UkSQYXAjhFb+cOs4l6v6t7vFfZ3zuylP98fgpLjepbx4Bj4BHYF8IRDUJEuf3x0/n2g0f zrK+cq64XtIfsWbR0gJ7YHA9bdu2tR/84Af2y1/+0tauXetIEMLctWuXsyGyP+pTWnp6un3ve9+z 9evXRwUcZJchQflv3pthTynInhqJtx0/1SZ293GFUXGD/UV4BJoIgaglQYrBIv398ZM5NlxSwi1H T7bTlHkkmlp1EuTaJk6caMWqPr9x40YbM2aMQYxHHnmk/eY3v7H58+fb1KlTrU8fVbbo18/ZDqvb DyMZn0Gq2nHH8YdaexX4vV8S4eUvvW93nXyYc37yzSPgEfAI1IRAVJJgmYq83v7pPEeA45Tp5dZj D7FjlXGkNTRID89P1KA0PEZvvPFG+9Of/mRvv/22Pfnkk9axY0fnGHPBBRfY0UcfHVGOMfu7h13T kuU0M8nFeN6p+3+l7IQPnnGMEpzvXfppf8fx33sEPAKtA4GoJMHH5i+xW+Q1OEQB73ecMNUO711Z xaA1NJxkcIYJDZXo3r273Xbbbc4hZubMmfbxxx/bG2+8YZdffrn9+c9/jmibYE33NFPevuR5LVII yd1Sh1/z3jT7+ylHWscItgO3hmfXX6NHoCUQiDoSpCLBNe9OtxRJAtgAWxMB8gAtX77c2f66dKlM K0ZIxFtvveWkPuyARx11lNtwisGR5tFHH406EuS6kQR/fshYW5eTb88uXK66jhlOQkwMcSRqiQHn z+kR8AiEFwJRRYIkwL5OjhHb8ovspqMn2XnDB4YX2o3YG2L74mvIbPPPf/7TkPyw+9G2b9/uYgr7 9+/v7IFBgxBHjhxpc+bMacRehdeheskZ6rdHTLC12bnOQ/iwXl1dRYrAOSi8eut74xHwCLQEAlFF gv9euMw+liR4+pB+9v2JI1sCz2Y5JwSIanPVqlUuThAP0B07dtgrr7ziJDtsgF27VjqDDBgwwE48 8UT76U9/ar/+9a8d8SEpfvTRR/bqq6+62MFobmO7dFQQ/Xj7zsvv2+8/mq3E3F1Vwd4nRI/me+6v zSNQHwSihgS35heq2sBC66gJ7lfKHBLNuSTjlCdz+vTpduaZZ7o4QUgQOyCNEImvfOUre+IHCar/ 7W9/a9dee6396le/Mn4bZJmBHKOdBMHkTC2KXllGaaal9oqyy1yk6hSxkZgloT4j2+/rEfAI1AmB qCHBl5ausXXZeaoCMcTGdY3uAqykOnv44YctPz9/z03GCxSPz8mTJ3/pxvP5PffcY59++qmzEUKC SIiHHHKIpaam1ulBieSd4iU5oxl4d80Gu2/WF3bW0P7WVkH2vnkEPAIegaggwTJJQo8vWGqJcTEu wXK0N7LF4NRSn9a5c2c744wz6vOTqNp3gkJlUIW+rGTbMzdus6P79Yiq6/MX4xHwCDQMgaggwUXb d9myndmq/J5pgzq0bRgS/ldRj8DxKsj79qr19qqq1h/ep5vFRVDi8Ki/Of4CPQIthEBUkOCn67dY seLjDpX3X7x3gW+hRyn8T0vmGMplfbR2k3tePAmG/z3zPfQINDUCUUGCSIJUihihhMne4aGpH5nI PT4lmNIUVrIiK8fySsp88eTIvZW+5x6BRkMgKkhwU16Blcvtn6KrvnkEakMgQVqCTsoaszEv37YV FFoXHyrhHxaPQKtHICpIMF/VIoh9S00In8shfVl2drar5BAJwdk5OTkufCLSqs3XZwTv1s7JkgTb 6L/C0rL6/NTv6xHwCEQpAuHDGgcAcJKLfTMrKi0/gKM07k8pUXT++efbu+++64rebt261VVuCNf2 85//3AYOHOgK7UZrayMWLJUn8W79R9iEbx4Bj4BHICpIsENyosWIBbcXFoXNHYX4qORARpcZM2bY 3/72N/vHP/7RZP1bt26dpaWlOcmzIS0vL88KCwsb8tNafwMGLAZYAJDlplu3bi6lW0u1cpHfzqpn pIOSbPvmEfAIeASiggQHtm/nVvbLdmY522A4OMdQxYHcnhDLwQcf7LambFdeeaWddtppdskllzTo NKhCQ6vUN+gg1X708ssvu9JNK1ascN8gaf74xz+28ePHt4iKeEt+ge1SftmuqSnWLtkHyzfGPfbH 8AhEOgJRQYKTenRy7u6ESlS0IAlSzZ3CtZAJUhmN90iEq1evtrFjx7rPIEakQ5JbDxkyxIqKiqxn z557VX74/PPP3ed8P3To0D3P2ZYtW2z27NnuGKhXx40bZwsWLHDHJx8oGWAootuhQ4cvPZslJSUu 3RqSGSRNf2qTzJDg6ANt8ODBtnPnTneumpJ21zYI6BMp3E4++WR3LWStueaaa+z55593EnJzt9kK ki+SdHqYYgRxkvHNI+AR8AhEBQmO797Juqal2KyNW40coj1awEt0w4YN9rvf/c6WLFniCAjyg3Qg mw8++MCuvvpqmzVrlkt1RqWHRx55xBEWRPbUU0/Z3XffbRdddJFLa/b73//eFi1a5GyJnTp1clXh R40a5VSLt9xyizsHjfOQD3TatGm2Zs0al1QbqQvSrE6COL48+OCDrp4gREo/Jk2a5PoVJNsOhgN9 IAk3hM5xEhMT7cMPP7SVK1daQUGBPfPMM7WOnClTpjjipl1xxRV79oP0Tj/9dHv66afddbVEe3Pl esvVPTlpQG9L8DbBlrgF/pwegbBDICpIkNgvSuT8Zfp8e1K1434yeUyzA33XXXc578oXXnjBMjIy nNovkKQgxKDI7WeffWYvvvii3XzzzU5ie/PNN+2///3vHlUkZAg5UgOQhi3xjjvucAQGKVEpgoK4 qBYpgwSZffvb33bHOfXUU2tVh0KQSI8PPPCAqzYPQVNZAjL+xS9+4c4VeLHee++9VqaCtM8++6yR bg2ipd9cHxIh/a2tQagBCYbuA3k+9NBDdtZZZ9VLmmysG7kxN9/eW7tRIRLJdkTvbi2ijm2sa/HH 8Qh4BBoPgaggQeD46oiB9tDcxfbI50vsgpGDnGTYnA2S+OUvf2mZmZnutFRtf++99/Z0ISAYJDxI EgKkHXfccc5eiLqQhkqT3KBIg1SHQPp755133HcQHwmyqQYPOR1//PEuCTaNKhL7cmzp0aOHI2Yk MZxo6A+lmAgtqd64lssuu8ydg8Z7yB1pErXtSy+9VC9oIeBbb73Vdu3a5SRPyLS5299nL7KlO7Lt l1PHWQcRoW8eAY+ARwAEmn82aiLch3Vsb2eoZM7fZy+0u2bMVxXxpnVEqX4ZqPhCHUtqs3lBbNVb 6O8gM8gG+yLvidsjfIE2aNAgu+2221zNQFSiSJPf/e53nc0NMsMDs7aG/REVJ5Icdj36Rw3CXr16 fekn1a8lsAMiQWJPhNBqa9gAQytZsD/nJWYSYq/JVtlEj8Sew87dvN2eUIL1DimJbrEUH+vDI5oa c398j0CkIBA1JAjgP1C5nNeUHPmBOYtUMaCLnTKob7PdB5xGXnvtNTv88MOdDY1wiEC6C+0EJYzY b+7cuc4xBUcVHF2Cun7Y6ZDarrrqKvczyO3jjz9275EKIT8kThqqRVSjkCCtuLi41uvFZokt7/XX X7dhw4Y5qZE4xqAOYegPx4wZ46RPJE1I+LHHHjNCKCBr+oOqtLYWSvLLly+3O++806lfIe+WcIbZ VlBkN6qY7rIdu+y24w+1ge19gvVmGxT+RB6BCEAgqkhwSId2dvXU8fbdV963a96dbt3S02x8147N chu+//3v23XXXWdnn322c2bZvHmzk+hogXTH+6lTpzrbHk4jkB32P8grkAb5/Pbbb7dzzz3XSWyo LUePHm2HHnqoI5///Oc/zraGTQ+14imnnOLOcdRRR7lwBAiTIrrV7XJ4gUJq2P84J/GE9IPj0iA5 7HY0VLkcA6kOlSjerfSDc3bp0sXZKOvS8ASlv9Q/xG7J7zt27OgkSYixqVtpRbndMW2ePbtwmZ0k m/GlqjXpk2Y3Ner++B6ByEIgqkgQ6C8aNcgWK6H2Hz+ebde+N93uO+WIZvEWhXSY9PGihLyQDPGy pCHxBSrEdu3auerv7E8IwYQJEwwpLZCg+vfv79SfeJSiwsQGd8QRR7jj9O7d2/0WooNYsQdOnDjR fUd8IESHvS89Pf1LTyHEDEkjOULOFNq94IIL9jipEGcY/A7b4/XXX7/HFglx/eEPf6jRfrivx/3C Cy+0E044wTnvQIC0tm3bNno8Ym19eHjuErvzs3k2XInVbzzyYOuovKG+eQQ8Ah6BUASijgSJ//q5 nB9WZ+faU/OX2tXKJnPz0ZObhQhHjhxpbNUbHpMnnnjino9xSIFoUGeinkQKxBkmaH369LGLL774 S8fB5odUyFa9IdkhPe6rYf/75je/WeMuhDaENkIt6AOq3RtuuMGRJu/r0wiJaKn2+IJl0gZMsyQt SG485hAb3615NAItdb3+vB4Bj0DDEIg6EgSGjkqJ9Xs5xmQpRdY/ZR8sLquwm46eJHtQRsNQauRf IRX98Y9/dDY+VJyoH4NA+kY+VYMPh2MOlehxaEGKRDKsLwk2+OQH+MO/z/7Crn5nmpVUlNltx061 Uwf1OcAj+p97BDwC0YpAVJIgN2tgZobdedLh9vM3P7En5y2xvNISu/moyTa6y5czqTT3zSXwHdUp alBUjfzdEk4j+7ruc845xznQYCckoB+HnnBvFMq9S7Gi138w02WEueP4w+xiqcdjY5Rd3TePgEfA I1ADAlFLglzrUDnK3HXSYdY2McEeV/zgxpwC+83hB9nZQ/u36MMA4dWmOm3RjoWcHNtldRVpuPSt pn6skfr7po9m2T9lB+ykGNE/HHuInTdsgCfAcL5pvm8egTBAIKpJEHz7ZKTbn0+Yal00Md4zc6F9 +6X3bcHWnXbFpFHWLql+Nq4wuF++C9UQIFfsO6s32G/em2HT12+2id07S/V9sB3Vt4erLOKbR8Aj 4BHYFwJRT4JcPKmyfq+JcXTnjnbDhzPsBqnLZm7aZr8+dLwcJjr52nIROka2Kwbw/jlfKAzic8sp LrGvjx1q1xw2wfq2+7J3bIReou+2R8Aj0MQItAoSBMNE2YguHTPYRnRub797f4a9pWTK0zZssW+P G27fOWi49WpbWfXBt/BHIL+k1El/N38yxyVN76l7d40WNN85aKRsgT4bTPjfQd9Dj0D4INBqSDCA fIIkv3+dfZw9rDyj9ynF2i2fzLYXlq6yqzWJHtu3p3VKbfog7vC5/ZHVk8LSMluimpF3Tptv/1IA fFpCvJ03fKD9bMoYGyMp3zePgEfAI1BfBFodCQIQk+cPZRM8cWBv+7Myiry4dLVd9OzbdmSf7va9 iSOUcq2bdWvmBNz1vXGtaf8CyG9Hlj2uuM+H5i220vIKmyTbH/fwnKEDlM2mNaHhr9Uj4BFoTARa JQkGAA5SGMU9CqM4W4m3mVw/WrfZvvLUG3ZMv5522bhhNrlnV+ud4dWkjfnA1edYOcWlIr9d9h+V xyIfbKmSjxPi8tVhA+2SMUMsU4kQfPMIeAQ8AgeCQKsmwQC4Y/v3MrY3Vq6zxyRtvLd6o3316ddt iiTD86Vum9Krq1JvtbfkFigBdCA3N1J/uzor1z7fukMS+hr7t9SeZSI/vD7P0mLla6MGW2evso7U W+v77REIOwQ8CYbckuNFhGyviwyfW7zKPl63ya54/SPnXUqNwuP797QhHduFTeaZsHuaDqBDOwuL bbGkvpkbttpTi1baRyqA20G5PlFRHzegl31Vi5EunvwOAGH/U4+AR6AmBDwJ1oDKCSJCtnlbtosQ 10syXG8PyhX/TtkPp/buakdJXTqpW2eXmHmAL83T4JGVXVRiC7btsPmK2/xg7SZ7ffla21lQaCNV +eP7svcdrVg/7LYpXgJvMMb+hx4Bj8C+EfAkuA98xnTpaGzfVvzZGyLD9yWdfLZ+i92owGxVsLXD e3e3w/t0s1GdOxhlnNiS4mL9M7cPBNbn5Nmi7VlO6psmLAl12LQz27pmtrXDJPUd1rubbLI9bKxw 980j4BHwCDQ1Ap4E64BweyXkpiI5G1LLnM3bFGO4VY40G+1GVSpQYT9HlqM7ZzpCHCb74Uhtfdv5 Aq5Ie4tU2mrh9p22cOsuZevZYXMkYW/flWOZCmo/XMR3yMGjXdIC7H4ZSnHnm0fAI+ARaC4EPAnW E+lRjugyVbdwsAixUpU3Z/N2ZaDZav9dvNL+OXO+dVS1ihFSlfaXqrS/JvqBme1ssDxRB0tSJDwj mttKkdsySXbLFM+3Qu9XaVuiv6nxaAp1GCTvzhNk4yNec6QWDCweOvk6f9H8SPhr8wiENQKeBBt4 e8hLGahLL5TTzKqsHMOrcemObJu+cYtNUyaT91dtMCsrtXZt0623spr0ykjVa7r1ETHyd2/lNa38 PPLCMLKKim1tdp6tk3pzbU6urcnSq/5eo/eoPHlvxcWS9to6Ce+84QOEVweX0qy/PvN5Wxv44Pmf eQQ8Ao2KgCfBRoATQhwg6Y+NGMMLiwbautx825JXIHLMk7S43eZJYvx43RZ7OWe5qW6Sq3LeQWpW NuLduqenWjdtXVKTtKVYZ3mkkr2mq7aMFkj0XaKA9K35hdoKbIucVbblF7n3m3RNG3Rt2/TZTuXu 3CGvzh2q21igvy0u3kZ0ybSpCim5/KCONqxje+ualuwKGpPazDePgEfAIxBuCHgSbII7AmmxjZRK lJZfWmo7CoqNhM+bRSQrpB5cvitb6kK96v1nymFaoX3iZA9LjY+zNFVD5zVFqtM0vabyt96nJ8a7 slBteU1IdK/sm6x9qJkX1ybGEuWYQwaVJOVKJY/mbp0/T8dWsQUrV7xdYVm5+4ysK3nKwZmjAr8k n86R7S636u9cBannl5RZgX5H3/OkxizQ37wv0L5Wsds6S3ol2QDB6wPat9P7tta7XZoKGic7Yofk ffMIeAQ8AuGOgCfBZrhDjsQy4vfKPkMSaEgHIoKkNucV2lqpU52klZevV225BSLLHH1XAIOZxYro YirJLV7eqfF6jdNrrFivjTZqxyKV8l8cpKjvduu/Yn4r5uN9mQiMRgkigtDJwgIhuk3vK7TpH0sT iXVX6jgk1DF67arX7qmpe1S6GUkJzr4ZbPTHN4+AR8AjEGkIeBJsoTuGZMe2p3WpfFei6uhFktZQ R1IpvVjvi/QKaWZLQsuWLS5LUlu27G285kqSQ2KD3MpEbEWS2nbrda3scrPlsNNRUtnknl0cacZK UkyOl6So81B5HcmyXSJSa4Kz0eGZ2Q5JU38T6sE+SJaVUqXea/NV2lvogfGn9Qh4BJoEAU+CTQJr ww8K2bDtr5U70kNy223l6DrV+BcJj/bGirX249c/tkMVy3jniYc6UoP8gkKzqEwhRaRIiM0XoN0f 4v57j4BHIBoR8CQYoXcV4pJcJiar+QKQ7FCRQn6EIHiSi9Ab7bvtEfAINCkCngSbFN6WOzj2PhqS IapVn8mm5e6FP7NHwCMQvgh4Egzfe+N75hHwCHgEPAJNjIAnwSYG2B/eI+AR8Ah4BMIXAU+C4Xtv fM88Ah4Bj4BHoIkR8CTYxAD7w3sEPAIeAY9A+CLgSTB8743vmUfAI+AR8Ag0MQKeBJsYYH94j4BH wCPgEQhfBDwJhu+98T3zCHgEPAIegSZGwJNgEwPsD+8R8Ah4BDwC4YuAJ8HwvTe+Zx4Bj4BHwCPQ xAh4EmxigP3hPQIeAY+ARyB8EfAkGL73xvfMI+AR8Ah4BJoYAU+CTQywP7xHwCPgEfAIhC8CngTD 9974nnkEPAIeAY9AEyPgSbCJAfaH9wh4BDwCHoHwRcCTYPjeG98zj4BHwCPgEWhiBDwJNjHA/vAe AY+AR8AjEL4IeBIM33vje+YR8Ah4BDwCTYyAJ8EmBtgf3iPgEfAIeATCFwFPguF7b3zPPAIeAY+A R6CJEQhrEszNzbW5c+daVlaWtWvXziZOnGibN2+2uLg469mzp4OmrKzMFixYYJs2bbLdu3dbly5d bNSoUZaQkOA+y8vLs0GDBtUI46pVq9znffr0sZiYmCaG2h/eI+AR8Ah4BMINgbAlQQjsrrvuslmz ZllRUZFlZGTY1772Nbv33nvtlFNOsZ/97GdWUlJi999/v73++uuO7GgpKSl29NFH2w9/+EP78MMP 7ZlnnrGHH37YkpOT98KeY1599dV20EEH2Y9//GNPguH2ZPr+eAQ8Ah6BZkAgLEkwPz/fHnzwQVuy ZIndd9991rdvX9uyZYs98cQTNn36dDv//PMdNG+++ab997//dSR2+umnu8/eeecdu/HGG530d+ih h9pbb71lTz75pF166aV7wfnCCy9YYWGhnXTSSRYfH98MUPtTeAQ8Ah4Bj0C4IRCWJLh06VKbMWOG 3XLLLY4Aaag5L7zwQnvsscecBEh76qmn7Oyzz95DgHyGFLhhwwZ7/PHH7bTTTrOpU6c6ooQk27dv 736XnZ3tvj/kkENs+PDh4XZPfH88Ah4Bj4BHoJkQCEsS3Llzp+3atcuGDRu2FwwQ4cCBA620tNR9 vnbtWvvKV77yJaiQAlevXu0+P+qoowypDyny+9//vvsMUsTeiFrV2wKb6Unzp/EIeAQ8AmGIQFiS YF1xwhGmTZs2X9qdz/iO1rt3bzvssMPs2Wefta9+9avOqebf//63kxC9FFhXpP1+HgGPgEcgOhEI SxLEExTV5fLly53kF7QdO3bYypUrna2Phoco0mD1xj69evXa8zES3/PPP+8kQBxn8DZFjRobGxud d9VflUfAI+AR8AjUCYGwJMHBgwfb+PHj7ZprrrE///nP1q1bN6ce/de//mWLFi2yxMREd3EQ2d13 3239+vWzE0880X32ySef2EMPPWT/93//twcAiPSEE06w22+/3ak/zznnHBs9enSdAPI7eQQ8Ah4B j0D0IhCWJJienm5f//rX7S9/+Yt9+9vfdrGAqampduaZZzpnluLiYndH8OxEWoQI2ZeGdIekyL5B Qz2KY8w999zjwi2wI3opMHofan9lHgGPgEegrgiEJQnSeWx5119/vX388ceGGrRDhw5OOnz33Xed SpOWlJRkV1xxhbPvrVu3ztkBu3fvbhMmTNizTwDEkCFD7LnnnrPy8nIXTO+bR8Aj4BHwCHgEwpYE UXu+9tprdtlllzkpEOmP+L+cnJw9NkFuH6rRKVOm7PdOIvlBor55BDwCHgGPgEcgQCBsSRDHmG3b trlYP+L6kP6w7ZEpBpuhbx4Bj4BHwCPgEThQBMKWBLt27Wo///nPXeA7UiC5QIkT7NSp04Fes/+9 R8Aj4BHwCHgEHAJhS4J0jlAJNt88Ah4Bj4BHwCPQFAiENQk2xQX7Y3oEPAIeAY+ARyBAwJOgfxY8 Ah4Bj4BHoNUi4Emw1d56f+EeAY+AR8Aj4EnQPwMeAY+AR8Aj0GoR8CTYam+9v3CPgEfAI+AR8CTo nwGPgEfAI+ARaLUIhC0JUjh35syZrvTRpEmTWu0N8hfevAhQgYR8tAcffLBlZGQ078n92TwCHoFm RyBsSXDBggV23XXX2fe+971mByUaTti2bVtXMYNFhC8cXPc7mpeX55Kxn3vuuXtVIqn7EfyeHgGP QCQhEJYkSOX4Tz/91GWIOeussxyeSIYk03777bddVXgK4lIkNzSY/oMPPrCXX37Z5ROlzNLYsWP3 3AtKLFGKKS0tzR0zVLqkkj15SmfNmuVIgyoUpGvbV9u8ebMrzovkQAJvyjPx29BGurc77rjDJfWm Gsa+2v3332+ff/65u54f/ehH1rFjxz27b9myxeVNJWvOxIkT7fzzz6/1UNRKfF3X8t/5iy0rsaNt 3hxvFUoabjGVfaMixzPPPGMfffSRK0HFsShVta8G9hAD10ffAlJdvXq1/ec//7H169e7/oJ5bcnJ N27caC+99JJ98cUX7h4cd9xxdsQRR+w5Lffuqaeect9R5eOggw6qsUtg+sQTT9g3v/lNh0do4xhc H/2jdiQNaY7KIWQdopoISdlZIHDv5syZ4/YfM2aMUXOSbESU2KJfPC/0g/745hHwCEQvAmFJghAM CbSZmIIG+T3++OPWuXNnVz3irbfecgT005/+1H0Ggd12222u+sT27dvt1ltvdRNeUJSXCZxE3EyO TIahJAgBLV261DIzM91kST3CrVu32je+8Y0aK9dDmpDC4sWLXR5T9qeCBUQYHx/vugyRv/DCC+47 PtsfCXJN9I9rgIBDSZBJne+QjlkI7IsE//Hww7ZAZFrRrbcrFwWODz38kF3+rW9Zhfr49NNP28Pa hwXChx9+aBAs6em49toaC4vHHnvMVer4wQ9+4EgGAoSYkZz69u3rVIg33XST/fKXv9xr8REQL3hB YBAQ+N15552uRmRQ8gqMuMYnn3zSLWJqI0F+y3kvuuiiL5EgCxnIFqw5Fo3yWSwcxo0b5/rNOekn 95dFFkTKgoDE7FQkoR155JG2YsUKmzdvnlvg+OYR8AhELwJhSYJMzEgXodUhqBT/3e9+d08FCSZh JI+TTz7ZkeAjjzziJk5UqKz8mYyRGK699lp39yA9Nlb+FRUVe91RPofAAsJEUvr9739vl1xyyR5S C/0B5ZwgYCbjESNGOGno2Wefdcfv37+/23XVqlWumj2FgSHC/bWLL77Y7RJIM6H7I6HccsstTgrm nPtq44UBmGxIbWdzX3rf2lqp3fu3e+1ySU6bNm1y/aTg8AUXXOAIkoXCO++846QeGmTFdVC3kQZZ QIAsNihwHGA3e/Zsmz9/vr3xxhtO2mLxgAqRvwMJnD6fccYZbqFw9NFHO4mLnLC0P/3pT/a3v/1t DwlyPrb8/Pwv3Z/Q64XYIWwWMtVbUGIL4grIa+HChe65CRZUDzzwgCPw3/72t+7e0dasWePIM2hI s5Aj1+dJcH9Prv/eIxDZCIQlCaLuRGqA+II2cuTIvZBm4oX8AsmLVTuqRxpS1THHHGP33Xffl+5O YWHhlxwejjrqqL32g3SoYoF0V1ObO3eu61swiTLRM7lCMpAgUuA///lP51yBeq2249R0bEi6pgme fZFWavsuONbhhx/u3q5cuc7KK8otOTnZYqRibSMpCAkbKTmQvoYNG2Z9+vQxCC0gwX/84x8O04AE +Zv9kKY4d0CC4ANOHJN7QcUPpK+A5OgDJMd94/cnnHDCXpfLvUMqrN5YwByIDbP6b1HlghuN+8IC 5yc/+cmee8fnYMAWNDDjWrk23zwCHoHoRiAsSZCJluK3tU2GTJRIWKzSIRmII1C1BbcLWw6qr/o2 1KJIPKjGAoKtfgxIOtQeBelCrkHFewgZYsEGuWzZsnqRYH37W9v+YFdcVCwpZ63ddeWVplnd9bGg oMARY9CQrAKS4LO///3vzoZJA4v33nvP7rrrLrewCL0nkydPdsSGNA6hITFiaw0Ilt9z/TWVvUIN i1r2F7/4RWNdbp2Ow3PFQiWU8Gr7ISQIafrmEfAIRDcCYUmCEAwTNRN2oOIKbgOOH4GK8zvf+Y5z XIAUISzIMGi8r+44sb9bCXn97ne/c04bqBSZCFGJUdiXduqpp9qvf/3rLznA8B1kEpDm3Xff7cgB SYeJN1QSfPXVV50Kknb55Zc7lWtTtI0bNjpnopEDB9gJxx+/F+mFno++hTr0IPEFDdXoscceawMG DHDq6dDr4G8kYuyXSI1gt2TJEqdiRQKm1VTsGFsuEjsq2UDabMzr35fUzf0MFiz7Oyf3LT09fX+7 +e89Ah6BCEcgLEkQmw+OIUyooQ4S1BbE5gdBQiQdOnRw8CP19OzZ0zlnDBkyxH22du1a57BRvbFv TRImzhHYsE4//XTnWBGoHXG0wT5IC7wokZSwCWK/QgXIe1SCQVwZdr0ZM2Y4pwz2waEEwkM9iING cLzAfhjaR85b3cs0+B6i3Z86lH1nzpxhD//jYcvtMsAGjjnYkhIrvSiZ1PE+BSfsnywy6B/XWFOb Nm2avfnmm862ipSLswi2S5xXsLXx97333uvIH5UwDjvvv//+HhKsfsznnnvOqahZvIRKjKH71XZ/ gn04F9eBXS9URQ75sUAKnomarodjY5fkXvNb8AwapBc8F9gH+RvvWd88Ah6B6EYgLEkQkoHAcLII SBDX+quuusqp3qguD/mgxkNSZGI8XtLOo48+6iZ31KB4NF544YV77h6qLdSBTPqBChAy5bd4jOJN irMItjH2YxLkHBBbdZsh3oO40ONmj0MNkt+gQYP22DBff/11dx6kUSSkP/zhD84ORcNmFmo3CzrI OYM+MpmjckXKDexweGFyvezHK1IuUk31xnXfLO/HXsedbJ3ad3L778zKtg4ZbR3ZsUigvywmcNxB PYhUFrSvf/3rbiGAapOQBc5Fv5D8fvzjHzuHIxpkyvVxjw477DAnFWJvDA23ABvuFRIfZImDEDjg JAM+XFsg6SO1ItHzeXCtfFd9QcB5CWFgIcGxud/8DmJm0YQDT2ij74Edk2Ph8Ys3LNgh7XP/cTjC ponnK40FDP1hweKbR8AjEN0IhCUJ4nQxfvx4JzV8S679OGAgYRAewHeoGpmkaDikoH5DrYjEBfEx 2Z133nlOOgkaEz6qTgiSFT8T3+233+7IE+9HVHmESuAIgu0LyRJyrK6O5Xh4P1566aVOrceGXRJv Q/pGgxCDhrs/5FOTbSz00YJc8NLEM5bJmMn+lVdecZIN3osQE4QGQWALxRMzUAuHHgepbYGktLUp GZZ7ZHt75aVZtvGeW+25p550XpVIpPQVIgFX4v6QjoIGkSEh0kIlIRyB2LgvNIgNifnmm292xAhO LCK4N0GDWAIVNfcJiZn9kbghpgkTJrhwDRpYQ2zcHxYpqI1Rx0KYoY2FC+T317/+1S2KOAcLAjDH jhsae8jvwJF7EDQ8X3kOOC+SOfcaqRBypCHxIv1yLwNv4b064P/wCHgEogqBsCRBEMbxAuJ78cUX 3QSFGg4pjckz1GGBiZyG1AYpBHFsTPihji0nnXSSO2ZoHF+gOnvwwQfdZFhdagh1IAm965Ao9kGI ACkE219Nno78Bs/IIHB7X08OfWdSZ8KmH6j3gkQAkA+kADlA8EzUQRxc9WPixAIxv7l6g/3sw7l2 iGx6tx/+c0uvSgHGxI6aFgkPaQgMQlWsxGKGkkZwfNTT3Av6xf7sQ6we0hT9AdfqmLN/sIig/7RQ jEPPg20RiZLjcA7IszbVJp/jVINalePRH/AITZwQ9JtFTfXrgShZyCB1ci5+G9y/6dOnu0UA13Yg XqpRNUv4i/EIRDECYUuCPXr0cIHjgSoL1eD+sncwqQeejdXvGRNdbcSxr0Dx2u49E29oQHtt+0Fa dclBuS9bFsdAMq1LC66lc0Gpm8Sxn/Xu2cNiQn68L9Kujcwh4Ookw2fBIqSmvoVe977247d1ub+h 54DYCHbfX6vtekJtuKHHYKGEc1BNqub9nct/7xHwCEQeAmFLgkBZX+/OyIO/6XocSMtIuCVl5ZYU 9z8nkKY7a+QfGUm0ttCYyL86fwUeAY9AdQTCmgT97fIIeAQ8Ah4Bj0BTIuBJsCnR9cf2CHgEPAIe gbBGwJNgWN8e3zmPgEfAI+ARaEoEPAk2Jbr+2B4Bj4BHwCMQ1gh4Egzr2+M75xHwCHgEPAJNiYAn waZE1x/bI+AR8Ah4BMIaAU+CYX17fOc8Ah4Bj4BHoCkR8CTYlOj6Y3sEPAIeAY9AWCPQJCQYmp0/ rK8+ijtHogGy2nAvfKB8FN9of2kegQhGgMxMdamM05SX2OgkSC5GStWQpNi3lkGgje7B8tgkK4hv b59//rldO/sDi9utuoYiRd88Ah6BfSPQxnZrrMRYbsduVkG5rd2V++/W8IlR7uKkvGxLys+1Cj+e DuhRgvwoxh0UQziggx3AjxudBMnmT62/fRU3PYD++p/WEYFPt2fbG4vWWbfOmXb88IMtIcYTYB2h 87t5BKykvMLOf/0z25BfuGfslFbstozEePvuyAF2Yv8eATd6tA4AAXJD15T4/gAOWe+fNjoJkqQ6 tDp5vXvkf9AoCOSt22zxyza7BNeHTq6s9O6bR8AjUHcEkuauMduZbTHxVXl3yyosLiXJBo8abRNH DKj7gfyeYY1Ao5NgWF9tK+oc5Y2QxkmgXeQTaLeiO+8vtTEQYMy0qSi3GJkRYioqtSix7r1Krmls +RY9CHgSjJ576a/EI+AR8Ah4BOqJgCfBegLmd/cIeAQ8Ah6B6EHAk2D03Et/JR4Bj4BHwCNQTwQ8 CdYTML+7R8Aj4BHwCEQPAp4Eo+de+ivxCHgEPAIegXoi4EmwnoD53T0CHgGPgEcgehDwJBg999Jf iUfAI+AR8AjUEwFPgvUEzO/uEfAIeAQ8AtGDgCfB6LmX/ko8Ah4Bj4BHoJ4IeBKsJ2B+d4+AR8Aj 4BGIHgQ8CUbPvfRX4hHwCHgEPAL1RMCTYD0B87t7BDwCHgGPQPQg4Ekweu6lvxKPgEegkRDYV+Ex X5SskUAOk8N4EgyTG+G74RHwCIQPAolxsQbZVdXTdR0L3sdTaNe3qEHAk2DU3Ep/IR4Bj8CBILB8 V7b9/sPZtjo719JVPDenuMTSEuItqEcdFxNjZSpPdu+shfbs4pWWU1Rs/zdumF06esiBnNb/toUR 8CTYwjfAn94j4BEIDwS6pqbY7C3bbN7KDWbJiZYqAmzTpo2Vh4iDxWVlNmvTNisrKbHU5CT75vjh 4dF534sGI+BJsMHQ+R96BDwC0YQAUt+PJo62X+cX2jZtcB+Fqau3+FhJhCLHM4b0s7OH9o8mCFrl tXgSbJW33V+0R8AjUBMC5w0fYA/OXWybcwtUSr5mjMorKqxr2zQ7YUAvS4n3U2ikP0n+Dkb6HfT9 9wh4BBoNAVSgZw/tZ4t37LLc4lKLCwyCIWcoKS2z8f172YkDejfaef2BWg4BT4Ith70/s0fAIxCG CJzrpMFFllVYJBLce4os211haUmJdmSf7tY5NTkMe++7VF8EPAnWFzG/v0fAIxDVCPSSqvO4fr1s bXaelUr1GSv7X9CQAif07ix7YN+oxqA1XZwnwdZ0t/21egQ8AnVC4JIxg+2ZJStto2yDsbGVJFgh J5mEuHg7pGcXG5zZrk7H8TuFPwKeBMP/HjWoh4EtAxdvvNl88wh4BOqOwNguHR3ZvbB0jVXoZ4yg IoVHjOjcwc4dNqDuB/J7hj0CngTD/hbVrYMFUtOUVpQrsLeS8PJKypwap1w2jJ2FxZasDBisZGP0 WZLeE/jrm0fAI1AzAoyTb40dZu+s3GjZxcXWRgvJeI2ZsV0y7eAeXTxsUYSAJ8EouZkfr9tsLy1b bWWyYUBw62TPKCkvt4Xbdtp170+3BH2WX1Jqfdu3tZ8dMtb8jY+SG+8vo8kQmNKrq40W6X2yfrOV SArskZFuXx0+qMnO5w/cMgj4ubBlcG/0syalpdkLy9fZ6s1bzeKV6UKu3YnKcbhDqZ3mbdpO1K87 58WTxrjPffMIeAT2jUCqxtFPDp9ks5961YrLyuUQ08NOG9zXwxZlCDSYBLdt22avvfaalSh9ULwe Ft9aFoH8oiJLyS4xS0qylBAbIGqd+IQYK1c64NSKMotbOMce3brClA+qZTvsz+4RCHME2mjhuK2k 3Epysi1eDjEVC2bbY9nrnI3Qt/BAoEwSemZmpp155pkN7lCDSXD+/Pn22Wef2ciRIz0JNhj+xvth RlKCTerR3jbvKLAC2TAgv9CGvbBTapId1aOT7c7Pa7wT+yN5BKIWgd3WMSXJvjqik322JcvO6Zlm Fbk5fgEZRvc7KyvL3n33XTv99NMtpoF+Dg0mwYKCAjvyyCPt3HPPDSNIWndXhm/bZbOfecMW5BdY Ukg6JxIAp0gFevywQXbx8VNbN0j+6j0C9UTgiNx8e2vFOrto7NB6/tLv3tQI5Obm2i233FJjjte6 nrvBJAjrFkvigAxTUlLqej6/XxMiMDyzrfVrl26fb9lRaQOskgbLyiusizLknz6oTxOe3R/aIxCd CPRJT7WLRnmHmHC8u5BghZwBD6Q1mAQP5KT+t02DQIKkvcP79LBPNmyx7KISixMJukz4smJ0Ewni 7eabR8AjUH8EvDNZ/TGLlF94EoyUO1XHfp4iae+fny+17QXbXKgEpWDaJiba0f16Wkqcv911hNHv 5hHwCLQSBPysGGU3elBmhg2QWvTzrTscAZL7sGNCnJ3pcx1G2Z32l+MR8Ag0BgKeBBsDxTA6Bl6h J6rMyycKnt9WUOi8RPu3a6ug345h1EvfFY+AR8AjEB4IeBIMj/vQqL04SRWv75q10Dbl5Ft7uXif NqS/S5Xmm0fAI+AR8AjsjYAnwSh8InqoztnYrh1twdadLlTiRFXA9s0j4BHwCHgEvoyAJ8EweSp2 K8+n25QBwW16L99f280W8r5CmWHK8/IqN70PQiEqCgttt7L3UDUiRkmzp2zcaS8qR3bPkkJLeeM1 25mcYGXKGsP3bRTS0obAUhJqJyRYrFKuxeqzmNRUayPnmTbyMnXfa+PV/c3Gd1Xf+4wzYfLg+G54 BDwCB4SAJ8EDgq9uP4bEKhRTGbrtLi11RFa6Y4eVbN9upTt3uvelSkfHa5niXxzR5edbeU6OlfGq mExHiBAUZBaaIYGYwKq4wFiRYJe27S3zjIttxOqltvrOdyy2tMR2V+0Pse7JJ0M8IURb9RqbnGyx 6ekWK0KEGCHIOP0dp9RE8doSOnVy7xM6dnRbXLt2FiPv0zYiU173bPrbN4+AR8AjEO4IeBJsxDvk CCvYJJlBZMXr11vxhg1uK+KVvzdtcmQHKbpk1+ReJXwh5D0SlyM7JDCSEYiMYngvcmkjonKbSMcR nwjMva8KgVDubOucnGrHtkux4/t0s7QOp1iZSNcRH4THeYNgen2+W31FwuTVJIWWa59ypFL135SW SH846dTYVxv7uFdJnjSIMLFrV0vs0cMSe/a0JF618RrfubPFKJ8phBqHxIm06XPNNuJT5w/lEfAI HAgCngQbgB6EUZad7UiuTFJaqSS5wtWrrXDZMitYudIKV61yZFcqAoGcnPoR0hIZuPcdOlhs9+4W D7m1bWux2tqwZWRYDBvvUU/qNyTE3vOeY9VSAcLViAjJEsP7i1VHsG1ivMuptzskl2htqbPdMUSQ u6sIcc+rJNAKXetuXWuFrhty5NW9F+mzX7EItEjXvnvBgj2/r9DvYkR4CV26WHKfPpYycKAl9e9v KQMGOJKM07U6KVPXy3vfPAIeAY9AcyPgSbAOiO9RWUp6K1q3zvIXLbKCpUsd2RWuWGGlu3aZScKJ kUTkCE0TeuyYMRbPewhPKsQYvbpNKsRYvTrSQ3qDuIKtisicajIgtdBXeA6JrI6tveIDKaTrVKgh reroNR8Fm58ktjYipz2tStXqyDNE7eokVUmNFVLb7pY6t1xbBRKu1LkVWhiU8ypsduv7PC0Ict5+ 23Y/+6yV6z3EnNS3ryVXkWLqkCGWPGiQJUpyjBdeqFqRIH3zCHgEPAJNiYAnwRrQLZIUx1ayebMV Ll/uSM9tCxdaqaSgWCZotvbtLXbyZEuA3CTtxHbrZnHaeA/hOSKpsrUFr4Htjb+RoPZmp33SU72f gwZl1AsIuIazud7VUILJSbuSbGOlCnXfV9ks3askS0ivYutWKxeeFdrcK3+LIHOlGs4SruVbtliM CN6R4vDhljpsmKUOHWpJOqZTrfbq5VSpvnkEPAIegcZEwJOg0MQppbBKjZm/eLHlzpljuZ9/7qQ8 0wQfi+pO5BZ/3HGWrPdM9hBeDPYu2cJQXzqSC/HidLY3qQqjrtVEklWfVZc43bXjrYpkrAVDvIgN G6fbIEeIUFuFCLB840Yrl5RdDinqXuz46CMnSSZIuk4bNcrSJFmnjR5dSZLakqRe3csxKOqA9hfk EfAINAcCrZYEC0RweaqJmC+1Zr7sWHkiPSS9Ck3QcZpk4yWFpB17rMVBeEg5kJ821Jg4huwhPJxG pO7zrRYEqhYHXyJIyBHVsBYSJoJzTj3CFUIskxReLiciR4x6LVizxrKffNLK777bknQvHCGOGGGp bLpP6SJJLyX6J9Aj4BFoCAKtigQL5LiSM2uW5c6bZzmzZ1vezJlWLCkwVqq2eNmkUi67zOJlp4qV lOGkPak1g8k58JDEOcS3RkAAcsTLNPRQhH0QfgExTpzonICcKlVEWLZ2rZWLDMukns7RwmXH++9b G6mTU1XUue2ECZY+bpy1HTvW0sePd56ovnkEPAIegbogEPUkWKjJc5cmTEgvX9Je3ty5ViK7Hqq5 xDPOsNTBgx3hxSDpScrAgzMIAXA2u33YyOoCsN+nHggExFjl/ANBEk4RJ6/SOFSpajje7JES8cKV NL/p+edt0yOPWKpsiahM0yUpZhxyiLWfqgLCNdgw69Ejv6tHwCMQ5QhEJQmietv53nu28913LXva NMuH+CTBJUh9lnDuuU6VFovEJwkQ5xbsdy4GDsmE2DjfwgeBqkw62BBpOBvFS/0ZL8mPz5KkMi3D ligpv1iS/ZZXX7UtUp2miTTTDjrI2okIO55wgnOw8c0j4BHwCFRHIKpIEOeW7a+9Zrs++MCpPIsk BcaI7JLOO89JB07ik7SHo4ZzXFGwtye9CBsUVWnlXK/lferstbrHdvDBlnjMMZZGIgKpTIs++cQ2 //e/tuOll2zzE09YhtSrmXJsyjzqKO9QE2G33HfXI9CUCEQFCUJ4m//9b9v14YcupIHsKImHHWbt vvMdi5OtLwZPThxaID4kvmj02mzKpyRcj121kHGZa6T2xGM3tndvJyUmHnGEsyOWTJ9uOW+8Ydl/ +5ttfeEFS5e6tPPZZ1vn00/3cYjhel99vzwCzYhARJNg9owZtlG2oKyPP7YiZWwxTYIpF19sCYrd i0PiU6we7vhO4lP2kpZosTVkeCFWMNhC+xTsS8qy6s0lxpbkU/07PuO7oHHcCtS7IY3j8tmeIHx9 FxwvdP/qx6reh+DcwX7Vj8n+wXFr+q5J8QdTyDAgROI29QygAk8+9VQrVehL4euv2zYRYtZnn9nG Rx+1LlKNdz3zTIv12Wqa9Nb4g3sEwhmBiCRB7Hzr//53y/r0UyuWSz3qsLQrr7QEOUPgcu9ybWJL Cslv2VI3oZjE2SEEBElASvHkCdX7UMIqqaoCwfehhEXf2a9MqsCAKF01CG0QUynSLRUhRIgcl9fq xw0luOC3nI/94sgSo2NxfI5XnUQDckuoSoodnI9zhTaOQT+K5FDE+WpaADTLfQgIkZMpzjOuXz9n /02QF2mZQmMKX3zRsmQzJiwGh5puF1xgXb76VZe+zTePgEegdSEQUSRYJBf5tffcY1ufe87l64yV qrPtN75hCbL3EHNGcmnn3FI9E0sL3NNETb5r1N9vfetb7uyBtAbh9Fcc4le+8hU79NBDK/N6atJO klfqD3/4Q9upkI2bb77Zesp+CYEGktUrr7xir0uS+etf/yphp8QR13Kpfv/zn//YbHm+Fip3Z3s5 +RyihcC5knA6sxgQKW3RIuGqq66yX//61zZQXpY0zsVvfv/737u+XKkFRF8tJK699lp7Q5JSTeTF sR988EH32//K1vaE7GxXXHGFnSCnE0iPlqLFx7/+9S+3H8c8/vjjXV+rE3qz3o7AsYbFh8IvYqiG odjCcmFUIK/SHDlP5V93nW3RM9Vb19Ph6KN9gu9mvUH+ZB6BlkUgIkiwVIma8fhbf999LkE1zi1I fklMWFJlEU/mavFVeRC2LKSVZ4eACqSC3aXUYP/3f//nSAkJK0+B9dMkyf72t791JAIZQiLsv0lO HXPlyfqcJuRvfvObTqrjN3yXI+/WDYqX4z0ECwHefvvt7njnnHOOikykud+/Ku9IyPfnP/+59VDY B9LdWtnGINRAUlyopAAQIBLdeXIaguAgqvUKUqefZ0pFSAskQl4huOD3YxWP94gkKAhvqrwv6Q/f bZSn5tNPP20dtSAZKqKpSeXbYvcG6RDNABI05aHkYZquRUGKbIP5InRU6nnf/rZ1PPFE6/2jH7m0 bT4jTYvdLX9ij0CzIRDeJKiJK1vB7aslGe3Qir2NUmgla9JO0So+ThO8C7SucnZpNsTqcSJIIFOS x8knn2x9FIAf2NTOP/98+/Of/+wkqpEK9h4iiZYGmUBCSHfj5NwxZcqUPWdDOgvUkUhjn0oVnC8H n+uvv95Jc5Ad5ztIYQEQ7EotFnpJBRiQJr/n+EsVaH7LLbc4UuS3o+UoEiqtQXAQc022RT7jd8MV j3eZEgv84Q9/sJfkffm1r33NnecFOZ5ApDfccIPrE/0Lu1YVi+jIUDjG6frbqq8l4ClSx6MUByuI sLvsyz4TTdjdQd8hj0CjIhC2JEgB2S3PPOMIsFASUKIkjtRLL7V4kQau8RSGdfF9EdICOxzdbScy RwKDLGYqti0gIkjyAtmnIDjUnhBJNzn71OQMgwSIChRCRGIMpEZI8KKLLlKFprZO0gvOy/cQ1J13 3umk09/85jdfIkD6hkQXqGirQ+tqDFY59Rx55JH2rhYmEDkkny1p/eWXX7ZjFKYAeUOWYd1CyVBS bpJUtwnKNlMgKbxQ0uyyX/7S2Qz7/OxnLlepbx4Bj0B0IhCWJEgB2jV33WUb5PxCrs402dVSRBpI gi5vZz3KCYXDbQukqkC9iPoT+1yGVLnrCPQWuQROMqgSv/vd79ovfvELe1Iq4O9///vO/hfakNyQ IFGbQmZnnXWW9ZPzRwd5w3ZSGSIks1CHHKTAzarccJ/UyR8ohhIJ7mDF1UGi1e11/B3YL0O9Tquf v4u8LzkP50dyhXDZkCJTVe0BVXBEtCC3KWpnqYXTpIZOELZ5DzxgG//xD8tTXtn+114nW+HhWiHs 7QgUEdfnO+kR8AjsE4GwI0FKFq2Qg8ZWefAlSjWXIukvUQHOLn1ZVSXzSL+nkCEEmK7sJ0h0EFag 6uQ77Gyny1b1b8U+Tla4B38jnQUNgpk0aZL9+Mc/tscff9z+8pe/OFUnNkDI7UTZtVCr0iBAzoEN D1Uotj1sizWFMCAtzlPM5cMPP7yXPQ9iTFaBX2yF9JPfQuQT5G15qsIPHnroIUd8ECDqVMg14loI GSYI77ZyTMr/5z8tRyrexZd9yzr95lZLPfRoFUJOFAby7k3UpteEJFXE8M0j4BGIWATCigRRPy35 6U8tS2V0UjSRu4TWyu3pHF6iLIcn0h92PMgl1BsTgoHwcKZBVXq3KidgMwwlQfbhd0iAR8s5aIXc /nGomSX7KQQ2X/k0r776akeK/C5XqeC2Kefmrbfeam+++ab9QxLOeKn+ICwINdRzFYJEzVldQoS0 TzvttD370n/6wGdvq1guhA5xByrTiB0RqHtF4lQMSf/JTyxOttySh+615699zjaNTrS2naWZSK6w 9Ix4S89MtraZidahW5pldEiy5LQEbfGWote0dnIWiv1f/GbE4uE77hGIcgTChgSp8LBUKsBd8tJL UUaPNKkEqdUXDuEOjf0MoN6ElLCjocZEikOVSIN8IBLUmqhFCW3AC5O/A/sexDZdmVDYF8lvsBYK OKtcKqkZdefPZMdaIDUejjEcCxvk5Zdf7ux1XYUpv4Vc//SnPzkig4xpECJE9qtf/epLjjGcC0eX UPskalkcflDNIkUOUmX4HaoBGBUNe6quKUVOTAkZKZb2yBJrs1DZZzZ3sfyefW3tkhIrzCm2wrxS y9drvCTCjiLDjt1TtaVZt75trfvAdta+U7JldExxryltE6ICGn8RHoFoQiAsSJCitivk0Ui1hxRV dkiTHYy4vyBpciQDDnEFjitBADmqQ+LxcFAhlKC6ajKwyxFHiKSFypP4vyDgHeLCK/OLL75w33G8 wAaIihLSC+x9HBsVJmQLyQ0YMMC+rVCAm266ydkceR+QYGCXDLxFQ4Pma4v1C81+06LxgE3xkJC5 h/t32tk2ruIV633Pw1aRm2wdD7vCkg8+0nJ35lteVrFlbSu07B2FlruryHJ2FtnK+dttxhurLTe7 2NqJ/HoObG89B7W3/iM7Wo8BGda9X4a17+LLPTXFLfPH9AjUF4GwIMF18oTchg1Q+T6dBEi6syix /0EwSH14cSJFQVZIaTipjFKsGrY9CKt69hX25TOku8+lJn5R+KDChGhQnx5++OH2saRmwh3wNMUb FEmNMAVID8/SQM3Jb+hHEHN4rIoF44GKnRDSDI7L/kinONGEhkgE2Wgg19qcZer74EXM/qhHi0ss /bQTLK5gp+XLuzbphTtt9NemKCftgL0uI1eEmL290JHi9g1SQa/Ps63rc23Lujyb/c46e/2fX1jH Hmk2eFxnGzimo1672JDxnS1OtkXfPAIegZZBoMVJkJgsvPBi5IiQCgEqED5aJEDICu9P4vaQ1oI4 O2x0hEUghUEsSGgQF5+HhhZAXN2FBzF5qDMhKEgI0sRh5pJLLnGemdgOIVlIDvLk8yB2kM/4XaDG RMrjnATj8zs8RVGLolJlH8gWB5pANRu8ElB/2223Ocea6iEb9D9IA9cyj3ETn3W38q6Wt7GkM8+x 0jXrbacwX3rzbTZEsZ4kaghauuyAbD2lBlUiW/dxSVGZiFBkuC7XNqzIslULd9iKz7fZpy+vsm6S CMcd0cNGHdrDRkzuZmkZiU18If7wHgGPQHUEWpQEKzQhr1UoRImqh7dVaq94JTumrl80NMgGO94v FW+GhBaoFrEHYkdDvcn3fAexsT82QNSWgXo0UDVCeKgvITr2gxyxI35V+S6HKbMJkiIeoGSNQbrE 4QXVKYSKhEjaNOINgz5AopDkjTfe6ILqsUfSD47H76vH+NG/wIEnVOUZHI+MNZwvLIPjG+thQjWq hUqqYjBLlXFny7PPunyjrnDvPlpCUpwjRbbxR/WyPKlINyzPsvXLsmzuB+vtvaeX2SevrLLRU3vY 1NMH2MRjezdWj/1xPAIegTog0KIkSN0/Kr7HUfpGThsu+D2CAuD3hS9EhcfkD37wgy/txncQEVug XoSIIBNILpSE+Bwp8WJlL4F0SJ8WJLuGeFCnHiY1cpC8mt8SvhBkkEEC5beQZCDBBUSGShXvUr5D Cj1KoSiEV9TU+A0SZU12Qo5BCwi9Ds9dZO5CAnN5jSYrY1HuH/9oGxRL2F6LGZI31LUh7Q05SGpQ beOP6WWrvjLIpr2+xj56cYUtnrnZVn+xw068ZLiTKH3zCHgEmh6BFiXBLcrMUaaJta0mFSqGRwsB ctsCJxOcX+rS2B8iqt6C40BAwXGDfSCkgExrOkf134buE3h7Bp9BqKg1GxLkHvwm6u2F2AdFhEla dBQqU06WCvcWKDwlRV6xDWntO8lr9OjejhDHHN7Tnrtnrv337jmWL2nxK1eMl3rUe5M2BFf/G49A fRBoMRIsUrLnXKnx2kglGF+VrJgJxjePQFgjQEYdSdeJCk0ponK9YiQbSoLBdaZKOpxySj/r0ivN Hr91hr3x+CJ5j6baGZeNCmsofOc8AtGAQIuRYL48JEslJcUpvq2NXP5dLlDfPALhjgBJGwibkO20 QJqMHFUEse98x312oG3A6E52wU8n2N1XvW/TXlstG2JP66XQCt88Ah6BpkOgxUiQ2oAVsoklyiuU oORIyQgTxOrVVP296W5Tw4+MI04QB9jwo/hf7kEAEpRHKFVMUN8X6jkOzbd6oEgNUvjEUecMtqfv nmuLpm32JHiggPrfewT2g0CLkWCZvBFRf6JacqvoCEiLhs0rcFrBWaWlg8M5f5BcuyZSDux+9DXq 7XXNONRd5h7ZsF38JbbaRn52ew1ubzk7imzbxjAsRdWMOPtTeQSaA4EWI8EYSSgULXV2wCoVU3Nc 8IGcg3ADYurw0Pzd735nWQrtONDGRApJheYGDY65v6rsxCHieMNv6Vuo5ybkyHc/Ul28P8qTkaoP dZUImeT5fdAnjht4m9I3zssWeKRCwEHOUOIFa6pMH1xL6LFDg/g5Lt8Fx+bv6t8fKNaN9XuXSIB8 tvRXoSqN3fJzSlxy7sTkFhuejX1J/ngegbBFoMVGWTy5MDX5l2/f7qrCH7hFpekxZoLGgxPyq2mi b0gPOA4V2QlTCBoExAZx8X1tEichGH/7299cKAYxhpBzaON3W7Zs2VOqqa79g/S2bt26JxwDgqU4 cEBMeKSSIxSpGNKj/BOhGPyO84X2I7gWqloEWXGCfSB/YiWDbDr0F2whb0iVwHy+B4NQgq/rdTTJ flVaiwo9ty4lnnKxNqaUvWtrgUImVlmXvulKs6bMSb55BDwCTYpAi5Fgmhxi4jR5lyxZYrsVC+cK uRKQHAaNvoRKZ0hBgSTDhMzEHhAT74MySOzH90Eez7pcChM9CbLfV95UWpARBsKgIgREyLlraoRN fAenDLWAeII8pfQLwq6vKpTfk46N3KTLlNSc6ySwnvRtJMrmnE899ZR9pEofkBUEfMQRR9jZSnpO EgBImbyoodfCeypXkNB7zpw5du+997oCv2SuOUO5YinRRPD/IpXRIp8pVTCIj+TaiZ0kDjIoGlwX TJt8HyRjhUagyUgjwUM94gT31beiwjJ7+z9LbNZba+1w2QVHTVH2JN88Ah6BJkWgxUgwVWERSXKK KVBFgwpJHbFKyxUOLYitW6isIDuV2Bsy6al+knEltEEOTMzss2rVKjdpsx8SHZM9GVbYamtBUDz7 Uzj3e9/7niNACPgBBWEHZZb2JQFBuJsUasIrkha/3S4JZfXq1e5YZJAJGt+F/l29X0F/+B1p08gp SjUKzg/pUbPwLmX3CcoyXXHFFa7EE3lG+Q7J7corr7RvqQAyKdmCxOHUGuQaKcVE3/6uQsmkjCNd G9lqSNNGMWDqEtJviBH1LRLgbCVSgFR5P3HixAbFMDb6M4UkqGstmTHDYvS+vRYA1VtBbomSaVcm z66rSnPHpnx7/bFF9tID85VXtLMdfe5gV7PQN4+AR6BpEWgxEiTnYkdlJ8nWRFf0+usWJ2kDrzsm mJZqEAVk9tprrzlJBzUl2VdGaLWPxIUkFDSIB+nr0UcftQ+V/xSJDhJEoqOyQ+/eve2VV175Up7N 4PdITVSQgHyCvJucH+mK2oBkmkHK2pcdD2Khsjt5PW+44QZHIhDoDE3QEB7ESBYXpCxe6WdtjUr3 SHz0h9yjgYoPSfKkk05y0h3HoEYhadj4nHNAUCwQILiA+AIyhzCpcQgxok6FXMmlSgo4+k4ZKP6m XyeccIIr9URybxYPHB8ihoTDKhON7jtSYKkk2hQtdjKU0i5oxZLk1i/bZe9Imtu2scAuuOog6zd8 3ypNEm6v+Hy7vfTQAvti+iYbOqGrnf29MXrt0lLDwJ/XI9CqEGgxEgTlzlKFbVT17oJXX7Wk445z MYMua0wje9vV9Y4yeUN6FKn94Q9/6HJwYr+6U5UDSFRNtYWgBeWMkGbIwUkOT9R8kCjSI3Yz1JzV 83AGvz/llFNszJgxjnSC6g787lnlpCSZNSQa5A7dV/+DkA2I7mnFrdFfJCmkUZx4gv5A2P8U1rU1 8oZSk5D9g/PSH6S4l19+2aZMmeLIKZCAKb5LXUJIDGmYqvJgF0iuEPtzzz3ncqGyBdUvOCaSM4nB ITfynmJfDJxw+N00xd6xD2pRFiCQc1Bvsa73skn2Q+2p+1WgZ2E3Ev83LrU4LQRIkr36i5028+01 LjE2ybJ7Dcl0mV9qaqXF5bZlba6tW7rTPtH+s1RhgqK8x5w3xE7++giVW2rXJN33B/UIeAS+jECL kiAxgl1VtHSlJIN82YzaqoCsS5/WQpljUOkF+T4pNYRtjEkZ6QxbWKgzDJM59i2IbJxyn0J2lDTC lsbkTt2+559/vkavT24DpIQTSDD5Q8Cch/N+/etfd2rBukz8zl2/yqsSqQtJCkKGXC+88EJXZBci Q/J8XRJ3bU4c9IVrdLbZKo9ViByplkXBT3/60z0OLEhpSH5cKwQIyUFqAQFyDI4FfpArjjPgwzWR Z/T+++932IE3hIcUGniagjelpt577z2nasVmyD0JB8cYHLkKpSUoffct6zhuuGWceJotnbPNZkF+ SoK9XSrNRCXMTkyJd4V2KbgbNGoNblfIwzaVWFo+d5vNfne9rVq0w7r0TLPJJ/Wxg0/o55Jnx8TV PQ+pn9A8Ah6BA0egRUmQ7veQwwWpp3a++65Ln5YiVVxLqUUhOSZ+6uwtkcMOkzTSD1IPHpKhBML7 QMoKJD+8HCGAwCnlnnvuqZXIIE8SWHM+Gr9F2kQCpEJ7cK5A8kLdWt37s/rtpz+QSECs9D1QUUJW 2PRqa6gmsbvRH/oCIeOYAwFi/0PVy/GDY2PXe+KJJxwZXn/99c6h5dprr3Xky3n/q5RiVLFH5Usf UOviQYpq9LHHHnNSHsQMDkixYA25cg4WAZSPwlHmF7/4hZPIp6paQ11DPA58WHz5CG0oITVvjpU+ +Ddrk5hquyZfbM8/sd6mK/n1ljXZlqBwhqSqkIbYWGkURICLZ24RXm1s0+ocW7Nopy2ft81WL95h qemJUpNm2mnfGGkjD+lmY5UZJi7O2/+a4r75Y3oE9odAi5NgnOxZ/a6+2gqlVszTpBsjG1Oyqqk7 78tmTqUWhECgVsTGdtZZZzkyuO6665y9LTRUgQkZaW/x4sVOJYj6EckI1R5ExKS+RtlEalOHQnYB ofCKJIZtjHNiZwukQIiBcAUkOrwoaTWFTCApoUZFwsK2xjGwbWKXoz8cr/o1hD4ckFUQo4ctFIKD dCE4JDVUnUiUXB8LBNSj7E/fudagv/zN7+gvFSmQECFGPqcv4AWpsqgALyRN7IG0L774whEdlTEC CZfjcvzGDEPY36DY63s9hjGpyRazfIHt+tt9tnZLW9vS5wxbN629bV6z0BKU7CgpVf+EtDYiPtoH zy23lx9eYNgKu/Rsq+ry7Wzs4T2cqnTQ2E5GULxvHgGPQMsi0OIkyOW314TaX6rQpXK4yJX9DUkw Wc4YLmSiGR1lIBIkLiZ4JBucQZDqUNmhygskPqomQG6niaypEP+rX/3KOYcgbQWB40FgfW2Td0Aq fA/RYa/D0QTnG8iFyT8gAogDsiAMIdROyPf0BUmK/fkeuyQ1DHGKgcwgV0gIMvrrX/9a69OGBAjJ Ia0hwXL9SKocj2sFF5x1IKl33nnH3nzzTdc/1J5Ifnh3cgz6gkTLK9JioF7lFXzfltSPRyh/cz6k PGorcl1Ila/KPvzMM8+4fcHzyCOPdJJxbWEiTTp8yJCWlmxFi5bb5/+YY+tWDrItnYbZruLOFivV Z1JS7arLstIKa99Zz9LJ/ayHagl26pFu3QdkKEm21P2+eQQ8AmGDQFiQIGh0k/2qXBLEcqnUcuXQ IdHDkkQyEmOardBuEKCNJ+hbb73lpB7sXUzEkA2T9PHHH+9IAXLBYYN9IQUIAPJEKnQZRTSJ7y+j TECQnJfzYFsM7GdgAukiBUIc2NZoobYxbI9BjB3nImThG9/4hpPC2I++YiOEwCARiHdfLVBb4pWJ ZMs1Bd6rQUV5+gfZYu9DsqPfhx56qJMWg+B5pFwkS9ShgSRMfyDY008/3fUP0kZiBTPw4lxcP1jM mzfP9Z+/qXGIJ2ld7KONOqqws6alWO68JTb//g/t3YU9LDt2mKWVypu3okgxgkjkMbXmzcb5pc+w TDtfCbGT0/aWFBu1n/5gHgGPwAEhEDYkyFX0lB0IKXDlb39r2bffbuVyjEiWs0mspJrdVbazA7ra /fw4UDMyiRO7h7SC5BN4b6IaRWqBLCAgJDiIEs9ICJGYNiTCIHtKXfsK0UAInB/SCPrBeVFlQgRI TNWdQyAOvmN/SJp+IX2hTqQFBIZ6sq6OJZz/XNV3DLK7BNfAOZD6eKX6PPbDQLqDXAOy45wsGmh8 HlxL8MpvQ/sXeJTyPRLlcfISRqqkBcWHm50Aq1L6FWlxk3vvPyzpi6127sU/sMRDRsqxpUA2vizb oMrw2zaq/iPSYnyMHttKQgwWNm1kFywrKbcCpUDzJFjXkeD38wg0PwJhRYJk3ugpx4l4xZStlE0u V6rGMtkKU+UsEy8S2E2+xmawEzKR16R+CxxnuE2BRyZOMw8++KAjRYiGQHGCv+vjxMGxAgeZ0Ecg 8FYNpM/qxwzUoUF/AuLZn8S3P2kwNIVbTftCeLXZOmu7luA4tf2W34FfQwv7NsrQwdNWatwKSdUF UsnmK8QlZsd2m3zZpTbgqlOkruhvRYXllr2twLIU35ezvcA2K9Rh06ps27A829avyLJCBcrHiRSx CuINunNrvnXoriTxvnkEPAJhiUB4kWDlbG5dlCoruW9fW33bbbZNcXNlckpJuegiS5ajhYxNlerR FoolDL2LECWqQILVUUfiQYlNL5CQGuOOB8HijXEsf4xaEECE0wKMkl5lsr/myzu4QOEkSUrb1u/P d1gXScby5HE/TkqOtaTe6dZFG43HME/hDznKEJOXVWRkftm4Mtt5huZlFVtRvi8U7Z87j0A4IxB+ JFiFVtuDDrKhSseVJvXZWjnL5IoQSxWcjXqUgqZu9mnBwHq6CUHhMIMqM/CSDA0YD+cb7/tWueBi ayP1Z4WccApeeMEK5LRTrkD9DlLp9pOzVjsywrDfPvgzPTPJ2Mwy3F4lsgcecU6hFReUWmZXLwX6 Z80jEM4IhC0JAlqCbIF9FaSdIfvTGtkIs+SRWKIMI8ly9kiSHS6WfJ6QYQuEUwQ3FZUlqlDfIgiB KskP6W839kwF5pMFplT5YuMVmN9HzlnEryZIEmxIS1DOz049/pe3tSHH8L/xCHgEmgeBsCZBIIiR +rODnCXS5Sm4VXaadXLfx1ZT9NlnlqTUY6hIYySNyZWyUjJsBpth89waf5ZGRwDyIz8tiybZNUsV l1igmNAShcDE6LnpohjN3goDSVX6uBi8kn3zCHgEoh6BsCfB4A4kyDUfp5lMSYHr5TCzVRlJClSR oEjqqyQRYbICrmPkkEJqK+eJSHxhGNgNo/4JioQLhPjI+6lnYrek9lKFYBQqr2mJEgu00WcZUq/3 UvHhTKlAYxVO4ptHwCPQehCIGBJ0t0QTWYpCEQYpYXX3iy+2jXJg2K7kzoXKO8qklqQA+2RJjTFS o5LmikoVzR1w33oenTC/UqQ+tAO8kthbgfmlqs5RgKOVcpPGarGUoXCSHoqr7KAFFImwffMIeARa HwKRRYJV9wcvvjR5YQ5STTpiCzcpF+U2peAqll2nQJlOEhTLh90wHrUWOT8VpI2adDeJub26NHqf 8ip1J44uFGrerbjGMtVbLFFgf6G8PXerwgaFnDPl0dtDYTeZLJiUJ9U3j4BHoPUiEJEkGNwuKnun KKXWgN/9znooPg8V6TblyyyUuitbCbnbqPZdilSlCUoOHatcmtgOkRD3EGIzpmRrvY9YE195lXen k/pIbCDiK9dWqlCHImX9wd5HfGeSnKgyFHrTVQ5V7ZQODi2Bbx4Bj4BHIKJJMPT2JSnLS++f/MR6 KtPLLqUZ26aCttkqLluoore5Kt2ToGD7RKXoSiA3p9J5OfthqITobYiRMxpEYEh7OLnElCoV3I7N Vrorx0pXKWG5SK9Ikp8Sj1qi8qVmSiuQqfJN1K7kGfHNI+AR8AiEIhA1JBhcVIxsPR1kG2QrVJD9 NjnO7FJ1hgKVBCqUZ2meyC5OtqAkCBF1KYSoDDUxCnh3noOSJpza1EuJ4TNSCGTn3uCxSViDcpaW S7VZrpR1ueuzLG/+CkuZ9rLFb14lib+btVU+07aS+jrqGWh/xBFe6gufO+l74hEIOwSijgRDESbr TG9ViGfLmTnTkWGOPAILli61QnmW5ijjS7zKDyWIFLEfxinjC0415CqNUdJm52UKKQbVLLy3afM8 wJBelaTn1JwKZyjfts0qlEwc8ivV/StfMM9yFq6y6XkTbGPGWBtkw2zImHE2+v9OsT7nHG+WXBm4 7ptHwCPgEdgXAlFNgqEX3laVEdhoufISzPrkE1UImGcFy5ZZ4fvvW77Upm2kIkU6hBDjVRUhRsHS sfoMYkRadBMyKdtwtW/mMk9R+xiHOLME3py75clZrjJQFSI+pL3ytWutRAV2CWYvlUSfIOeWlAF9 rRNllnqcISk/wWYu7W/LKlJs69qeNvrjXOs7PM46+ZydUfvY+AvzCDQWAq2GBEMBS5d9kI1WsHy5 5WlyzVPgdKGKxRZoy5eHaY4qRsSJBOOkWmOLVxX0GDlXICXG6vMYxS220WTs4s+q1KdeYtzPY4kt D7Vm1YZjE0nRK0R0ZZLyAkmvTOWoyBfrNqUwI5YvRYuS9sOGWYpse6l6JaA9Y+Rwm5DW1iaqYvuC TzbaF9M32duPzrM3HjYbp+K1Y4/oqeK1nW3A6I6NNV78cTwCHoEoQ6BVkmDoPWRyZcNxokKlifIh QTZJiEWqYFEoyaMASVGSCcm746VijZODBSnbHCFWSYmQIhteqG3kdr8nYL8qi81uXqPd+SYkHRkE 5xYIVfY8rr9CC4sK1WREtYmEx3tHfCqZVbZ+vZWtWeO+i5cHb7K8ftuOGGHJKqvE+1RtKapRmCRn l+pt0JhOxnbYGQPsi88224LPNtnc99fZ9DfX2IBRnWzckT1t2MQuNmxSV0tK8ZlgomwO85fjETgg BFo9CYaiF6N6dqFSYpkcMIo1ORdKMuG1AFKUPQoVapGSeZfIFZ/SOwEZQoCOFCFEOdq4TWEZLjSD 9zjg6ByOIEMTgFe9d58HScHDyf5YlWjaBZ5DasHfkFzwHulOqmJCFHZDdmyqrMFWzntID7ueNqS+ cjZ9HqvfJ2lhkTZggKWoDiKEl6yCvklsstHi4VnX1rF7mh1+9kA7+MS+tnhWf1Vy2Gyz31lvT985 21V2Hzmlmw0/uJuNmtLdOvsK73WF1e/nEYhqBDwJ7uP2Elgdh+pNW9CKFXzNVqJJvEQTepHsVWyF UtsVIzUqPKNcZBCj8AtHgArWd5scbVzgPq8iRFSpMVUboRruO2UtCT5Xxd7/JQcPCDEgTzoT+lno NYSQpyh1T9tTB6F6RYTg74DM+EUo6fE3UhxJwmWrq9DCAJtd8Bq8h/yoxFChAr4EqfMabOUiQqTg RC0QcFbKkCo6WeplyC9R3rnxWjwkSsUM4cUStnKALTElzsYc1sNtB5/Qz5Z/vs1mv73WPn5xpU1/ fY0NHt/Zhk7oKnVpD6cu9c0j4BFovQh4EqznvU+UGpQttJVqki/FriXJplREUCwPxhLIUipUR5i8 lxRZpL/LVAGeLCVtJBHu2fR3DGneQj+XhImU6fYhqwnf8Xewj0iSPKnOmQTioxq6QghirEIFXZUd JynFdsdU3V55wbqwDxpOPTj3VJGby6xCsWIq2pNeTBtpxnjP57yq4q9V8F6vbuO7aq+QIi0gswSk uCqseE0QwcXLyYiCyfFaBPBKcvSmbn2HZ8pJJtPGyT54zKIdNue99TbttdW24NNNIsTVNnBsR5Fh LxFmT6lK/XBo6vvhj+8RCDcE/KhvhDsSL4mPba8mYirDy1ESlNt4T/5KEWaJbGCQJoRZEpCnpEr+ LhNZlmA3E+m4MIEqcnOvoX+HOplAglJNop3cmdzXshJ7WvuyTZZRstGR4u7ykOoapI8LYiD1O2er hCCr4iMdWUKMIZ8hRcZxjRCYiCwOUuM1IDS9h/zisZFKkkOC5jXYmoPs9ncbO3RLNbZhE7vakecM toWfbXSS4dv/XmLzPtxgvYdk2qhDutskqVJ9GaT9oem/9whEDwKeBJvqXkql6NSpeJDW0CAZpCu3 SVIL3jtvyaqtXFIjdklUkY5I9TevfIY0Vo6Ept869tNrTGmhLd/Sz2Zu7WMT28Vbz06lsrmJIJMk TRJoLtKDSJE63XuIU9IYfzvCCl4hMqlm+Qy1Lp+ThMDtWyWhhv4dDiRX19uYkp5gA8d0tH4jM22y CG/F/O324fPLbf7Hm2zZ7K328UsrpS7tYlNPV6J2Odv45hHwCEQ3Ap4EW+j+QkaxbHW1gSG1VcUn QqCBt6l7xYbnHGoq7PMHl1n+f9ZYj28faiNP6ibVqFrgqcl7cm2G5M2ECPk7CF3Y876FcGmu08bG xliXPm3dNuKQbrZpZbZ98oqC72UzfOfJJVKbrrW+QzvY5JP72tgje1lyqvcqba5748/jEWhOBDwJ NifaB3KuqkTRTiW6D1taWZu1svmVWLs+cjSpZrs8kNNH828zOiQbW98RHezES4bb3PfW2fvPrrC5 H22wJXO22quPfGHjj+5lU08d4FSqMbF73IyiGRZ/bR6BVoGAJ8Eou835WYVWVrrbUlKkIvWtXggQ Q9i9X4Z17d3WDj1zoC2ZudXefWqp8y59+cGF7v2oKT3ssDMHyNlGdtBkP3zqBbDf2SMQhgj4URyG N+VAulSUV2rlZRWWkubVdw3FEUmvbfskm3hcbxt9aHdbt2yXffTCSpv3/nr77LVVNk1epWShOez0 AYo97G5p7RQrGucXHQ3F2//OI9CSCHgSbEn0m+DcxcVlmpDbWIKXUhoFXaS9gaM7Wf8RHW3nN0fa jDfW2GevrrI1i3bakllbpB5Ns0PlRDPh2N7WUe+TvO2wUXD3B/EINBcCngSbC+lmOE9ZabmVlVRY clqC0nN6u1VjQo502FH2wJMuHW5HnzfYPv9ooxxpVtjqBTvsuXs/t5cfWiDJsY8dckp/6zWovbXr lNyYp/fH8gh4BJoIAU+CTQRsSxy2UKrQ0pJyS02P9+q5JrwBSIeoStlWLtguyXC1cpYSfL/GPnh2 uctGg91w8LjO1rmnYibjvaq0CW+HP7RH4IAQ8CR4QPCF14+L8sqcJJiSjo3KS4LNcXf6j+xobFnb CpWJZpXNk0fp2sW77J6ff2jd+rW1w88YaKOmdrdu/TMsLaPpM+Q0xzX7c3gEogkBT4JRdDeLCkpE gio71Fbq0DgltPat2RBA/XnCxcPt2POH2Jz3N9jcD9bZ8rnb7D93zLYXH1xgk0/oY+OP6W19hmb6 5N3Ndlf8iTwC+0fAk+D+MYqYPQrzSxUeIRKUZ6iPZWuZ2xYbH+ucZNhWf7HDZr+7zhbN2OIC8d95 epmNVGD+pBP6KnF3J+s3rIOSFHiJvWXulD+rR6ASAU+CUfQkFOaXySYoxxilBvPq0Ja/scQSsmVt LbC5yk/6xbRNrt7hvb/80Prp84MkGQ6f3M2lZyPMwjePgEeg+RHwJNj8mDfZGYsCSVAkGKO0YL6F BwLtOqcoafcgm3JqP1s8Y6stmr7JPhcpPvPXuS4Af8zhPWzE5O6qddjVuiqNm28eAY9A8yHgSbD5 sG7yMxUXllpJcYVzwEhI9Le2yQGv5wm4JwTfsx1ycj8XZzj3gw0KwF9tn6iixTCRYFD0d8hBXep5 dL+7R8Aj0BAE/EzZENTC4Dfl5btt6ewttmVNjrVV3sv0dkm2cYWquleoOoTyjBbmlXgVWxjcp9q6 0FsOMmyoRFco1nDBxxtciMXcD9ZLVdrRhooESew9VnUQqXzhm0fAI9A0CHgSbBpcm/yoFI5AkkCl 1rlXWwXIx1tBtgrfigRnvLnaVi3cbvGJsZIIY2zYpG525FcGOXL0LbwQyOyaamyjpnRT5pkBtmjm FvtU5Zxef3yRzXx7rdK1rXDSIYH4XXrXXJYrvK7I98YjEFkIeBKMrPu1p7cxMW2scw8FYsv2t3l1 tmoDtnEeofy9cVW2rV2yy3mKJogIh4oEVUMpQq+0dXSb5N2DFFzPNkHS4Sp5ln4mj9I5qmix4NNN 9qlStQ3hO5Hh8EldWwco/io9As2AgCfBZgC5qU7Rc3A76z+qoy2RWjQ+4X9xgbyPk6t+RUWcUni1 c1KEFwKb6i40/nG7K7CebYQ8RzeuzLLZb6+zDyURrpLadM57663PsEwbf1Qvd1/RAPjmEfAINBwB T4INx67Ff0nZn27aFihlV0I1D3vUovFK1zVFuSzTvft9i9+rhnSgXcdkYxswqpMddd4Qmy+74fvP LLNZ76y1xVKbvvXvJTbuiB5ysulvXft6r9KGYOx/4xHwJBjBz0CcJL5umvziVMZntyrPh9r8+JvM MQcpaNu3yEaAXKU9BrDgaWsHn9jXls/b5myFCz7dKGeoLPvwuRU2dGJXm3raABsyvpPxXPjmEfAI 1A0BT4J1wyls9+qpigVd+2TY9g25StRcafeDAGNEjAcrM0mHLilh23ffsfohgB24vWIOUYOOPKS7 bVqd45xopr2xWnlLVztVaa9BGa4g8FjFHqZlJPnMQfWD2O/dChHwJBjhN73ngHbWpU+6bZIzTFCt QBxoCQkxdshJ/bxUEOH3t7buYwvsP7KD9R7S3pV3miFPUghxzeKdtuLGafZC52QXi8hCqJMqWSBN +uYR8Ah8GQE/MiL8qejQPdW5zlNNvlIKxA90t6t43lXqM9+iG4E42X0zVefwhK8NsyPOHqhsNJvt o+dX2tI5W+yVhxfaG48vttFTe9jhZw10DjVtM5OiGxB/dR6BeiLgSbCegIXj7j3kScjkRi3BSi9Q OcSc2t8HWYfjzWqqPum+E2Yx7sheCrDvZeuX77IPn11h8z/Z4Mo7TXt9tZMcj/zKYBsm+2Gm1OTE kfrmEWjtCHgSjIIngCTNeAeuVoA8tsD+IzrYANW48611IsBCiOr2F/58guXsHOnshbPfXWvrl2XZ fb/+2Dr1SLNDT+vvwiy6KFep9x5unc+Jv+pKBDwJRsGT0HNoJ+vYs61Lo5YQE2NTzxpsGd4hJgru 7IFfAhqC4y4cakefN9gWfLJREuEaW/H5dnvxgfn2yj++cIH5k0/ua32GZMp2mLbPE6Jq3yYHLEgz Oc2ncjvwu+OPEA4IeBIMh7uwvz4w+6i5f8vKlBpN9j8t93eXl9tu/Z2kKvKdOlcW0u2kFGpDxrSz mPIyaUWr1F0+Un5/CEf997HSEIw5vKfb1i3d5fKULpq52RX//eC5ZTZCWYUmn9LPBisrTU8lWAhN vhCAs219rv3rjzOts2zQZ10+xpJSozxQP2Tc7S4tdQb3NrGx1iZuH9Nm1djc80D5sRf2Y8uTYDPe ovKCAqvQVsZrfr65v4uLK7eSEmOg8cpWnpfnvt9dWGjl+ruSBXe7fSE/96f2Ly8qsqR4keLqzpaQ PMj6Vyy2nHs/tpXpibY7Tqt1BqG22MREi0lOttiUFItNTbWYhARroy0mPr7yle+Tkiq/r9pitF+s PvMtuhDoNbi9sWVvL3QJuxcq2cISBd///VcfWc+ByjAkj1KK//aXSj3UkWbxjM025/11Woy1sQol cD/jstGW1j686yASLlSusca4c2NK4yWhs8ZKx5rNBaU7dtjW55+3og0b/nfTOYZ+a9KytD/8cOt0 8sk1PhBlubm2+d//tsI1a9x4ormxpDHE2EsZNMjaH3ZYzQ+TzlGWlSVcyy0uPX3P76PryQvPq/Ek 2Ej3BeIq1UNctmuXle7c6R7o0uxsR3bu86q/3ffBfvo+IDs3SEV4DAIojmqAbtNgaiOiohEMz/s2 Gozub61IIbPY3WWWktzfOsUnWrulb9uuubNtS6kmKlavVeQZECzHRqJERnS/rSK+GA1WBl9cRobF t2tncWzt21s8f+s1rm1bi01Lc3+7z/mMV+23z5VxI+HrD9P4CGQoG80RZw+yQ88YqGK/m5y6dKEK /7749/n2xmOLnKp09GHdnSNN28xkWzp3mxUWlFpKWqK8ThdZQW6JfeWKcS52MZxaydattu2VV6xk 82YrFTGVMR411kq2b3cLy56XXWY9Lrmkxi6zz6pbbrG8ZcssTotAFpBu3GmsBeOtNhKEbDf961+2 89133VihVYh0K6StYdx1P/30WkkQcl5///2WPXOmJfboYfGZmW5scZxYjcvkXr2s7YQJThL1rXER 8CRYTzwhOAZXEQNMg61Ef5dq4JRs22YMPrdt2eIGHJ8FhBaHFCYicSRT9ZqqFakjH22sFNtASFUb f7sNiS2UBPkbEkQ1U0WCDNKBCpHouDbGOqcNs/bpIlL97UgQlY42R4KSIhlsFUiXEC7vQ/6GkFnN Fq1fb2VffOEmjvKcHCtF+hROcRqArKDdSlpbPK+dOlki7zt0sAS2Ll0soWtXS9QGcfoW/gjEKvH6 qKnd3UbidcIsyEZDerYPnl1u4+RA01n2wmVztlpyip4/FlFSr77/7DIrVCHn8688SJVMmrbCRbHG G1vJpk1ukdl24kRLHTy4RnCLN4rMRXRleuYTGF8s3LRBJize9qXdSOze3QbecINbtDI295Ag407j LGXgwFpvKKTV7xe/sO4i2GBhGIwvFsmpw4bV+lu+L1i92na+954zd3D+siqNT7zGedevftVGPPhg jSTI/sXr1jmCT+rd22l6fKs7Ap4Ea8EK0ijUQ1kstUiRBlWxBh8qEl5L9DfvHdmJOJgUErRygwwg gbTRo/eoXNwArJKiWNXFsbILeXUqSG1tkPiqJLy6376992xIGVZUq04dKzJkELGaddIphMir/oYY y7UhwTqy57q15WrVCukXiyxpibpWyC9BE0mSNiaUPZtWt3yW3K9fQy/P/64ZECD4no30bJAeqtLZ rpLFRktMkeZBhBk0igTjeVosIrzgqgmyJbZvtB6WSC257aWXKscZ448xxyvjUYu0oXfeWSsJJvft a8PvuceNpz1jDy1H1dirTRVK59GGQDgNaYzljiec0JCfuoVwnx/+0LqcfbZboDLe3BhEgyTtUeqQ IU4dW1Njsbr2b3+zXe+/7zBxY65bN0uoGnMQI38f6PzSoAuLgB95Eqy6SUzmBVKBFCxfbgUrV1rh qlVWrMFWrMnerUC1+nQrQU3iSX36WOYRR1hiz55u0kcKcmrCKjWiUyfqbwZFuDfUK4ENEBXM/hpE yaALVLzB+1KRIzgVrl1rRbKJ7PzgAyvS6tSRY9XiAAkRtQ6TVLJW1KyqU2UnATffwguBdp2SbeLx fZwUSJD9k3fMdlJf9YpcZKKZI7ticWGZffWnE2zQ2E6NciFM/kuvusoK9VzFSRPC4onnJp0FprQP 7aZMqfU8PE89v/WtRulHcx0EbQ+SYm3SIovyQCP0pT5JEoyV1giTCmrgYmmhoEvGGxqbzmedZX1/ 9jO3CPDtywi0WhJkhZk7Z47lLVhgBStW7JHyHPHpIUKy44FMP+gg68KkrUHIasrp6oNNqpXWVqMo IEywqN7wVGXViroq2FjBs6go0qKC102ffupWuPw+kBKTtJhIFSGmjRplbceNs/hanBb8AG5+BMhI g6doQV6JBJGaJRGI8As5zTxy02d2rmyEYw7rWWtH86Rmz50713KkRWByrs1RBGmt39VXO/WlG3eo 2jXu4qpsZc2PRMuesVYCVLcg/V6XX25dzjmnctxJikZaLtS8lq9FPZqn2qRANEDsi6mGxWprbK2G BFHp5cya5bbc+fOtCFVnlZoTO1nKgAFulYk6InX4cEuSKgEbVyDd4UXp274RwA7CKp0ttDHQ9kiM WmAgLbL4yFu40HI//9y2a/XKKhWHACa8ZO7FmDGWoQVI+tix3lOuBR+8HZvyXbaZ0uJy5R+trFYS iINOMeqcj9u43KTUO3z8DzMsP7vEZSzCBato3XrL0WIT0stfvNhNuKg08/QMYHPLOOQQJXj48jSE JqXvT37SglceOadGmxPY6UN7zWITjQ02QiTFmhrmnRW/+50VSmuTxqJf4y1j/HhL0/jDH6E1tKgm QQYcnlpZn3xi+UuWVNqzpLLDzoW7cuZxx7mJFn27U2ni8aiVpie8xn30UQsnsMleasK63dSpzga5 R2rUfcldtMhyZsywrI8/tl26X/EvvFDpZKPVadqIEU5iyJR7upcSG/fe7O9oBNZjE6RIMzUqY2Jj RHpytBIXEhLnPKaq4umQGjesyLZ/3jzD1q3MtzPP62grfnudnD3ed2MPL8l03cvO8pIcoIm2/aGH ejvV/m7AAXzvPEv3pwIl7lEL/ALNj8yTznTBQlZjL3XoUOv2ta9ZhpyQorlFHQkSo7PznXeclxWq Fzw3UREg1WFHyJDagJUO+nLUmt6DsWUeb4jRqUSr1KrtjzzSSs8/390rVNLZEKIGZda0aU6K2Pbi i44Q06UyzTz6aGeT5R761nQIwG/dVcfw69dMtvLyCtkEy6yooMxKZP8rLCy3wrxSK8gpluRXpPcl VqzvsA3m7Cy0t/612OILO9mIzt0sY9Ik4/62lZThxl1VyE3T9dwfua4I4Kw26OabnVcrPhHZn33m FqLZGncIEO20UPEkWFc0W2o/3IOlA9/x2mvOKJyPa7/c+pH2cGDpftFF1l4TJl5TzlNMm/eSaqmb te/zMjmyoZpGWuzx9a87z1RUpzveftt2vPmmbXnuOduuV5yPUNl0PuMMyzzqKBd20trss019F1F3 9lCpLgLokfokCFZuStReVlRs2Z/Lnr5mm7U9ZIrFpKa7AHqkxRKpTvNzSlw1k+49R1lSkuyKOD/5 7ClNfcvqfXxMGImS+tjQiHU45hg3fyK5o8ZuK4Fhn82Vrfmfx3C9OxAGP4hYSRA34tx582zrM8+4 yREJAnd/iA+De8djj7UUifM++0IYPGUN6AKD06moteEVmKnB2f+Xv3T23B2vv247kPbfeMN2abWK h27Hk06yzthzpeaOBK/cBkDSIj8J5jd8YmJ2K5xGE+SuDz9wmVGQ0OM7ZFrfo/9t8T2+7CjVIh32 Jz0gBIhNTmAj1GvkyNqPJfJDatymsdhF822KhAwXfxmBhBhRJIj3IW74OzT5bfrPf5weG0N9ojzJ kPg6ydaARydG4H15Ux3QU+J/3CIIcE/ZOmhwkrqqnyT9PC2CtmgRhNpmvQKJNz76qIvRxI4R2A+9 1H/gtwv7bc5sZSH6739dLJpLKSZWRHrIOOIY253kXe8PHOXIOgLOhNs0D6+/917b+Mgjzrsb4aOr TBpocyKJDCOCBAnmLpI32WYNwk2PPeZcgGPlPZYxebLz5uwgqQ9vMp9SKLIGUkN7i9caG3YmbBao bra/+qptlaoU1eniH/zAZc7o8Y1vuDyPhGL41G4NRduco9IX3/mOC9wmVR6LkK7nnuvU0G7c7Suh dMNP638Zxggg9fEM4BS1XWSYJ8/f7GuusY3//Kf1UIxm51NPdTb8SCDDsCZBVJ4Er2958kmXkw9d Naqxzmeead0vvNCpO/1KP4xHSjN0zdk05FwD4XVTuqo8xaAxEHdKYlmmQblWmUN6XHqp80jk2fEa gvrfFOI4O8gZCZt6j29+06m+/LirP45R9QupPdMUSjbwt791oSwQ4eannrJchaAt+v73rVAxwQP0 XSR42ocnCWp1kS+X+Q2S+jZpQiOvXpqMth21wuh+8cUuniyc2tKlS22LMsuUViWsJm4qXemX+vfv b5nVsrBsVWaaVQocH64HiH1CW4muc7FWVPwuLcS1OUsr8OVaDORoERCnSb+bJv0Bch4JDV5eJs+u ZKkLe2rCCm3r5Wm5Rh6zQ8BPauM8xQ7NJ05S6ozKmK//Nfo9Ahd2reA4F33pLimq+jHLZXtdqBg/ zj9yX3aDZr5JxJuRZJgtX/dk4z/+4RxqVv7+97bu73+3Xt/+tgso9qnb6ndjyOwzTGm5wo34eK55 voulKaK5jE6KPeyrxU4XwnFCWrayHPE8D9S1dJCdObRVyOtnkeabrrIth36XL5U742qXEkDwrHdS 6AC/TwiJn6MPZTLTMB5D2zZpJ5bIXMNYZgwxtmdLpcy443zVxx379ZE/Q6EW/l/Iua+dHIn4jGsK bVwD+4yW2j82TJJpow1AKmRs7ZJX/kbN23iURgIBgm3YkSCxfbjDr7v7biuQCjTj4IPdKr6bdM1O vA7D9gOp3z6TkRiSoTk7pXKBjpdn1S/lzMEDG7QXFP/2bU3Gt99+u/1EK6jQh5yBc5b06o/pITpE QcQ0CPMWZbWfKScECIwHn4F6kWygF2tBwKCn/UxpkYbJHsq+QWOAXiopiEH8d5EA/ZulldqRUiP2 JtGujhVKhAzOv/71r3aqVBmbZXvlHAzuJyWJhxL2HHmNnXLKKXbaaafZAw88EIZ3xJw38CCRX0/h t/GJJ2z7yy/b8muvdXat3ldc4SQbF7fom0OA0KJkPRM1qa/CjfyCW/Z73d9HZQdmURiMu3jFvA2V hugqpVw7LKRs0QyF3BynuGDG3K233uoWk0GDVBhLP/3pT+1rsifTGIvs9740CiwIGacQ0+mai773 ve9ZhiZ+GuOYhe2/5SgUtB0y17APY43xBAlC1lPl8QzRMjdUH3fME5crfIsF7w+VQxSyZK4IXYCu 1Xx4hryhIeL/6jkOFxIMrpvnxIUvaYukFjYkiOpzp7w8SQS7U6t3HBz6K21Sj//7P2fTCeeGZPRN qYm+IZUcDzcrU1ZzDz30kEGQT0lNEKxMg1UkpDRFcYuTZdfc8xBpoDGIAwmvQLkAITVWo9ddd50b 3LkKGXhOtq8//elPbiBzXhrvQwfFJmWCYFDtlNfs/SrRcrAWE26yE84Q28MPP+wGcuiqlBUtA4w2 WCQCsbK9pvCTc9H/qyHtPignlPayDTFphHtD6hvw61+7leoGEfZWJWX+4htft8yzzrU2519pltHJ 4hOVcYMtSR6p7jXWklKUrzJdpaZCEkaH+7U2pH/YU7dqQsXeTqwYLvKRYMfhWhlnLMSukdobkkLa Wik13D+lPYKEGHeMGRrjivYvmVWOki2T34W20HHHGP7LX/5iH330kV2hBdMEaRY411tvveWefcY7 56Qx5kIJlQXnlVde6QjwrrvuspPktUyD1Hopb+7dWtyzAA0dd4wpPqNB6BAipEz/f/SjH+2ZDyB8 FsKcOykC8hLX9jySPQrpMVxaWJAg1RqopYX0R7kT8uB100OQoYcvUhrEMkqB3EGbKHXA4XIguER2 KgiHBzsYuAwGBs/NClL9h1R2EErQQlWcDCgGIvtwvKAdpCw3DJy5sn8FLVSiZCXK4EGKhGwDAmRf Bl9b2XaQUlP3U3IFKfJ5FRiFcI+V8xH9/FS5PyFhrgfJM1IakuFgrew7aFLa8o8Hbe0bH9sL7/e1 Le3GWGp6nKUkVlhy4m69VyLjjETL6JhiHbqmWsfuqZbRIclS9FmatvT2SaqfV3MKqkjBIuhnntTi a+64wzbo+ULlSTal/yVFC/+r4VmGPEI1LYyNE1TJ4Xxpjlj8/fGPf3QkwnhBCmPs3XTTTcZ+SGih 4ycYQywGX5bmgIXnmfI/CNoYxaUixX2g5PCcm+OGjjsWrRDUe1IJ/vnPf3bakqBBrJgrxiphQHXz QnWkkTa/8pWv2L3yvEQrM0hhPyyEWVSjnQm0ROF/h77cQ5LqrxE2hF9QrSMcyj61OAlSbWCNJllU oGQB6S1VAK62kdYYONUbOv6z5b3KgApIEEkMQjtH+nOIigeblWN13T/HgihZQaKSwYYYSlrfkbfe dmXDCR1krA5R3TB4sR2wmg1VCYX2r7pdoia8GfBXSxo/77zz7BmFIkDokCr2xa8rkD0SWwdJAe0n TbDU/zxnm/+1wNbOf161FpWcefAoi+s/1Ap25FqWKq5vWJ5l2TuKXPV1pMPMbqmOFDv1SFcAeYZ1 65fhCLJTjzS9pu1VYijccSHUiDJFq7QIy5adqpMmWhaeHaQurOk5DOfrQSqr3ljksYBj8YZdD1U+ 4wgyQXvxfTluoMb8wx/+sJcUF0qIkNbHypzC+Am1EzIWILJAnckr4w5JEcJFWkRNy7ivqdVl3PE7 1LmQKVIt4xmzA34CSKaR3Kizuk2e3Gj88PvoqXlsXzUam+NaW4wECWzHi4+BiB0QMHpLdYjHUbQ0 VopISxAdq8TAfsd7Vpgffvih3am6aNjoWJlWb0heqEUYzBAh5MlqlNd+UvOxBQ3CRAL8nZLhYoeA dI8//vhaB2LgxBM6KBnQ1Ve3hyoEgT5AqKhiPpG7PMdnoonURnaTPt+42M4b+q6tEf6bXn9J9uZx 1nnc5db22FOUCqzIcncUigSrtm2FtmtbgWXpdd3SnTbjDSVfLyq3rn3SlU2lvVKLtbVeeu2lOnx9 hnWQKrXFhtV+bwnJyzc9/riTAKXXs76abPuIFMLN2Wy/F7KfHXDYwhTAFtizIUI0Gt/97nftDl0/ 7wN1ZejhUG9it8cmiDMLklcw7nC6wXEsaOzLuEDy+628IZHUkEJraoyvuo471LiYUhhrnO/ZZ591 C9IeYeYUWN/7xPw+WIuPtRp3q267zYVWoIYnj2xLtRYZraQ0YyWwSismMroMlt2ru1Zu0ZjHE7Lg 4WegBCTIQOD9z3/+c7fau/HGG53KE3VJaEMSY0XIwGO/V5QWDjsBgxoDPtJYcEx+y3fY9Bi0qFFX qJRKda819kdNeqFCTDh+dRL8hR7I6tIjq0/sgqhvUc/UNHG01AN8IOdNmXKUDeg/zBLv/Zut/evd tu2Gn1n75BLrf/7/t3ce8HWW1R8/TZvRpEmb7pHuQWlLWWXvaQEBQQSRoYLgQAQVFRkiQ3GAqCjT AQIyZO89yiyjdO+dNN0rHWma0f/5Ps3T/9vLvelNcvc9p5/3kzT3vc/7vOcZv7Oec7YHRwRp84at mhNziwPCVUs2yrLFVS5ZNBrjtPFa7FXzZvYf3lkG7tFVhu3dXUYcoKa3GBaZbc17Br9L5RQiZfHJ DNFAoR5qkkqXKL7m8IA1gkDHuvPEumPOX6xV51/VkH4ERsANM2koYWnBj/+aximw9p5TSxWCJhoe mqR3YWCdeUuTNSzRBAL4GomaJggn6OunbZ6Ln55no9GFrjs0V+939335jkbDP68aO+BKUM1ZLSz2 2xy+xfveHOUDgY4UMFisPtMKnYvkCh5yww3SLcRPG+++7BBkEvUg/xwCYJBC5+uGWqghwEMUAGBK phKh2SzGYHQlJifMOGhyV2vQBiDzqGbAYYGFRnyxyL6lwUFc+AWm6mHwVzRVEVIqZhgfGON9FJhO cK7jj8D3gV8hGNLNc2kTbTLUuU6/QsPHGRekTzaFG2+8MS2CYZozl0joPPDqayS/X3+Zq5vNlB9e JsM2bXHnDoOmwUINkuHq2V814DHbo0o3rN0iqyo3CeWGlsxbJ7M+Wy6fvVEu7z4zT4aO7ia779fD FaUdeWDqpBRDEh+qa45gM0zDmUqsO4TPoMWC8cQ8imZ17bXXOq2N9YGGFbru0PDwy3ERZc26A+x8 NLQPjGHdAa5obawpzKWA6381Ijno6+c+1tveWi8z+Hf4T7/CaXjsGUSKAobsEV7gzYQxo2zTMMUA sg7NV81wtlquSNlG4pNEU8I1wXKddAtU8yNZ626qDpN1IlOJic/iwQEfquV5nwK+QaRN/Ak47Vko fvPl/OHdd9/twIcFgE+Di2MURKIiJXoQxNSDifXoxvBktEwWN2HhZ5999g4Wcx8LjjabQ5iXOGJB 1GimEQfoSdZN2ZnZqgnPueoqaaf87hngW7h3JkiGa+DILjLm2H4ODJctqpK5k1bKRy8tkBf+NU0+ fn2R7HFwHzn0lMEOFJNNWFt6Nx4DSHZf4vn8yVqnkvkaCjj+mWhtrCF83ASJsb78uuPML/5C/Ies FXz7XAiWgCrrDosJEaWAKpYTwBIgBVxplyhSjmN4cCVylf7wuT9eEc37c26X84npFIQWzXtxD9YI CicTDFn18cdJK+qbUBBcqmdpFqLB6GZPpF4mAWC4MzuAGAElkXwETATA8VdqliIiDM0Ns4rX3ABR zKT45QC+ILGQADRPgGpQi0NzRGPESc9RDBaxlzrRBlm8u4oODT6PReyl3lQ7nxTtomvyPpXGOUaB r3qWbn5zVKPOU426s/pro6UuBM/ohea33/H9XZHZNx6Z6a5pH1bKwScPki+dN0I6dtZEw0Yx4UC4 avcEjBGRja89kvaEpgfIEfyCQMi5WG8ZYf1xNhZLDZpY6Lpjzfrnsu5IiOHXBEcvMFt6Xz/HK/y6 Y/0QuNYcEETL9OsuJgxLsUZIf9hftdwaFTwoZJ4MShgIkoAXMyibzGA1F7jzSBlEZJwYrzW4/DlB NEDO9XDAlqjKIFiFRojht0NzI1oUM44/d0TGCHx/fIYfj+AZ2gfcCJRB0/NEmwCVJxY0ZhmkV34i 8dIui9cfvQh3ThDJM5xJlOdGG9mWtsPaCIScnUMbXKSWCnKQYrZvLvXW6FGu3fbtLpPfq5Rn75ks z949xQHjmZfv47RHo9ZxgLnMuUASVfhzgvjBSTbBoXOCW4JgFTp/0cxYQ5j6K9VX6oVPtEfO2BJB SrAZmh5aH0Fh+N3xxXvQC113PA9TKUFvaH3eLMrfETzpK4Ju6DlBfPnhTKKsu3ARsK3jXGp9m9SH yQJAOJEQEMQPSIb/9aryDlNth9IbmUQADpOdwBWICY6WxeIhsCWcDyD0/dEWCa9mAfsFwqJkQeEb eEgj+jh8y2LinBE+ArRHT2wCoeHtnJ8CQG9QpzMZJpBQ6RfZK/AzhGaMYcERjRZ6kNhLsukWPt+S OcaCLFPebFYtfrGaojupJk9uxJYmZ+f4xNFnavaavbrJU3dOko9fXuiOXXzr2gNk2D7JN4+2hEep 8h3m8uOPPy5kMPLrDi0NvxvmzGD0dLj1wXdwFyBokpQiCDasL4APSw7CLESgDH7E4PGgcO3i/sA3 z4F9LDmYRekXmWUQdFnX4TLGEHATSrQfTttNlTHIhH4kBATXqVREuipqvnEIPtOyzuNcJxQ7eFaQ BYpkF5oflOMG+O5CTYpEjxFmjWSKBujJO/Exb5IthkWB+QX/YXBxcIQhGADjv080GqHgPocp5hk2 DZ9vMXQSBzeO4GdEnBIhRz8zndqqf6ivagfUy1uiZjXOz5VoFGFrqO+wUrnw1wdJabf28trDs+S+ m8bLJX883BWtjQdReYWKGjrRpFiFoVRNfdaad8eNgBbnjx3QFgIpIBQqeB6hZ5ARBEPXI9YR1hzr kjXlifs4v0vEJloloIVVh3t89hnu5ShSuDPCuC9InuFdDgiuZJFh3YXm7KWdSEcfsBIhXAcP9reG Z/bdL3Ig7iBI8utVGl5P+aMy3cjJSJ9pxMIILqCm3g8wCk2q7e/HPOPzjwbbYGETENMURcpCAWgF nepIpC1Jes1iDj1ukWnjGHwfMlr00Ei/2bpBrtUCviXkf21lwVAy0Zz5431V49gmbz42W576+yS5 6DcHS3777Sm9YkkbNJvQJLUuuEw5quUUq3aUaYRmFpooO9I7AmqhAOjvJdiFZBShBEBGEgr9vZGe j5BLUglPtIWrobnE+vWpDJv7Xbs/Og7EHQQ3aQ5Nip6WajRWx8ak0NF1ze4yDiSRAxwX0WQDJRog sVIl8e5Un2jM79iaXuW319D7S/eWyvnrZeK4Cpk+frnsfWTsBcNatUxs1nSEHfff353JMjIOpAsH yGhE4eataj6mWC81LONJcQfBDQqC61UqHaYhxJmoBcZzcKzt5HKgWLXBYjWDLtXK2Vt8lYUYdKlD p3w54fwRcu+178u4p+fKHof0lna5OTFoeXsTbCIbNC8ohU8pK8XRDyPjQLpwoEaTCszSxP2suRGa VKUkTDatWL5LfEFQ7egUV8xR04DVcIvlsFlbieIAhXjrNUy9WqNzSwOleVr7/JEH9dYCFoUyb+IK 2aCZaEp7bC+JFQsiSz/+wPZ6LAZ/oJFxIJ04kKtuIcrmrVILDBphWoNgvebIJDM9L5QbUlw2nQbF +pq9HMhvnLvkt0XDilVQV25+jvToVyyzVmyWFeUbYgqCRGNz7qqdaoC5cTYlZe/MsDePFwfaatwC VsNaxQ8EunhTXDXBbRz01Ggo8sWRlSNdiEoPZJwgDVI6hCeTr5B8hP5AfLrwOR36ydylYj3zmDOu sQJBahYVaRo2Ym02aV7SWBL9bNAzaZRFov/pQhxRoHg0R3tCMyyl4jtwJpHIVF+zMBX7mK59Aggb tPNgSLwpriCYoz4Jws1JmN0QyG4S75dqbfvlWvOKs0OASyocCaDKNQd1qSodjjiTRHkXn8+wte9v 3/9/DmDNYO7iV4sZAGrzbXLayEbNPdqgkaIdOsU2gwxnGrG+OAFUz6SlC5EBiXVHMohUiESm2guJ 40kaH+74ESkNyU5DlRij2HKAddeWdZIAIS7uIJivCYq3anHYWr3ShdD+Yi2JLtYSNhzs9cRZIwCW wru7kiTJ8EKGmEggSDvhFmlT/Oas0qxZs1yRXM5BccTCF87le2S34DMy4RDeDcgGi3mSVJhzV6Sl 4uyhTw8VfCbfpxQNfSOFVfCYB89ksyNTB3/nHFekEPZkzhsi1GrVJENGi5YemA/X/5rqOlmmZtB8 LbuEWTSW1I7zbFouSM0YkhcoHBvLZ8SjLc7ABlOSxeIZrB1SqHni6ALPIF9ouDkbfCZn+kiaTZHe cOuLNdzcdUcGGgpVM/897a8RvKRGhADd6RpM6InjUawLcpP6PYl1RaUKjlOxZoOlnRDgSbpB5ine kf3FE+cZ+Yx0jqxpMlAFC27Hgt+xaAOlieK7eWrKz9W5HG+KKwjS+fa6wSFBb9YKCM6cpJMwHSjW 2VHIGcjE9cQknTRpkssXuisQJGk1NQUjERM63AHcpvhMWjdqqiF9k6GGxUGlerLhU4Xifo2IJK8i Jio+J8m3P+gPb/z7cPCexURGmyCRKYM2+S4XFTAoCQNoAny3aEoyEhXzGenmMCuF5kdN9jxBk9qs Ji98a7EO7PrszXKXOWafo/pJsUaLxpLoL8c70pFive5wbQTXHcId647E87sCQQ7ck6UpEjUXAGmH Z5OSLVh0N3gQnjRwwf6SLpG1duKJJzoQZE2yZwCM7CFTNAqYZN4c5F+oR2JYV4AcwEiKNvYFXxqN pN4AMK4T1hvlpEimQdupRNUqYG9QPnHGNREnCuIOgpRu6ahaxFrNGrNFtaFYbyatGTzy+7G5szA4 yErqsmDCXQ8sfP6IJv/GPIrUxt/RnCJVbQ/XJw6oP/zwwzs+AiCQ+o6JIocqoMGEJWsMhBRJf5js 9IFsNcEsFtHwBImYlFFUseC7+DeoacbBelJDcQiYjBm+2C+gSPkmcpGy+MmGwfvcqSHM48aN2+mR mG55NxY7Gh6E1gfBSwCTPKceONEqyaeYarRB/cJVCvKccSXSMlZE+aWX/zNN6usa5PDTBqdVVfpY 8AAgePbZZ10OWw6jU9syXL5aBDBydQIKHGYnyQRzFfNktATABNcdwh8ZnppKau/bphYh64z14KvH U/IMYREtiznbXHcJQifaWbBPwXch1RqXJwRHeESeX0DPJwYnHSKWHFwhL2mldirF0FcES9Yqguwb b7zh0r5xaB/e3XHHHa5ajS+2TWo5QD7VQJCK8+t1jpRpFp/2LcjbG+3c8PfFHQQL9bBjZy3vQ/WI tbpZpgoIkqOTzRsJCqkIUyUTFMnIpzTzpVKoIUb5FDZ+pCt8AZdffrkDoHvvvVc+1pyo4QhzBVJb aHANkt0LL7wg/fTwdTSZZpAGyXQPCLIQAB7MNAArYMp7+I0B7Q6wDkc8i1RTEJtKMEsGqdrYMHwK KsAxSDwrNNeoB7XQ92PjAkTZvFiYFBgFYCGkVQQPUseRxZ820TCpdJFqtEqBe6Pysq9uStQdjAVx HOJ/f5kg87Tc0jFfH645Rf+/Snks2k/1NhCGmB8+rRnCEnOaag1eAGVOYCFg7rChI5gxp8nPC4Aw 159++mm3hsIRwMS6C63WgFbIOuY50ZQEo1+ADKnT0FDpC9Ul2AeY2wC5n9fsJ7gswhEZaajm4t0W FLzG4oIwTRAQay1cpiiEXFKt4SfF2oP/ce7cuS4XMAS4IaTSHiDI2mJNA4AQAjYghxBNOSaeEdRe yQIVqdRUsuYRyetX6NhiPeykJmKKrseb4g6COObJGbpMJahyEhLrixVqPrxkE9WkmYhMQojJhebC hPdVHFiMmPFYOEw8fGJIf0x2P5mQsCKlLANgwxGVqllg0Zr/AGM/WTE/8n20Mvx0LBRAxVeQYKJH 6k9TKaYAT94F7TCUqIhNXlMEhGg0Tu7HrENfkPDZOMh7SoJgFj4mHAIf6CcaKBsWgEg0bqrQejXR LlONtUR53Fm12Vjk3ly6oEqeuXuSvPPkHBl9aB855eI9pG272B2STxXeNdUP1gTA4a0oWDXYwMeO HbvDPMn6Q0t84IEHHDiS0J378JV5vxjAEmmeM0fDlfti3nGR7zMaQrhjTaAF4msDvPkufjhKLyEQ e6GR94rUH8DGm3nZb27WYrIE3bBm2UtmzpzpEmsP0DOpQULYBsh81Df3s28AaJ4AVvyMEIIsrgX6 isDLvkC0LRo1/CCZPxVl/va3vwkCAd/1gBoNPxJxzxpNUbhEBYqemnu1q/piE0FxB0FeoqNubr10 olNNnqK6Q1QboZBiMomJzKTGJIDZg4XHAmGTDmo2ZH7HoeyDQkh0ixPb1/JDigvVmpp6L8yBmAuZ 8KGTPhp+UAECAAYAISRawINJDWG6aS4hLeJroMp96ELGVElJGJ5DFYpojoywMcAvEhPDV7RWfmfz g79sCmi1OOXhI2ZXJOlUAUHOti7WjWKTAvTuf/1rTIS2z9+u0CK7U7WsUoWmSesr5/5yf6HCRLYR Y471gvHHjA+oETwVTELNHMNawtrzpjpAhgAVNnmI4tG+gHQ0PARAWHdoh2hyzSEABKBhn2DfgBCi +Z13gNBOozHT4qvDiuQJIRBwQrMN/h0hEgGX9ewFbl9RAlALCqMe8DEro/XxHYDS1zn030eg52+Y ctmHAF+e35Jcws3hX3PupeJ8fxV8EDzzAmDfnDaae29CQJCzSlTuXqcbbYWCIC/aWxdBLKTr5r6w vx/NBpMGpjqczCwSpKbQjPBs4kw+L03xfQDHZ4fHzPGmSi/hCLMEASJBqdRLagBOSyicJgaQeHAC bIKO9eAzSMSLP8QT0W840rkfMyklaIKECYq/I71eoWmMwvk/wpWSYaGzQXmNGj8qPKOf/I32+Bvk k4PD+1QgjkNUaADBUtVee37tDOn99TOdaaZqdbWsqNgoZUM7SUFh9GdeK+ask3eemC0fvrRQ1q7c LCdduIec+C2tFt4nsQCIhE1QWmmjjzZZvMbEifCJIAmwMR8w+QUrQdA35jOfATzerMnG7TUqfGOh wVj+nZhTlD8KJqoHUNDcKJHUEmINc7Fm/DpAm/P9wZKCxSgcYcWhP+EizrGIIAwj3AaJIBbWSDBo judiWUEwxRTqi/R68ycCLMek0C5ZbwicmFAJhGF/g2e069c5bh5cK5GizlvCp9Z+p4PuDbuplWub msMTRQkBQV4GB+cANSXMUJPYXLWzk0Gmu/qFkkX48QAyvyiYEGzSTOpgAVlMEZhe8AdccMEFzv6O LwLTKYS5IlKFB9oPak5MTLQifG/hstbTF/xjoRpRsD9oZPQRxzpmJHwqSNZeKkZyRtILR0HzLGcP 0YJZUNRSC41Qxc+IyZWjDfQrUiSc51fweTjekbp5R4AXvykLnc0Jnuyp+ThZjNQ05AgG96ZCqDbR y5X33ycLb/mjdNpnbxl2zZVS076zvHP/dPnktYXSoSRfvvmrA6MCwXlTVslHLy2QqR9UyuKZa6Vs WCc568f7yH7H9ZeCouhBNBbrY6MG+MxTn3KtmhR3Vw239JBDYtFsi9ogCQVgRvAHmzrAganTgwkb O4Iomz1zh2LQaEreJ+jnCWuEzT0cAZ7BADcAlvnM/EPoDSWCTwCGcGDgq7qzZgEb5jJuFIRZwBzr CIR5N1I5JJ7rhVc0PEojUWibfYWgFoJ1fNAbbREDQPANptcgcOJeQICEJ6xN9iK0aNwUEPsAQI1l Cp6ybo/SoC7AESEenhCURBto2ggGqeYT5D04X55IShgI8lJUkx+kAztHzWskSCVdRvcIB8DjzQQm DmZAHMtMRqJD2eiDIdpIT2zeAB5AgRblK6/7+1iU0W7gTFgmHv6vUMKOz2KIVOfP34/pgqKeaHBo s0zoYGRdtBGrLGJqEAKM8MKbdwkEIAKUIxmAPecbiTBjY2ITAHxZTHwffw3+PzY1pFY2Bxb3CfiA 1aQI31hsaIZovl4oAOjRoJFM4TGgSch6MomUaJX/+qfMu+5XUljWS7pc8nN5e2KRfPzbl6Vy3lo9 zrBF+qoW2KARnZFozfLNMundJTLx7XJZPHutrKrcKF16FMk5V+4v+x7bV3qUJccFUKD+oVLVvBbp fEEIHY7/V4WbZNCZWp4KwYtAKDZ41h8gEVx3zDUAjmK0ABQ+ZQARjdALlayDaM14gAraEUJsqDkf Myd+9qYCZZijPoaAADUfrMO68xHkvIePpG6Kr1idWDMEhrFu2Hs4AxgskI2Gyz7j4xV8e3yX+olo e7gb2K+IcgXoINYXGilHJugbf8c0irABmF911VVuz6NwNoTgG61/NBlzJVHPTCgIYo7ppYNCbsP5 ugnOVGcwh+h7a/RTotOqMUEIPWZCIqURqYlNHmmLiY2NHomSRYPtHzAkuAPJiUCOlpwRYtEiwYWL CCXyDZ8HWlIosRiQOiH6yoIhYo7gASRUX32+OZPmENUGMIPyrh4A+b6vXUY/cZoDyt5EzGLypiDM Mb6QL9InWi48hNjUAEOegcmIgJxgXTYc+DjoMQHxPpiEQiP5mvMurb23YWOVM9MvvOVW2VLSVxbs daG88LxWAq+YIJvXbNK0aTnuUDvpzepqt4PgtoZtypcGwdw542PNev/Zclmi5ZE2rdsqmzdulbIh pXLOz/eTPQ8rkx79i3UeaX60JBGlaAaq8Nmg4LJYfZwzVUMYonO4uwacJJrwZROmj3DF2mLOoLF4 kx7rzp+bQ9v7q/aXec78QGhiDTaX0IQQYsOtO56HxSJcQBh+NX+ujr5y3AdtDysKn7EWogkUC/aX 7+EDJ5ITcGU/YT0E9xN85wia4dYEVicEVIRmQI/16tck/EK4xJeKEMG9rEWI/mMlYt3Sf9Ys72LF ekUSCoJuMHTilHEMQQcZE81slVo2qYN2gGqGeQpAiaTQ4JRg5oVgIUscygAGUuxTTz3lnOQtCeJg Ukfa7NHumPjhTDxIzME0UkzgXR2w3xUfWXxNmUJ2FUKOBhnMIBP6PBZoqCQbvIcFGMl8tKu+x+7z bVIzf67M+8MtsuD5d2V24bFS0e1oqZpbLDWb10ibbRqAULB9iSAsbFYQnPL+Epn03hKZ8/kKqZi3 Tjavr5WtNfVSt1W1F01/hsa333EDZODILvp/zTuaRPAL8qktRZHVAkNORoJ+0Ag36zmzMs0sw+H6 RBIbb6TNN7juOPOGBse6w2SOSbQlgV+sq0jFcdHIWE/hIrkRgkML2vL/1ha5RUsLdy7Sj8Gujk1F Wjv0l32iqZRzu/o8UfOgSmMA1mqMSJlq58kOkkw4CDogVDW+t0o7eaohzFNto0JDgal/NkS1g47U jmplBe9YDyTAhfMeCRaTBGa/YDqiWDwvCMCxaM/a2AUHarfIyrfekym/v1MmLiyS+SVqEm7fVWpr cqVN3VZxJxfa/P/xBWeu04zUT94x2f25od5lJXMpz4bv11NGHdRL+u2m4fQaNJNXkJpZkRA80QhJ Zbjw1ltlkZrOSlR7IBIvFQnwwnTKWmODx7oAaMWSmgKjWD7H2trOgQa1GC1T8/Y81VixjRSpZtpV j8ckk5ICgrwwptFu6nsiNc5c1QipHTVFQ3wHaiaEHmojJ/9hqhCmGswMRKphtsCOH81RgVTpv/Vj Zw5UL18pU+9/UV55YKosrD5M6go7yrbc9pKzrUHabtOs9RGO7qEN9uhXoibO3jJoZFfpu1upFJfm a0HctmmT9QUBtOyii1yEdpUKnkXqF0pVQuAk2hmhE22NdecjjlO1z9av8Bwg6IyanAvUzbJCrWk5 apnoq/OwUwokyUgaCHpWFardeqT6Y/DJlGvk1SwFweWa326ABo90TKGq2EilwYgzm+zpx4E6jZhb 8+YbMuHPD8mHywZKVY+9pKBbkZo+t0r1hhqp1YoObdu1UUDLcVpeMFgDAOTfmGP6ygl6xCGWleAT zknVajtpNCNXqhM+Le/XSvW+Wv/Cc4BK8cs1uK5czfA1GjDHMQgCJJ0GmAJWv6SDIGzDTNNfncUd VSqAUWvUDzBRM7cQMFOmUYNFKrXGsoyNTdbs4gCBWBs1NLxcz0QhYBV16ypfO75MOpwxSlZLN1kw dZUsmrlG1mmB2y2ba9X3VysbtMxRrfr52rb1oNjGnWutaix/JIk95ZDwAUNy50qnUkwJZ5I9MCoO VKhys1CDeShQTTxIP/VHFzQG0UXVQJxvSgkQ9O/YSc/woP0t0zyelVqjq1LP5q3Q/HxlGhbcXcPu C9V0Y4syzjMig5qvU/P1Jk21tVwjAJlPHMDlmE6Znk8klR80QK99jypzvxP4snjWGgXEte5s38ol G2TT+hrZqBdHJDau04P0s9cJZZBS1e8Xi+GjkOlK8qaq4MARJvw2iY7ejsV7WBupwQFyR2OF6aZZ dfg91SilQBDmoPH10rMvbFaA4Eo9TLtAw7krNAN6H80y00XDfIs17RHao5FxIBwHOBS+QQ8bk4h3 qR490dBOKVHhiuQMWBcokBuOCrXS+/AxPd0FUeVhydz1Uq5n/hbNXC1LF1VJxy7tnVk0kwnNebVW LSnX82RL9FgC2Z666lnODnrEJ0ejS42MA83hAGdUuVKVUg4EPaPIG8exiZ6akWG5Fm8loz8qNX5D 8pBSL40yTRwENjIOOE1O8yBu1GAPBCfmDAJVqfq9uqrg1EMT8uZqaHpziOTW/YaXuuuQUwa5r1Zp FYgiBctMJo5TIIgiLKzVdGtz9cA6Jq1eGrjGZlas2VXyGysVZDIf7N12zQFqblZpEhB8e1jy0pFS FgQ9MwG5/nqIvacC30qV7FephIqGWK6pg8h60U3NWiV6rKJYD+FyBtEouzhQr4enqfm3XtPgrdQI 43VadRuw66qmF7LQd9fEAu00qjBWVNI5sSmdYtXv5rRD5DZRe1xo1Cs1Nd8y1ahnaQL8fA1UGaX5 cHs1pgtrTrt2b+ZwgNqwrLu1mrqNCkEFevZzbw1+ydOf6UYpD4Keofl6phDfYA8NmFmtOfLW6eFZ 6hNOVycrPgs0QyQRTDZcyUzOnW6TIO36W63mzqkzpWrqDDcPVukmTdRZR03dhsBEbkx8D2Yyb/3I IlxyAYgcY6rVNHhmfWk9X9Oxha2ajJs8tOv1zDRF0rES1Gu+5U6aOhKhk4xE6UhpA4KeuSTe7qkZ JLiqdDDWaWb4NVpfj9pvFaodFmvaMTZD6sBhtinWcFyLLE3Hqblzn+urN6tWMkkqJi6WJXNWScEn z0rbqeMkp7Sb+o+PVrPn4dJR8yliIjeKPQc664F1rgYNmtFElOEfQAo+TYVXq+WFnCCqGqVR5nAA AJyu+YLXa7BZsVroUEhwN6B8FKXxuks7EAxOKcygXD31cD126fWa2oxUPJhLAcQOCoglegGEHTQh bQcNqElUjarMmfrJe5MaLWBMJqGNmlh846SJsm7ydHm9fKgsyB0lvfJGyECNFh5zzqEy8oKx0qYw Ocmpk8ed5Dw5R3O9RiI0gQqtxrJKi7kWs94UCJ0mqT+b649NztvZU5viQL6mOixVi0Bvzf+M9lei SgZ5adOd0hoEPfNJv0bIOxdZCTZrlfgq9WWsVQ1xhQZIVGotL6rZF2jCbA7ns0DRGAHHRJftSPcJ E8/+16uprUrD8rk2aYklxrFaS88wpvldu0jHI46Uw755vhQv7ihTP14pS9T6Uj6+k0xaN1OG761l Zg7p7fJ1GiWHA7ggSMmGprhES2W10ew0hZoRqlCTz7fXtddZk9ZzQNrWXHLGJ9JT0d7ZL6vUr04C ha7HHRf2VtxOwzRzVm6Cit0miksZAYJBZrHYuLroQOK8r9Zs7WgTBE6sV9Mpod/tNBdoe+rbaXb5 Qs3gTuooBpifAKpRYjiwRTPhb9Tk6Zv12qQlpgA8FmS15oskxyDjgW8PqRMzZ/sB/Z0mv/eqGi1v tF6mfbRMxr+6QF58d558olXaSWM2dO/usu/RfWXQqMQmY08Mx1L7Ka5KjJbJAuwYSzZWt+607Fbl c89JvZ7b5KyYUfI4wFnZzVoQgKIFG9WsuVnXHeuwWgNdNurfB2iMBcfTIsVUZBoAMhIZB4LB6UVW Aq5S9WVsVUDcqlnpMbFhOsWXyOIkqAI/IxUsMNkAguQzxXzKJgygxjK6MHnTP7lPxk/EEQY0PA6w 83uNjketVuTYqqVd6tavlzwNu++kfj0yy5NaiTD8PNUsckPyyHbu0U46a52+3cb0kENOHSSLZqyR j19ZKBPfWSLTxi+V8fp7v2GlmuOzjwJiP9MOEzj0VKRoh1CpF8FqrLmtWtqHDZexbMo/v0TdGDl6 rAUzKpabSOc5E/g6GfcooqkXqDaH24h1h2BCwfOO6tcjk0tnADAFUpklkvEZDYJBRgJyXIAb2gWR TmzMaIo4fNEWN2CKU7/iGj1qga0b8GMh5ik4MlG40BydaVU1Scte88WpWq/1A51JWkGOn9X8VB7D azK4AHZkj2jQlFxFappGyytSwMNvhGbuBBFKakWxEHPz2krZ4E7uGnVQb1lZsVGmfLBE3n9uvqvq PkMB8fWHZypY9pQDju8vQ/bqHk2ziVx/Gf0sAA8/EhdBak0RGzJ+fOYK6bXa6trL05+FWHZ0zXXS YLfiffbJaH615uWoy8pa26hCZr4eUyBCOqzZWbV19q5SHRt8eriGONawY921phNp+t2sAcHg+LjF qVIpF2Y2TKdISEhFW1UzQVsBEDcoOGI64GeOhuK31TNSZMxgchF+j9bIxl3AQteJ5H7qxZmZHAXP HRJVFBt6ys8fjfwj8wqJpPHdbamsdFr1Fr38TxcZiHSpQMghWjKPYNakajtaACZnsv100GAJtG00 vHZaKYB6Yq2NJOzYpUCzuRTIgBGd5bBTB8vCaavlw5cWaqX3CinXwrefvLpQ+ihYohnue2w/6dTV Mp+k0pzjjC9VBdapdQZTHf5gziiuVb8ia62v1j2MBILML7RNDvm7ueTXWyasuzCDxLpa+8YbslbP xNboOmTd1SkI1uuaw7KCyRltmjOdodROeUQSEvy2jldkis9yykoQDB1zIt5y1CSKWRTzKRJSd80w 0tC4mTtTni5KZ0vnp9rRN6vPg7+hDbKBA6zBn+20LUAWrcb9rr4stEsncenvzgSrv7fRxe8Wrb+0 czsmZuPfvmCeiGZxA1o7SH93Ye2AGHXxtoMZPx01/h/AcuZJvWobNWX+X6O/s8jYaMgIjzbnEyyz Abnf+anh84AamrILiNACpO6nSvL4YZ3w0ChExGvdUd2hq/oHuUYc2EtWL9skk8ahHc6TGZ8sl3mT V8lL90+TkQf2lgNPGCCD9+qm5bEslD9e4xFtu8wb/ImE3TvhSc+feTMqPqti6oxGIEBgpp4P3aRR xHmNQmgulh9dX/iwyEfcUS0OYYm5z9zVn27dBQC0RWC607pjMVM1LwzpfRw3Yc3Ub9rkLCVow279 6TpDmMa3Gu6s6zatSM+xsCUPPuj2Dvqfq3sLQX8kECnV+pAIBGFJ74fXRv/PAQPBCLOBzZoLQstD smKyNegEdBNXF2mt+juqdYGyCJ02pD/dxe8a3MEVXFSuMZ2EwWUBMGB2zVFplwnP5HXaEb4V/R2Q 5Hf/HQe6SHgsWgVetFMtdaCJLuvd5gEgOVxTqZC+Qg2KdXU1uuDYXKpUYty4QeqqVPNVkGcBuks1 YX+/+35wMQfAkv4jQbbXc0Jowflowvyui5a/senQR9fPRgEhWQuOXKBcfQZ1kiPPGCrzJq2SD19c IFM/rJQPnp+vvsMF0mtARznoxIGy5xEa/t29SPLyDRCTMl6sC53HTptr3MCZXyVqAmW9udpWEQir A+uoXu/DBO/XnauCoX8nYXokEGStLtbKNZtnzRKAk7nt1p0+r60KbkSQdyHpc5jns34ItsP074VY BGfXXyXOzuF6Cec2wXy54He/c9lWvJ/UiaSAo65bsh111ILH4UCQd+qqtVgpKIC5GMBE2Ga9uXWn Qn1rLStJmQNJeqiBYDMY70BHLwjNhiw2BHA4TQptSLUtB0J6McnJYuKCPlTKq2n86SQ91ayctqUX C5h7Re/ZAT5oba5+3fZFsUNj8//3fQ7e48E1KHm6v22TNW26yczc/aRE1svoho+kAUjV8uihGijv xEbgtNRGbRXN1Wux/I1gFRcohPYbuJrBxoTfmqPlkDp0zJc9D+8jI7UC/Nrlm+XT1xfJJ3otXVgl j972mTxz9yQZfViZHHTCQBk4qosUleSnTaHchDM0wQ/cVQULLA6jNNE3GhLrDU2K9UVQDi4OLDsR AVRBCwvPOo1idUJvo1WEdcz85kwcGlk4fQ7tbYlWJyG4LjSIh72ghyZsd4mjFZhCyWmdjcCKhchr raw3tLqmigRgOkbjo19GreeAgWDrebhdu8McGmiLRfGF9FJBM6RfbGiUaGFoZV4z0//XNWpoaHRo al4zc5qo/o1nopmikQK6WnLbaYVOAkRLxPSIRKhrre2qfHnq6fbSr3cbOf3iMyS3BE2z2GmfSL1U eSaqz2luAdPsjt9jwaMUaQNzabeyDq4w7rFnD5fZn69wQTQzP10uE94slw9fmC+9VHM87JTBMvpQ NUn10GLKJZmdMDtFhqbF3XAaJACmF4IcoBgt4f4YetNNTkjFUuLWHfEBuq4AVc4TR/KbIQx2UY2t oH//7RqbrjtiBpxmp7/Tj0gAjpY56NprZfA113zBJRLVuovGJRItE7L8PgPBRE4AwDIweR1oKlBh gokndVq/VXpOekU2ba2XraOPlh6DY5dQOp79jnfbuWr6HKl+Q661K6vlUw2e+fydClkyf7088qfP 5Mm/T5S9jyyTA08cJP30DGJpdxUaFESNMocDmBYp2s3VXAIEe6sfsyXEPoAAapR8DhgIJn8M4t6D 9oXtZNSBPeW9Z+bKzPGV0tdA8As8L+3WXo47Z3c5RrXDORNXunOHcyaukCnvV8q7z8yT/sO7qO9w gDuK0b1vBynRuoJGxgHjQPpzwEAw/cdwl2+A9jJKtZ1XHpwusycsl+O+MXyX38nWG3Jy2shu+3R3 1/rV1fL5W+UyRQNpFs1YK4/9ZYI8fddkpx2OOba/AmOp9NTAGtMOs3W22HtnAgcMBDNhFKN4h767 dZLi0gKpVFPfOjX9dVLNx6hpDlBF/sgzhrlr7qSVmpGmwmmJ08cvk3FPz3Wp2fZTMBy+f0+XocZ4 ajPKOJB+HDAQTL8xa1GPC4vzZeQBvWTGp8tk1mfL5YCxA1rUTrZ+acie3YSravUWd8RixifLZM7n K+Xx2z+XfDU3731kX9njkD4yWCNLObCf09Z8h9k6V+y904sDBoLpNV4t7m2BbtQcD/hAox9nT1hh INhCTpZoVpqDvzzIXfOnrHIH8DExT1Pt8F3VDgfv0U2PWvRWc2oPl8yb6FIj44BxIHU5YCCYumMT 0561UV/XwBFd9JxjjiyerXkGN9ZK+w6Ra8PF9OEZ2tigPboK1+GnDXaCBcctpry/RJ69Z4rydqaM Ori37L5fTwXDbg4U8TcaGQeMA6nFAQPB1BqPuPamo/oBh+zZ1aUSWzhjtdugjVrPAXyt+x6jOUn1 OvikgTJ/6mrnN5zw1mIZr2cQB4zsIsP37SnD9u3uApRI6WZkHDAOpAYHDARTYxwS0guypqCdPH3n ZOfPMhCMPdv7795FuPY7rr8c8dUhjs8T3lwsrz40Q95/fp4M3bO7VrPopkcteskI9dGadhj7MbAW jQPN4YCBYHO4leb3Eso/TP1UNZtrnSbYUK8ZLjSlmFHsOUCFe84Uch0wtr+Uqwl6oiby/uS1Ra7c 0/iXF+oRi84uyfdeWvewe9/4JkyI/Rtai8aBzOCAgWBmjGPUb9G9T7GrwL5i8QaXN7PP4I5Rf9du bBkHemsaNq5RB/eR4/Qw/kyN0P341UUumbc7jP+kHrcY3UX2OaqfC15qp35bI+OAcSAxHDAQTAyf U+YpxZ0L9KhEbxclOm/KSgPBBI5MkeYgJZCGBN37f2mALJm33iXy/vTVxbJg+iqZ8HaFq2ox+pDe ak7tJz36WXq7BA6PPSpLOWAgmGUDT0To7nq4+/l/TZGF01fL4V8ZItWbamWuHgJfumC97HVEmZnm 4jwnyBvpax5inj7h/JEy7eOlmrxbE3l/vEwWTF0lbz8+2wHmQZq3dPf9tXhzoUXyxnlYrPks5YCB YJYNPJWZuvQsVI2jxAHfPVe9L4tmrpa1KzZLcef2buM1/1TiJgVCSfsOHaXXwBI5QLXDpZrR50ON KJ2g6do+eW2xM5dS9WKvw/u6IsCMjaVpS9z42JMynwMGgpk/xq4M0+aqWllesUFmaqaTKe8tkZrq evUJrleT3DrZqr/X1zfoZlss+e1tSiRjSnCOs0RN1VwIIidftIdM+3CZvPfcXNXY18hL90+TNx6d KUNGd5NDTkY77KUFg7UCifkPkzFc9swM4oDteBk0mJFeZWt1nTx8y6daSX2h1iHU8oNbtfjvjpu3 SW5BW8mpa+M21XZ5Vlk92VOCEk9deha5Q/gHntBfKuaul49enK/RpRUuXdvUD5dKZ9XmOYaBb7G7 aoqFxVbzMNnjZs9PTw4YCKbnuDWr1/ntc2WMHuQer/Xytqj/r12uVoXfcTJCf6F4vbaYV9DOTG3N 4mz8b2ZMBmkgzUDNR3ryRaNlqh6v+EB9h+Wz1rqzh688MMP5eA88YaAMH9PdlXjKUxDdFZExqK0e j8kzzX9XrLLPM5wDBoIZPsDu9RTnRh7cS7584Sg9KD/pi28MIDYoCOYZCKbqdMBcWlyaLwedNMhd i2au0ZqHixQUKzVDzSqZrGcQS3u01wLAA2Wfo/u6yNJOXSNXCsG0um5FtRx/7u7mA07VQbd+JYQD BoIJYXPyH5KrZs4jvzpM5k/eHoqfm7fzWbSGhgbJzc+xM2rJH6qoesBBey58h5hJJ7xZrjUPV8sr D83UyN+pLiPNgWMHanaa7tK9TwdX6cLT1pp6F3Dz2RvlsrJyk3z1h3tJPz07amQcyEYOGAhm0ah3 1AoIX/nBni4YZrkelsf35KmhQX2DCpRt1VRqlD4coDrIgVoWi6t8zlqNKlW/oR63qJi7Tu668j3p onlKD1K/4ujDyvTAfkfppoA4+7MVDvwKitq5KNT1q6rlzMv30TRulks2fUbeehorDhgIxoqTadLO AM1recrFo+U/vx0v9bUNgpkN4uhEngbItAvRENPktaybyoG+Q0vddcL5I2TyexVqKl2qCRFWySsP zpAX7psue2iKtkNOGaRp25bK2uWbVQjavvwXTFsl/77+Iznjsr3cMQ0j40A2ccBAMJtGW9+VgJgx x/bTjW+1vP7fmRoY0dYBIJExuRYYkxGzAWFmjFa856rUc4eT9UgMNQ/ncC70mvddYFTwrCHHLFZU VMn9v/lYiwbXyJFnDP2CuTwjGGMvYRwIwwEDwSycFoTTj/3mCPUhrZGZny1Ts1iuNCgS5qlmYFUN MmtCYALlOubMYTLj0+Xywr+ny4zxSxGHtks+jQQQblxXI4/+6VOpWlMtY8/bXYq06oiRcSDTOWAg mOkjHOH9emjmkVMu3kNWXrfR+YTYD9EKjTKTA2j5ow/t4yJKJ2+tU99vTuCYzPZ3bteujRA089w9 k92c+PJ39nBnEI2MA5nMAQPBTB7dXbwbeUJP+MFB8r9bP5CGqnXSvoslbM7k6TD1o6XOLLrzOdGd 3xgzaX1dg7yluUvXr66W078/WvqP6JrJbLF3y3IOGAiqGXDT7NlSvXCh1K5dK1UTJkjDli0aMJL5 5Ww4LN1txSYpq+0vUzuOlOUP3i9zX6+UujaWfaTJfUEdq4VDhkh+r16SW1oqhYMHS0G/fim/lUx6 p0Lma9L0wg55eixUNcG225MmbNPIYBzD7qf+oQ3JFBQIJ7y9RFaurJeDB6+W4RvHSb3Oi20hZtSU f2nrYFQc2FZfL7ldukjhUPUHd+rk5naHESMkp6Agqu+n801ZC4LV8+bJiueek/WffCLVixZJ7apV Ur9pk2ypqAh4StJ5aHfdd7xCBIMO7zpGKnv2khWvvyMVa16XLbv+albfAd9K9t1X6tavl5y8PMnr 0cMBYefDD5euJ5wguV1TT3Oq21qvSbo7yXHnj5a2bbbJxjnzpGrWLKmt2iy1DTnqE9YAqaISqaup k1rATsGwpk2RzJiwWpa8s0AOWfuu9KuZahCYoTMf73BhWZnkde/ulIE8ncMFffpI8d57S9exY6Xj /vtn6JurGyBj3yzCiwFyFffeK6tffVU26SZAcuniPfaQ0iOOkNyOHWXjjBnSUFOTFZogLGqzrUE6 6TGJrTXTpaTrAOmcd7TUbrOyPRHXBaG0aiUoGjZMcnJzpWbFCtkwdapUPvSQrHrxRal88EHpftpp 0uvcc6Vdh9Txp7XVM6AHnzpYhua+IuX3/Ufn+UzZum695PcbIEUjR0leWT8FvhzZMHmGaC5193t9 m1ypy8l32l+Hun2kY10fZQvb5Y6ce9m2fWTs+26rq3PCXEHfvlK/caOzjK378ENZ9frrsvzJJ6X0 4IOlz4UXOuEv0yhrQLBh61ZZ9sgjUvGvf8mGzz6Tgv79ZdCvfuWk9zw1A7RVAGRTq12zRjANZA+1 kZw29TKoRre2nLaSl6tmsf8PGsweNjTzTXPat5d2hYXCvKpdt05qli2Tlc8+60AQkzpCVt9LL5Uu Rx3VzJbjc3uNbmrlf79dVr/4gtRqX3sfe4z0OuccKVKzLibdtkWFmlm93mm3ahdt7ATwt30yqLFM QTFrtov4DEKKt4p5vK0KbvwECNkLN0yaJBX//Keb12vff196nnmm9P3BD9ycyRTKilmNer/oz3+W xXfeqUJ8jvT70Y+k7NvfloJBg76g8bUtKsqUsW3We1gwfLPYteNm4mmdL0XNoSX77CM9vvpVWXT7 7bLymWdk4/TpMvAXv5A+OteSSUj0866/XtaOGyfFe+4pw6+/STorONPvUGpX2j1sVy1uOJkjmPhn tyspkfzevaXDqFHS+eijZYUKeIt1D134pz/JhmnTZNhvfiPtBw5MfMfi8MSMB8GaykqZe911svS/ /5UOI0fKEN0M2ACyweEbh/liTTbBgbaqHeI7GfG3v8lSNR8tuPlmma0gWLt6tfRTrTAnP/GiBiba OVdfLZvmzJE+F1wgA664QtoPGGDjaByImgMEyZR95ztSeuihbi6t0liKOo2hGPbHPzqhKt0po0EQ dX7B734nlQ88IJ2POcZJL8V77ZXuY2b9T3EOtFPTetnFF7sIuznXXivzbrxRzY1F0vd739uesidB tPa992S2blpbNPALjXTAj3/szF1GxoHmcgATKUrEyLvukrmqSCxVH/jsn/9cRuj/010jzFgQ3Ka+ mop77pFyDYJBnR9+220umMHIOJAIDrBpdP/KV6SNRo/O+tnP3MaRp6DY49RTEwKEBH3NVZ83UdAD f/lLGah9aNMuY5d7IobUnqEcyOvZU4b99rduDlf+5z9OyBvx978Lgl+6UsauijXvvisLbrnFRX4O vuYaA8B0naFp3u9uJ54otStXyuwrr5QFN90kHYYPlyK94kkENZSr/xtNsJ8GMaABGgDGk+PZ1XY7 DYoZrOC3pbxcVr30kixWEBx01VVpy4SMBMGtGra+SB24+P366wbQSf0zRsaBZHGg9ze/KZvnzpUF 6kPhKAVCWdz8gxraSxTfkvvuky7HHisDfvIT838na+Az+LmY+oepz3vi6afLsv/9T7p+6Utpe3wi 40CQc3+Ep69VTbC7DlDPr30tg6eivVq6cAAgBJw4o9r9lFOk4377xaXrWzUIZ/Edd0i74uLtEdBp kMkmLoywRuPOgaLdd5d+l13mfINL/v1vFySTjhaHjAPBOj2zhRTM4scUlI6DEvfZaw9IOAdIs9br rLNkjvrpVujxieLRo+OiDXKua83bb0tPPaqBT9LIOBAvDji/tyaGWK6a4LoPPpCqiROl45gx8Xpc 3NrNOBDcpGdYNkyeLF3VF5PJqX7iNiOs4bhxgDOEyx57TJY//riUXXSRtNeEDbEk0v6tfPppydfU Vy4oR5M/GBkH4smBAj1L2FstDjO+/31Z/dprBoLxZHY0bZP6Z5UOBGHgnAU0Mg6kEgfIKVqkYebk q+UgfXtMlTE8MlGnSSGY/xxyNj94Ko18ZvelRM2g7LkbVBNEEEu3hCMZpQlS/aFKU6JxaLnEzgNm 9spL07djw1jRubNUffqpdNGzqyTgjhXVLF3qEsCXqEmKBMhGxoFEcIDMQ+QUrV682AWApdsB+owC QbIcbtZzUTl6HirdD3AmYvLaMxLPAXzVRIZu0Q2DvKOxBEE2IdojCbKRcSBRHCAIizlHViIi89ON MgoESZFGMmwObqKWk//OyDiQShwgOXuBlqxhfpLQIVbUUFsraIKkRMMSYmQcSBQHGtQNhTmUKjxk 6Uo3yigQ3KRlkOqqqtwYoJZzliXd6LeajeHrX/+6DNLk3qlKU7V00Iuak/LnGhrdEpqkEYx/+MMf ZIhGTF6vmVSyidDW2CiQmDHfx4poiywxtI01JN2Io003aTKBCzS/aR+tY5eq9PHHH8sHGgl5+eWX t6iLn6g/+NZbb5W91F1zpSZQyASq27BBtixZIltUCEvHuZdRIFhfXe18Ik4TjOEGE8uJ+qTW5pqj ZoNfaC7HcHSfHu84VBPVxhoE56pQ8Je//EVu1woHraV5usk+qKVVWgKCKzV7Cn3oqGO0txbszDaq 37xZanTD2KaaG4FcsSTKIAGyRcrjVCTmzGo9x3iZni0LJUDwX1rm7Mtf/nLMQRCh6/7775c/aQKN 1tJ0DWh6REuytQQEl+i4/12zq3Tr1k320ExWGUNq3SBJPCDoSnGlGWUUCLbRMkmcC3SX/p6KtLse MO2hxSsjUadOnSQ3BqHtP9JyUT/RbCEDGisGdNZgjBP12Aj0zjvvyBtvvCE33HDDLlm0RYWJn/70 p3KjJoGmDShP/U6AWEuITXCyHmF5V5MZ5Ktv7DWNZvzoo4/kWk3DlAyiH59qkMpRGk18tSab/sY3 viHnaJ29IP1T66khvKC9ogUv1cX+PU2GXaAZiaD1uvDv0kTC8PosPQvYFPk56u6JYWSoa07Pbfn5 nwxe7uqZe2pQ0GYVAsJRG+UFc79dK/Ob1qpw8WPNEvUrPY/ZXY+KQD013+WXNKMJhAUDUPyl5lPd Fa3TM8fMiVs0/WL7RhMzc7alc595M3v2bKdJQk/rcRb+3xJhcld9j+Zz1t5nGkjoNVL6hyWK/Ye/ ef7tsi0dOzf3GufgLu9PsRsyCgRTjLdhuwMINrlJxmhjfElz+n3rW9/aCQRPOOEE9+gFCxbIm2++ GRUIsqk8//zzblF4ENy+f7esGkKdaj+0yWYCoaG+rYe7kwGCbMgIBA0NDYKUzgbZVaMqj9V0Y15Q qVDLwssvv+w+QxgYo5GX3/3ud6W3HkM4UwuMQo/p2T/a+aqeAzSKzIGmtB/mU0vnVPCJzC/mK0Do N3HG0oPgLDUZj9O6itGAYLValmjrN9TOC/hZW9pP+sblaYa6bz7UWo/JAMEqdRvBh60Bv7QHRfrH Z2eccUZWTOesBkH8UUOHDnXSP8RmfMABB7gJj+3+Kk0Ki98KLYjNETMgkwczXk1NjfxRc0GySFhQ p1IdoLGN/bWmXKFWHX9f02RhOvnrX/+6Y4FjEpqmB/pv1rx7EJsrZkrapY21etbLa4I8429amw6J ETr77LPl+3oolUX4gJaHev31113/n9EMJEVaqgcTzVf0kPR3tPZXpQYJodEgBb+qaeQWq5nsd1pW 6pJLLnF+uDXqO9pXw5rZ0DG9MunRHnlPiP7QHpIiJky0yIFaRPNZLa4Jf/g+/QYA6tUcct5557nn enCDL/doFQ+ky4M1d6vXOr+p6cPYiPbRArS8xyqtS4YmRV++rYduf/jDH35h4QFSPOtxPWQOEMPf KVOmyKOPPuraQJqGn2iY/fUAOmB1yCGHOJMz7XqwouEV6ov7mVZUQKvDBMd3eSb9HKln+DBVPfXU U07T8wBHm7vttpsD78FaPJfvM/YjRoyQDeoPoR/4s5gr6ULMWfh4mmb8gA+AODxj7r2nibev0fym zPNf//rXTvNhzNgwATKEBzSGt956y2lcHmBYP4w1lgLm5gsvvCC3afUWT2jL8J/vQGjXd2iKN6wN J598suOln/ubNHCIMacNtEMEOuYHxHcm6pm0Xurz53M0SMaEfnAPz2At9dNIXNbX559/LmjzzD36 w3OYF1dobcUOGtDBvGFd0A7EnGQtMMeY+0cccYQgvLKW0f6XL1/uTKvMfYp0X3jhhXL++efv6PsT TzzhTLv+u8x91hP3LVy40D0boh14yf+Zg/79gnMInvMs1jhrGW0awZF9BMIywboGUJmbACqCGmv3 uOOOk5NOOmlHc4u0pBa8Zz9i/dIX1qxf7wAy8QjsO/yO0My+kumU1SAIUDHRMXuwkTNB7tXcjgAL IFisob9MUswnx+iZLiY9YHKnZuifOXOm2zjZNGnj8MMPd5vJdVrAl89ZNJjZ2BCCkiOaBd+FMMX9 4x//cJON7+MPLNfM7HwHAkR4Nhs8i+jhhx92fQJwli1b5vrzZ632zH1sXPgb+mqoMguB//M+bOxs IrwjE5tN4GKtdfecFsYEYNlI2HBYGIClFwjoC/zh2ZhV2fRpG2Lhs4AAL9rAT/IfLavSRSNzWURI lIA0kuRoTQ+GPwaTEtoefQKc6DPtAPBswPSLRR6O6Au84r3YkAEc/KrwFbCnb/ydsWPTgyf0BXD3 m7sPtmAzAcRLNRM+44BWDCADsIDafprTk3vYMNmceS6/A5b8H2Kz5XtsNPCWYI4DDzwwrfYKxpa5 dfzxx7sNkbH5rxaeRmtC8AEQGF8A4rDDDnPjy/sT1IEQxwYPj2kD4ANYaINxh9cTJkzYYS72jGHt ML8hQJJ5gfbMps18YE4z91lHrCHGGABgnTHXmfvMKdYQgoef+4Ax8wdhBdCm/8xbhDaI98MEyd8Q DFnbCEFlGqUL4AGqzFOAGAIwmYuYtpmrrA2vVTLe9AuNjj4Cxg9pUnT4hj8T4Y++AoqAEnMXnjF3 ETwALOYpBJCxdhAosCyEI/YH9hF4C29YPwjKEHOQdcV3WaOsJZ7F+uDd4TGCDnsUgiQCLDwE+AFP xoL5DuGS2KjVR07RvLa8m+cj+1KmU1aDIJISwMHiYzGzoWImZHEzOZHM2OyRJJHAWEhMFO5jI0Br Ol2TdCPR0gZ/w6xGGywaNlkk7SAxkb0vCTMbC/FSrTreVm3qbDz8DUDmQqL8geY/ZXPm/2xI/A0Q ZKLSfyRktC/6Rz9YGGwUTHQ2dzQYCMDg2fydvwGSfO7poIMOcn7CsWPHur4AJmjCLAJ+sljgC4SZ CEEBECjRYyhoDIANGwIgSB+RwjErIkminXIv0jrP5G9sfBA8Q4gI9iV00fFebF5e28avyCKF0FDm z5/vBAR4Dq+QbnmXizQ12dc0gTobMhszAg0bBX4eeMEYA+xsbGy88PRorT2JKRkgZ6wZE3jAJh0k Nkg2TzRTnpFuBJCzwaI1MV8BGsCEMYOnWAjgD+uCsSYqEqEF8GO8GF/mGfykDeaTb4M5hNXEC1Se N8G5jxCGoIjGzdwElHk+mzV8RxBhvgzTGqBs6AAXz+KZrAUA59xzz3XaF3P/f5q/krWHsOrnFwIe RL95NgAAMDFf/HxjzvD7K6+8IkceeaSbI4w9YMJ7AzqsDS+Y8vmoUaOc5shzmPsIj4AKfQIAh2up LOYMwhZ/Y74BgESE+nVJv9hP4Gekuc+c5J3REr0/n3cElCHGAW0SAQChjnWNwIbgBl/Ze+gX/m4E GrRmQJj1zRjDV/gOsX6Z/7wnF4IxY2ogmG4ru5n9RfpDQ2JiITUxcVjsmEQxHQAymHjY1NlI2RDR rNhgkaLQPphgSHa0weJh80ByQzrmHm/6CNc1Ng82YSYlhOZCmyxyFi4bCVIdPgkWBBsEfYP4nQXs zY9+ofNd/7nXXPyzvUaKucPf5z9jU2exsREhabOxsDi5l8URbItns6EAgJ7YELy/A54C5vAJE6J/ P8AGAOX7XPQZc09oX0J5BZ+C0bKMAd+F2DAhL6kjYNAvr1XA//HjxztwY6GzebOJ0Q9Am3GC4C9/ Q2pmXvxbs+LTdzYxgI7PggQwIwSxYbBhp5v/hLFlA2beYgrHzM5PNnDGH5CEt2yorAnmKfOfewAR +AjgYOKkDdYJbbBxYjJFUPSCTqS5z1z2cxLhhTnFOPA3NmkAiHni5zMADTFf0Ly86ZT5xe/RzP1w 8w0wJWKVvjMnMAsD0FhfeD5j70GQ/8OHoJkQIPFzHwENNwhaF3+jb6xR5quf+54f9CXoIwzlE7xg jABuT/DJ8wxgo30AEKJP9IXv8ExAl75gpUDQwVzPe/E9hE8/9+E1gMyehwADodkD+Kl+XCvc3Gru 37JaE2RiMsEAQBY89nNs65g0kCLZUNEgmLxoRixqNmMmOBs6piTa4G+0weRi08R05tsA1JhMmGTQ +oKEyQVJjoVAe3wPAGFis9iQgjFzIKGyCDGDeEe2B8XQAfcLhA3Bg0+4xcX3g8Q7cDSDzZ+FjJkF qZXFQF9Co/ZCvx/8P5sEEimgygKFf5id4GfQEe83t9C2+DtaBYsaQGPDgzdeAGCj8psjGyfvzP2M Gc+Ch14Dxo+KKQohBqkabZI22bjRrIP+Qt8PxpBNHUnebwr0yfMWQQFzHBI4Y46gAv+a0mabuzDj fT/jSTQrWi/zj3eGH/wfwGNeA3TwEk0HbYi57AUbNATuoQ20KIQk2vBnSGmD8WNdASah5j7GCqD0 whBaDffRJuOAoIMJkA0cgGP9BIUlP/5BPkUz9/le6HwDGLB0YN4EQPjJekMI4pmh0drh5r5/NoIR 7gasEfALjYq+83mosBeuL7wPfGGOwj/mPiAFPyA0c/982mfsWK9YaVirXN5ig/UE3y7fQfNmTQKO COdYqbw/kLnOd1gfvm36xv2AaKyPa8V7bje3/awGQZjFYkYDxPSJeQD/B+YLfHsQGwELE5DD5MKm jsOeyedDi2kDDRAzJW3wfz5jEbPZoCEyGfFV8D2vVWDiAGy4kD5xvOP0hgAwpDCeyYRkcWESgnDa Ayah2glgy8KF2HQAYjYWNjAmt9eamPB8l80N6dBPcsx6+CkIBPBn+OgHWhb9AITYLFjMLO4gsQl6 oKTfBAbwHTQxAAdtggABNgPfD77Pe7Fw4S8CiffjsADxF8FX+oXmRfsALD4bL0EDdpitaBvzGxsy n/EOEJ8xhviWAHWvnaDt0A8kawh++vB9hA+CY+ir1zh5X8aB7+GDxA+ItgzRT57P+UfvN23uQkzG /Qg9aEDMJ8AM/xH+qd///veuO8wN5gnAhjkbIQZTHIIH2jTEesGcj9meNpgjBJLRDoQJju+wmQbn LL4n1hF+PcYE/yAaJvOU9uEpcxFLBGPO9wEGAIa5FqpBMT7+bwAH84V5T38YNz9fmcsIk2hGzDf8 iBBzlvXHc30EN0DIesfUjlbFXOYZocc84BH9hNAqeRfmDxox7hSEC2/NCa4b+gmAIVTBaz93mO+M CdYZzwf4AoDhY/RAxfxDSGfuYYkA6BDceG/IB3qxv8BT3gHCN0ufeU+0P2IF0LJDj35gPQEg+ZnK CQxau3ayHgTZ1AEtJH4WOSYepGFvC2diMEFYiH5xYCpiEvkFFNoGJlI2GN8G5jRvFmWj8AuByQoA +yg4bPgsAG+nZ6MFhDA5sXB9eD6DDnB536KfBHzuQ/vxWdAuQAcw0AeAFqK/aJeANIufcHIIrYZ3 QnvyfWBR0UcCYAAqpEWeERoIAm+85knbgAc+JwIl0IDxXbKpIN36fvBM+AS4I3gQTEC/IUyS3qeD cMEmg1+OTQkzDpsrmxv34DvC10G0H/3nffyCpy3axYdI4AN953v4edHcvJkLoSFovgvVotlM2UAx qbIpeP8k7aNNYrJlw6Cv6ULMP0CM+cwGi/kfc6cfH4Ql1gNz1ke+cg9j6DU7+BLaBps64wphXvYC FW14EzpzBOEHvyqWFfjJRu7HA7BDkGIOcx99BTghTLahWhXz0R/hAZARSBA+mSf0wc9XhCOEUXx0 aEL4jSE0XgQmgMe7GFjzfM76Y70ROAQYhJp5ATvPD/gDYVFBWIN3rGOIvcQDFP+Ht2hpCMyYklkj EPzyUdoI58x9BAksR/CaMYKY68x5gnz4CajzM3gMizYRSPjJ2kEQQev274CFhjXheRucu/jyEWDR ZA0E02VVt6CfLBAfbszXkcYwdQWJTZTLE5tukNgs2Ow9sekH22Cj8Ka8oPmN+1k0fuGEdp+NmAXk F1Hwc79ggn8LhqNjmuLyhIbFpgKxWSA9hh6WZ5GzSIN+TLQhgJLLEyDqo8r830KzgCAAhHOqsykg zXqC/15rCL4L0qsn+kAErd+w+D7anSc2qNDAlWBbvA9SsifAHrMeAofX9DBtc0Uin2nH+1GC97G5 JOOcY8TORvkBGzdajic04NC574+K+Hu8hcT/HyGEeeOJjTjYBgIDFxQ6jxFKfEQmn3thjN8BQ54d +nw+C3eMBjD1BJgGfbQIVH5+sOF7Tdffj2ZFhCfCrjc78hnrj3UWXGvB9/HfJ3AsSJHWNFYHBENP 8D84z/3fETg9Yf1AQPDvzHsGrQ0AHoAbiZivWIQ8AWgIcv6dWBuR4hbYM8L1L+LD0vSDrNcE03Tc YtptAnmIasNPwCaXameD2KQQMtgQMPciCXPmygNYc5nB99g8wgFac9uy+9ObA5hZMdtj5sYKEWpd SfbbYX5FeEWDRiPGdInW2FJi7mPK9kJ5S9vJpO9lFAiSi9HnZCRbv1F0HODcE/4YtLlUXBxogpjP kHjZCHD4t+ZYAmapaFLGRce95t3l5yhllNS507wvN3W3tsXcp5oEl1F0HCAQDgDEjJiK+TwR/Jj7 /pwmGlw402V0b7s9ijrmc9/PPe1ErPPhRvterbkvo0AwX00dBWpuo6SHFRWNflrgA+RKZcJMG/Sn pHJfm+pbns7R9mq+dbkWY1hQl5yh1HQrUr9WYQpXIEm1ccMv6KMkU61vvj/4MX2gVyr2MUdjKQrU P1mk5tP8CIf+U7Hfvk8ZBYIdVM2nwGM7jQIsTKMUVqk8QaxvseVAew7nq2mrUH1nbRsPKsfiCRTq LVKfU64GLxkIxoKj1ka0HGDPpWxdgQbuFKoQlm6UUSDIplKvYe+U9bCiuuk2FbOjv7Ua5btZTc9F erQjp5UVE4IcQ7PM1QCtjXqmjHJKRsaBRHEA8/sW6mTq3Ka4brpRRoEgJqEOeqh0vYbcb1I/VzoW 1U23CWT9bR4HKDraoOc5izQwp01jKabmtRD5bqrKA4Zb9OyXkXEgURyop46l7rcFaIOBqO1EPb+1 z8ksEKTWl/qOVut5rSpNldU5C5K/tnYC2PcTy4EqPZ9IYd2OeqYz1jUv8YMjBNY0VvjG5GpkHIg3 ByimW6VnD3trwBrm/nSjzAJBDf/tomeSFmjGi9V6YLefZl3AV2JkHEgFDmzUhNSb9CpRACQ4JtaU q+c/e+iZsgWa/HmV5m7t15h4INbPsfaMA54DDZq9Z7Vm32mnCRQ66ZlErHHpRunX411wuL1GKXXR Q6+rNVPKMj3/01vTGBkZB1KBA0v0kP8m9dkN1+wfAFasiQ2oi2Z/WaipyFZqFpbummGFiFEj40C8 OLBJzxYv0cw4xZqSrWtj8u14PSte7WYcCBKuW6Zhzys1Q8gSPWTaWVOYFWiqIyPjQDI5sEalZeYk 5krmJL67eFChZn3pranbFmvWkUrNvTlI04MZGQfiwYF6PbNboRV0+NlNMzqlawxGxoGgZj2WEpVK emsC5oq775ZyrRc4VEsR8Xcj40AyOLBV84qWa/7Jaq31OEql5sLGpM3x6EtbFQJ7qfUDTXCpgmBH 6kA2liCKx/OszezlACb3Sk03V6o5iXvpfpuulHkgqCORo0mf0QbX6JmpJZplpEBzefYl1ZABYbrO 07Ttd4MmP16gCY5XKCj11OTMXchP2lgLMV4vVazaZn8twTVTfeL4x5HQ0UCNjAOx4sA6TTc3h+LU eiynjyYZ52e6UkaCIIPBOayhN98s07UUz0Ito9NOfTA9NWFyvMxQ6ToBrN/x4wAAuFCDVCq0+kVH LVM0UBOv52nC8LiTCns9tbIF/sdF6h+cd/31MlTBsFAzehgZB1rLASKcZ/30p7JVzwUO1Fqd+J7T mTIWBBkUHLVDtLbZbN18Zutg1emg9dHce2iKRsaBeHKAhA1ogIu1QCtHFZiHZDRKFJGVZoDmgq3V UjlL1WRVp/X2hmofSrR8lJFxoCUc2KYlyNZq1P0s3U+rtU5iH61w01/nWKyP+rSkb635TkaDIIzx 0aFIw6jvZNPop/XGLGquNdPGvhuJA2TP4BgEZsjlWtiV84CDtWxV58Yiv4nkXL66AYbovG+jldnx D05Ts9UgLe7MMaJ2ml/XyDgQLQe2qjC14plnZL4KUhyL6Ktlrgi6yolh/tto+xLr+zIeBPG/9NZa gLlqhlqgxSUXa3g6vsIBqs530sKfBSR8jbOPJtaDZu2lHgcwfdZoAdJlCnzlqv3VqSbYXc/ssVEQ Pp4sIoPHbqqRMs8rNFp6qhZp7an19srUTUCy7XZaONbIOBCJA4DfRi38u0gDDFdrkWKOoA3Qihtl CoKxTPuXzBHIfBBs5C4hvCz6cvXPEKo+VQNn8NNgz2aTytXCqBysZ9BdORALoknmvEzpZxNnDHhQ BaKhulpqli+X9R995OYV56aKtYgrB9UxvcfjPGBzmUNfB2mdyGI1hXJsaMXTT8uql16Sriee6CJH SbfWVpMgU7Jq68qVgtnL5n9zuZzm9+uYt1U3ERYCytDV6bEH5jLAt+qVV1yy9x6nnSZlak0o1er2 mURZA4IMGpUlkIq7n3SSLNXq8VVaTBYzaV1VleTrWUKAcNPs2UKtNzYEI+PAFzigtdM4lI4AxUZR U1npgCNfM+gXDR8uAzQqs9c3vuEqOqQSMZ8R+Eo1leCyRx6R1bqxrdH0gkRPI/y116AZoqj52zZq HZp1JJWGL+59AfioPoKbiGTYW9SqwRwoUn92V1UguqnA5AIL1bSeaZRVIOgHr1T9M1wbp06VNe+8 43w4W1Sa59AnAEhxUtsEMm2qx+h9VGIGBHM1TydCE1HIgAfWhM5a/DTVfc25qhXiz+FA/dpx42Sd 5tjl/GKdJkFG2kcrdAWpTQiM0YRJj2awflELkOhlgqpKNaEDlrNOmosZwSmT50NWgqCflkTr+Yi9 OkowrVkjGzT8F/9Oukc8pcfSS99e4mPGssCmkY7BAW011yMSPheENrtFK6xXa5mnmFa8T98hzqqe b1MLB9m2nDaoQl02BU5lNQgGZzmFeLnap2EpkKxarfayceEAYM5VsvfecWnfGjUOpCoHDARTdWSs X8YB44BxwDgQdw4YCMadxfYA44BxwDhgHEhVDhgIpurIWL+MA8YB44BxIO4cMBCMO4vtAcYB44Bx wDiQqhwwEEzVkbF+GQeMA8YB40DcOWAgGHcW2wOMA8YB44BxIFU5YCCYqiNj/TIOGAeMA8aBuHPA QDDuLLYHGAeMA8YB40CqcsBAMFVHxvplHDAOGAeMA3HngIFg3FlsDzAOGAeMA8aBVOWAgWCqjoz1 yzhgHDAOGAfizgEDwbiz2B5gHDAOGAeMA6nKAQPBVB0Z65dxwDhgHDAOxJ0DBoJxZ7E9wDhgHDAO GAdSlQMGgqk6MtYv44BxwDhgHIg7BwwE485ie4BxwDhgHDAOpCoHDARTdWSsX8YB44BxwDgQdw4Y CMadxfYA44BxwDhgHEhVDiQVBBsaGuTmm2+WCy64QHr16hWRRy+++KKsXr1azjvvvLjysbq6Wm65 5Ra59NJLpVOnTjF91oQJE+Tdd9+Vyy67rNXtbt26VZ5++ml56qmnBB5+61vfkhNOOKHV7VoDxgHj gHEg2ziQVBDctm2b3HbbbXLiiSc2CYLjxo2T+fPnxxQE//KXv8ioUaPkmGOO2THmW7ZskVtvvVW+ +93vytKlS+Xvf/+73HTTTc2aEzU1NfLrX/9afvazn0nnzp13fHf69Ony4IMPxgQE33vvPbn//vvl 4IMPlg4dOjje/fnPf5bRo0fL0Ucf3az+2s3GAeOAcSCbOZBUEMzJyRG0vGHDhjU5BkVFRVJcXBzT cXr55ZelXbt2O4Egz3jllVeka9euMnPmTHnkkUeaDYK0+d///lcuv/zynfqbn58vHTt2jMk7zJ49 W9q3by9XX331jvZ+8YtfCM8wEIwJi60R44BxIEs4kFQQRBN89NFHHWAAdNDUqVPlb3/7m0ybNk26 d+8uP/nJTyQ3N3en4VizZo3cfffd8uqrr0phYaGcf/758rWvfU0A1fLycmdiRYP717/+5UCttrZW DjjgALn44otl8ODB8te//lU++eQTAUwALAgtbeDAgc7EiCmUe5ctWyaHHHKI+/zkk092gAl4XnLJ JTtpeXyOuRYN8NNPP5VVq1bJSSed5ECJNmmbvhUUFAh9/8Mf/iAffvihe69jjz1WLrroIunSpcuO d5wzZ47jASbUvn37yve+9z05/PDD3efvv/++/P73v5eNGzfKoYceKldccYWsX7/ePXfevHnuWRCa 4pAhQyJO4zfeeEPuvfdexy94cu2118rjjz8uI0aMkFNPPdV9D+2VeyZOnOj+v+eeezoteffdd5fn n3/e8Y/xCUeYlXv37i1nnnmmEzaMjAPGAeNAKnIgqbsTIIhvC58Wm/3nn38uaDRHHXWUnHbaaQ4w 3nnnHXnsscd2gMDmzZvlmmuukU2bNrkNeMOGDXLfffc5gGHzBvAANrQ6zJEAbJs2bdxzbrjhBrn+ +utl7Nix8r///U/22Wcf+fKXv+zGpVu3bg5YeBY+QUDwxhtvdMAG9enTR9q2bevAGSD8xje+sdN4 PvHEE1JVVeUAkuf8+Mc/diCOuRKif5MmTXIm1h49eshVV10lmF8feOABWbt2rVx55ZVSWlrqQAlg A4zQ9NBIAc2SkhLZa6+9nNYMwE6ZMsXxAUDinYcPHy777bef+wziGZHoySeflDvuuEPOOOMMB4AV FRVOGPnTn/7kBAgIIMaki8mY/sBDzNL8ftdddzmhBSCHHyNHjtzpUQgy8Aj/JzwzMg4YB4wDqcqB pIIgTAGs8vLy3Eb+n//8x2k3AAigAaGFPPTQQzv498wzzzgABCwBCgiNCw0OTY220LAwaaJBeTMq GzXA89JLL8n3v/99p6UAKscdd9yOttetW+c2d75zxBFHyO23377T5wSh7LHHHvL222/LWWedtWOD r6urE4AF4Dz99NOdX5FAlaBPkIcA4IAYYO3fD/C/7rrrnNZH/+EBwMT7oZEC2PX19U7Do7+ANRoZ AkKw77zP3nvvvdPfwk06tMVnn33Wgfi3v/1tB27Qa6+95vgG/yCeN3ToUPnpT3/qwBwCZH/zm984 oQPQRpv85z//6cAzSPfcc48DZ4QZ336qLgDrl3HAOJDdHEg6CMJ+tAW0MEyUaEYeIPiMjf/II48U Ak4gtA82ZTQdzI5ssgSEoLUBjgAVpkVAKuhH7N+/v9Pm0HAggAtNLEh+w6YNAAvwCRImTYAHc+pb b73lTJkQfk38fWiWfIe2eZ8gCNJ/zJNf+cpXHGh74ju0u2TJEvcngl7OPvts9x68H58BnICsJ/rN M4IU7n3CTe2FCxe6oB9AMAhQ+BIBeM/njz76SH7wgx/sAEDaAoB5f4JwMJ8yLgDgxx9/LPvvv/+O 8UGjR4v1WnB2LzF7e+OAcSCVOZASIMhmzCaOOdFrHUGmAXiLFy92fwIc0FLw9fE7xPc53gB48hOQ QTMKJQCF4wWtoTFjxjgwwB+J5sazMSUeeOCBAtDy/HAEOGLSDAKgvw+zsAdctFHMqX/84x+Fv3ve oDHGggB3eBAUNGgXQQQg9zzFzEx/Q4l7+AzCX4ofEd8rWiKEZogGedBBB8Wiu9aGccA4YByIKwdS AgTZ7AmeYNNdsWKFCyYJ0vLly51GBHHvd77zHWcy9Rs2GzhmTEx5BLM0RV77oR3fZnM4zHe+9KUv OSAmcIT/A94cV6Bt+hSpbf6+K0J7xQQJwHpgxEzpA4cifT/a9yGqFD6h8QUBmX7zHp4n9IP/hxJ/ 8xo2bXG85Xe/+50LzKENzLr4UWMVCbsrftnnxgHjgHGgNRxICRBks8d0hjaB/4+ADL9BE0xCcAz+ Ja998H/AkmAQT5j40CKDINcUY9jsvenP3xcKUvyfjT0ULAEojk/QD0AXc6z3T9IWfWiuxumfjYkR cyKmVvyaEP5STKM9e/aM+Erh3oeb0bAXLVrkBAvuGTBggNOSCR7CJ+gJ8y7BNj7gB832zTffdBqd 187pw+uvv+60Xk9EraIJE80Kr3bbbbcdQUytmZj2XeOAccA4kAgOJB0EMa0BGGg7HHUg4AKtEF8Z UZMLFixwIOD9d1/96led1kHE5CmnnOLOy3EPYElACgDkzXWhDKQNb67E10g7BInQBps9z+W7AAeR mhxCZ3MnyAOTLGAH0Vd8Y5gC586d67LMeO2IzwBEAlwwFwLutE2b+CzDEX/3gAwwEdHK+xEkBBEc hBnTH9znXv4fJN4H35x/H4CKPiEc4O+DPwTa4JckIvbOO+90fB80aJBUVla6CNHgUYZzzjnH9YN3 I0gIvpLxZsaMGc4n6Ik2OZ7y9a9/3WnARN3GOttOIhaCPcM4YBzITg4kFQTZWNmgPYAQ3YgvjGME L7zwggMezJ742nzgCBoiPjMCaIhCJAAFjZBNmzODABpthotKJELUgylgQ/QnZ+4gzJtoSWh5mFfR wggMASzQdNDQPAhyPwDM88vKymTffffdMXvoH0c3AAoiLtHAAEHu82cOQ6can/OOEMBLsAlt8xPt iqCTYMo4okdDAfXCCy8UsuD49+GcIHz1/AietUSQQBskwAewxofHcQuOYyBwQATj0BY+PoAQInAG cEbbCxJgzflBNE0P3Nm5nOytjQPGgXTjQFJBkE2Tw9hBAmg4CB+kUPBAu+KYA1coATb/+Mc/wo4D h9I9ESmKLyuU2PQ9oTH5c4Sh9wGUmCcBR2+29PdwMP/hhx/e6SuHHXaYcIWj0NRs9I3zjJGIM5Rc QeI7AFQo0bd///vfO/0Zsyb+12AfOe6Avy94wB7QC2p9kfrDMwBgI+OAccA4kG4cSCoIphuz6C/+ OnyBnLfDlEhgSLoRpk9AC40O7Rltmkw0ADoAbmSOH0FhAAAN3klEQVQcMA4YB7KFAwaCzRxpAmHG jx8v/fr1c9UvvBmzmc0k9XZ8lvjwSH1Gujd8eJhT0Xr9YfmkdtAebhwwDhgHEsQBA8FmMppMMOle tgig45gHl5FxwDhgHMhmDhgIZvPo27sbB4wDxoEs54CBYJZPAHt944BxwDiQzRwwEMzm0bd3Nw4Y B4wDWc4BA8EsnwD2+sYB44BxIJs5YCCYzaNv724cMA4YB7KcAwaCWT4B7PWNA8YB40A2cyAlQJBS PBw+J3UXab6MjAPx5gB5aSkQTEq6M888M96Ps/aNA8aBFOVA0kGQzYj8lZQP8pUjyJdJFhPyWJLU mRyYwUoOJGom0TWfk0IttCQQbXI/NfNCQZWk0b74Lt+LpvAr+Ub5DufrgoV6g2NKYm6SZFPyqKkS TSS/5t14L7K1BHN60t769etdO/SNtpqqzM770y+qcIR7F2oTwkvfVjRzkHelXfpGajgIfvsk37yb L1sVqT2fqJzvhT6bv/H+jAPtw/9g4u5QnsKf0M95J/jIZ/ALoi365nOf0kfGP8gj2uF53Ms4khaO NHkUOrYkAdHMDrvHOJB5HEg6CL799ttCwVgSL7OJASaUKXriiSdcIV2qs1Pe55vf/KbbUNkAn3rq KZdke82aNS4pNVXOfZkhSiyRyoxNm+oPTz/99I5Roz3yaJLYGhAl7dlll13mcnr6DT90iClDRB5P Kk6Q3JrKCmPHjt0JnKjoQB5TCu2SUo3k05GIe375y1+6/vFs2gsS7UyePNmBBFXmwxUZ5n4qP9x3 333y8ssvOyAgc82ll17qkofzLvAJvlFJHjD44IMPvlBIN7SPAAZ9g/9UyIC3gNZzzz3nEozPmjXL gQhlni655JKwfZs6darL3UoaNsCZpOW8J0nGaYt2SUhO9Q3ylwJAJN8OJ4xQVYTr5JNP3qmrWA0Q msi56ks/efD2QsqvfvUrN06kh2O8EQjIK4vWx3cAPXgF/+AzvxsZB4wD2ceBlABBANBvXoAY+Tmv uOIKVx2CMkKUM0I7oqoD5YLYkKkCQa5LCriShJvKDUj/VH2n6vy4cePkt7/97U4jSrtslnfddZd0 6dLFlR268cYbXZUEKliEEuBCFQnAlzYBA0CUCgx77rnnjtvZ9Hmu15iamkaUYCI/51VXXeVKQIUS 4E4ia4AmUuklvkPtPzZ2eANQvvjii3LzzTfvKN2EQEGljfLyclfqCM0pWE0ebQxeBJN/w1e0JV8o mOcAxggqp556qhMW6BP8o5IHz4bgE4CHwAL4UYYKgObnSy+95MzcVLVgfABjiiJT+mnOnDmukgWC D/eEEsWUw/EAsAYIqX5BzUOIpOu0zXMghADAF22RZyAkAbz0BwGI8WfMGAvaMBDMvs3P3tg4AAeS CoJsVJTvOf3003eYvNAKASVvnkKaB9DQjiAkdxI/s7GzqaORXHfddcKGiWaHFsTmBjCEmrhOOukk 4fLmtYsvvtgBKjX3woEgmuO0adNcdQa0QMo1oelQccGDIJoiIIFGB0AD1k0RfeYCIMLdy98RCDBH NkWUfGLj9uZU8phSKBfQozQTxEYPOAXBz7cJSKGVIghAK1eudP9H4w6WVEIAoNpGkJfUKgxW26Dk Evznb/QDEPWaNZoeYAlQMibw0rcFTxFy4F844r5wGjomYt6bz72mzLtSzd7/H8GEz9FsKZEFAYSA nh9/+EKpq0jPty3COGAcyHwOJBUE0ZwwaQaLsLKBBjdctAU2WC+pAzokgPYbO+Y2NvDQIrPhACbU t4T2hBnRb5Khw41Ghn/RV7BHk8GEBzh6uuOOO1wB4P3228/5n0Kr00eaQoBTJH8f2teu2gl9F0x+ AADaUZC8jyy0H6H3EpyEhnvUUUfJbbfdttPzGQ/aQctDU0cIoCahJ8yM3vfqQRmhhWTjaFm+3BTv GxxbakTOnj3b1XBsCQV5BD8Rqjxhvg43tqE+WOYeScSNjAPGgezkQFJBEJYj6Ufa8AEbiuyyyXrf D5txMPDEb9DBDTCaoUS7pHAtpjlAFQJIMBOyoaOBQoBpEKz43QML5jdq833ve99z36EP3qyL+RHN iu9jJqQ6e7zoo48+cj5SNNVwGm245+Ib81GRABamQnxz3u8a6qNDIMAEilDA+wR9mZipQwlTLJXo uR9NPTSgCDClaDCgFKzzGGyHeRFOUGD8dyUkIBRFCrgJPoPxiea+eI2dtWscMA4klwNJBUE2M4rB Yo7EvBjc8KZPn+58ephHMWn5z9hMg9oNfrGmIgzDsfeZZ55xvj5Mfz7ogk0V0yjaCaY1QNBHl+I7 85onGoff0DH/eXMoJjU2doI+fvaznzlfGn4qvosmGS8QxMd1++23O0DDRNwSos8AIT5TfI3UG4RH +O3gBcRPtDrABU2R4wWhhYODz0Z4gd566y0XuISJFtMjRLAOYwsA8jNSZCbgBL9DifGPFMjk78X0 CXA3RYw5Y4aQZWQcMA5kJweSCoIAG5oLmy/mTq+FTJgwwYHUmDFjvhA9iemRaD42ajYvfFoAJb60 IOEfCpXwCcDg/ieffFJ+/vOf7xQMQV98UIVvhzbxL/IdQAZtCdDzwHnwwQe7jZb2ILQeokPxU/I9 6vVFoqbOQ+IPpO9oXJEIcMWc+9hjj7mo0EjlnWiDtuBHkDBDYq48/PDDnTkXszOBPwAD5uUPP/zQ Bd7wPcYDQASs6FuoCREAhbf42/ChYjJmTCD8fvDIg9mMGTOcj5CxI4KzKUIwAkQJyMFUCxHUQoQp ZvCmjqLg+0U4IMrYm24Bz08++cTNOfiP1o+wxTwzMg4YB7KTA0kFQVhOTTsiJdHK0ArRxM4444wd Yf+EwWNmZIPlXjY3NuUrr7zSBcIQjII5EtCB2HDZZNncCLrAhMeGyUb4wgsvOJMhm/5nn33mfFxs +ueee65rK5TYqImKxF/G5k2b/I3ITYhCtFyeCNghEtH3JdyUAjA4tgHgQAA/wSOjR492/0e7JGqU ABxAgn798Ic//ILmg1/u7LPPdsdAuBcfGO9y1llnucAhfsdEOn/+fAdMaNNoYgQDQYAD2h6mVHgT 9PFxgJxjIYMHD3Zatxcc8IkS4IIAghnZE9GijBvtTZo0yfG1R48eDvgAV8YTMCTSE/7DS6J50Sa5 Z9SoUS44KpQIsiHohshR77dFcwO80baDIAgIBzU/NG+0WrRceAPo8Xw0Wczf/B9zOwWSAUsj44Bx IDs5kHQQRMNA20AL41gEJjKAB3MXkY7e1+fP3qERcB+mS87KsVGecsopOzZEfDxsbphI2fDR3NiQ ITQ7wubZ2Dnz5v1KaFXhCM0HDZA+4ENEMznvvPN2OlYQ/B5gFQzyCdcmGzF9IgAF4vfgMQA2eK4f /ehHblMHXML5v+AZGicgEnyXYIAQ30Vzoi18l8EoUZ4fyQwIwBFUAjEeCAmAJuCMWRQfXjCYBRBH q4IwI+MPBVzRQDkSQhV7QIf34Xs8G23Ta4d+fEL5hRkZfyJCAxGrjAP9Yly90OC/wzEbhKjQ8UBI IKKYuYR2im+ZMaK/+C2ZTwgNRsYB40B2ciDpIMgmi6SPeQ7Cl8MB56YIDYXNMRxh/kMzCUdswM2N RKR/AB/Xrgiz5K4I35g/whDu3quvvnpXTbjP2fS5IhHmXc4NRiKOOXCFI68t+s8Ao6b6dfzxx+9o Bv5zhpMrlDCTel9hVC+pN6EBhiYUCPddTNNcodTUmCOABc97Rtsnu884YBzIHA4kHQRhJZsRl5Fx IFEcwFKAhmpkHDAOZDcHUgIEs3sI7O2NA8YB44BxIFkcMBBMFuftucYB44BxwDiQdA4YCCZ9CKwD xgHjgHHAOJAsDhgIJovz9lzjgHHAOGAcSDoHDASTPgTWAeOAccA4YBxIFgcMBJPFeXuuccA4YBww DiSdAwaCSR8C64BxwDhgHDAOJIsDBoLJ4rw91zhgHDAOGAeSzoFWgSBpsULrsyX9jawDxgHjgHHA OJAVHACDmkqkHw0TWgyC5H2k2C0X2Td2Vd8tms7YPcYB44BxwDhgHIiGA4AfOYgpzN4aajEIkgeS fJ+UC+L3cHXfWtMx+65xwDhgHDAOGAcicQAtECWMogHhim9Hy7kWgyC5PimtQwmb1nQg2o7afcYB 44BxwDhgHPAcwPpI5Rhq0bbGJNpiEKSUjxUjtQlpHDAOGAeMA+nMgRaDYDq/tPXdOGAcMA4YB4wD cMBA0OaBccA4YBwwDmQtBwwEs3bo7cWNA8YB44BxwEDQ5oBxwDhgHDAOZC0HDASzdujtxY0DxgHj gHHAQNDmgHHAOGAcMA5kLQcMBLN26O3FjQPGAeOAccBA0OaAccA4YBwwDmQtBwwEs3bo7cWNA8YB 44BxwEDQ5oBxwDhgHDAOZC0HDASzdujtxY0DxgHjgHHAQNDmgHHAOGAcMA5kLQcMBLN26O3FjQPG AeOAccBA0OaAccA4YBwwDmQtBwwEs3bo7cWNA8YB44BxwEDQ5oBxwDhgHDAOZC0HDASzdujtxY0D xgHjgHHAQNDmgHHAOGAcMA5kLQcMBLN26O3FjQPGAeOAccBA0OaAccA4YBwwDmQtBwwEs3bo7cWN A8YB44BxwEDQ5oBxwDhgHDAOZC0HDASzdujtxY0DxgHjgHHAQNDmgHHAOGAcMA5kLQcMBLN26O3F jQPGAeOAccBA0OaAccA4YBwwDmQtBwwEs3bo7cWNA8YB44BxwEDQ5oBxwDhgHDAOZC0H/g8Zmj1H 6IyRFAAAAABJRU5ErkJggg== --_004_CBB59BB45B25Djasonlivingoodcablecomcastcom_-- From scott.rose@nist.gov Thu Apr 19 07:50:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8721F85FD for ; Thu, 19 Apr 2012 07:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG56ssTHDlQJ for ; Thu, 19 Apr 2012 07:50:50 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 791EA21F85E3 for ; Thu, 19 Apr 2012 07:50:49 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q3JEocoS029201; Thu, 19 Apr 2012 10:50:39 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Scott Rose In-Reply-To: Date: Thu, 19 Apr 2012 10:50:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0A0D4160-693C-4F1D-89AC-18810F882A7E@nist.gov> References: To: "Livingood, Jason" X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Cc: dnsop Subject: Re: [DNSOP] identitytheft.gov DNSSEC Issue X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:50:55 -0000 According to Verisign's tool, they are ok now: http://dnssec-debugger.verisignlabs.com/identitytheft.gov That png from DNSViz is dated 4/11. Back then they were BOGUS, but I = contacted someone there and they took care of it this week. There were = several FTC owned zones that were BOGUS for a couple of weeks before = they fixed the problem. Scott On Apr 19, 2012, at 10:39 AM, Livingood, Jason wrote: > In case anyone knows the domain admins=85 >=20 > Jason >=20 > On 4/11/12 5:58 PM, "Szymanski, Todd M [NTK]" = wrote: >=20 >> =20 >> >> For those who can=92t see pictures, it=92s identitytheft.gov. Looks = like it=92s been this way for about a week.=20 >> =20 >> =20 >> ____________________________________________ >> Todd Szymanski| Data Network Administration >> Sprint | Service Management=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From jason_livingood@cable.comcast.com Thu Apr 19 07:54:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FFE21F85FC for ; Thu, 19 Apr 2012 07:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.898 X-Spam-Level: X-Spam-Status: No, score=-100.898 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asGoiz4W-32l for ; Thu, 19 Apr 2012 07:54:40 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 856D321F858F for ; Thu, 19 Apr 2012 07:54:40 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.14031306; Thu, 19 Apr 2012 08:41:03 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.02.0283.003; Thu, 19 Apr 2012 10:54:36 -0400 From: "Livingood, Jason" To: Scott Rose Thread-Topic: [DNSOP] identitytheft.gov DNSSEC Issue Thread-Index: AQHNHjpKKApY//pbPUqrIcJQ46KU0paifioA//++CQA= Date: Thu, 19 Apr 2012 14:54:35 +0000 Message-ID: In-Reply-To: <0A0D4160-693C-4F1D-89AC-18810F882A7E@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CBB59F015B274jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: dnsop Subject: Re: [DNSOP] identitytheft.gov DNSSEC Issue X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:54:45 -0000 --_000_CBB59F015B274jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Right you are! Looks to have been repaired between 12:52 UTC and 20:54 UTC = on the 17th when broken: http://dnsviz.net/d/identitytheft.gov/T41nfw/dnssec/ JL On 4/19/12 10:50 AM, "Scott Rose" > wrote: According to Verisign's tool, they are ok now: http://dnssec-debugger.verisignlabs.com/identitytheft.gov That png from DNSViz is dated 4/11. Back then they were BOGUS, but I conta= cted someone there and they took care of it this week. There were several = FTC owned zones that were BOGUS for a couple of weeks before they fixed the= problem. Scott On Apr 19, 2012, at 10:39 AM, Livingood, Jason wrote: In case anyone knows the domain admins=85 Jason On 4/11/12 5:58 PM, "Szymanski, Todd M [NTK]" > wrote: For those who can=92t see pictures, it=92s identitytheft.gov. Looks like i= t=92s been this way for about a week. ____________________________________________ Todd Szymanski| Data Network Administration Sprint | Service Management =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_CBB59F015B274jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5A4E37F376220C4BBEB7B5BDB5B82E65@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Right you= are! Looks to have been repaired between 12:52 UTC and 20:54 UTC on the 17= th

when broken: http://dnsviz.net/d/identitytheft.gov/T41nfw/dnssec/
JL=


On 4/19/= 12 10:50 AM, "Scott Rose" <scott.rose@nist.gov> wrote:

According to Verisign's tool, they are ok now:

That png from DNSViz is dated 4/11.  Back then they were BOG= US, but I contacted someone there and they took care of it this week. =  There were several FTC owned zones that were BOGUS for a couple of we= eks before they fixed the problem.

Scott

On Apr 19, 2012, at 10:39 AM, Livingood, Jason wrote:

In case anyone knows the domain admins=85
Jason
On 4/11/12 5:58 PM, "Szymanski, Todd M [NTK]" <Todd.Szymanski@sprint.com> wrote:=
  
<image003.png>
For those who can=92t see pictures, it=92s identitytheft.gov. &nb= sp;Looks like it=92s been this way for about a week.
  
  
____________________________________________
Todd Szymanski| Data Network Administration
Sprint | Service Management
<ATT00001..c>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST
+1 301-975-8439
Google Voice: +1 571-249-3671
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


--_000_CBB59F015B274jasonlivingoodcablecomcastcom_-- From marc.lampo@eurid.eu Fri Apr 20 04:57:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAF221F8759 for ; Fri, 20 Apr 2012 04:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbYtVka5mAu3 for ; Fri, 20 Apr 2012 04:57:41 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id CCF2C21F84A1 for ; Fri, 20 Apr 2012 04:57:40 -0700 (PDT) X-ASG-Debug-ID: 1334923590-0369490e9ca17a0001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id zJbkQs4AJanisUPF; Fri, 20 Apr 2012 14:06:30 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id EA28DE407A; Fri, 20 Apr 2012 13:57:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7VC2Jqz5mTa; Fri, 20 Apr 2012 13:57:26 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id D6455E4050; Fri, 20 Apr 2012 13:57:26 +0200 (CEST) From: "Marc Lampo" To: "'Livingood, Jason'" , "'dnsop'" References: <003101cd18a6$bf1080e0$3d3182a0$@lampo@eurid.eu> In-Reply-To: Date: Fri, 20 Apr 2012 13:57:26 +0200 (CEST) X-ASG-Orig-Subj: RE: on "Negative Trust Anchors" Message-ID: <009101cd1eec$c12c3f30$4384bd90$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0Ypr7CYVMB+wvKSaa6UhANg27HDADUScOAALy6N8A= Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.59] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1334923590 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: ralf.weber@nominum.com, 'Nick Weaver' Subject: Re: [DNSOP] on "Negative Trust Anchors" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 11:57:41 -0000 Hello, (at the risk of launching a lot of weekend messages, again, - which I read with great interest after some days of absence ...) The draft on "Negative Trust Anchor", section 7 : "Use of a NTA" seems incomplete ! Actually, the validating caching name server is itself only an intermediate step between - the authoritative name servers (whose admins may commit errors) and - the forwarding name server or resolver on an end device. And what if that forwarding name server or that resolver on end device perform validation themselves ? If the "end client" performs validation and is unaware of NTA, it is in trouble again ! And the validating caching name server that implements NTA cannot pretend the DS record, in the parent, does not exist, because it cannot provide the appropriate "Next Secure" data (DNSSEC ...). (the only one that can remove the DS record is the parent - it has the private key to provide the correctly signed "Next Secure" data) While I do acknowledge the concern of ISP's that offer validation to somehow protect their customers, in case of a (DNSSEC only) problem with some or the other domain, I'm afraid "Negative Trust Anchor" may introduce other problems. Together with other commentors on this subject, I do think there should be some best practice recommendation about how to cope with this kind of problem. Kind regards, Marc Lampo -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: 16 April 2012 07:40 PM To: Marc Lampo; dnsop Cc: ralf.weber@nominum.com; Nick Weaver Subject: Re: on "Negative Trust Anchors" Inline. - JL On 4/12/12 8:21 AM, "Marc Lampo" wrote: >The draft of Negative Trust Anchors does not mention anything about >informing the operator of the failing domain. I'll make a note to call this out in the next version. Something about making reasonable attempts to notify the domain of the issue and any action taken (such a using a NTA and when it expires, how to contact party adding the NTA, etc.). >The advantage over negative trust anchor would be that this is more >centrally managed : the action by the parent (remove DS) is visible >(TTL >permitted) to any validating name server. > (the negative trust anchor needs to be configured by every validating NS, > whose administrators bother to do so) I see the advantages but I'm reluctant to see this more automated / easy. Thanks, Jason From simon.perreault@viagenie.ca Tue Apr 24 05:51:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA821F87E4 for ; Tue, 24 Apr 2012 05:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYZ7x5Mg3Akq for ; Tue, 24 Apr 2012 05:51:47 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C735221F8608 for ; Tue, 24 Apr 2012 05:51:47 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:8130:f627:d4d2:65bc]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4DA8B40054 for ; Tue, 24 Apr 2012 08:51:47 -0400 (EDT) Message-ID: <4F96A1E2.9030907@viagenie.ca> Date: Tue, 24 Apr 2012 08:51:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <20120424124644.4369.11101.idtracker@ietfa.amsl.com> In-Reply-To: <20120424124644.4369.11101.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120424124644.4369.11101.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [DNSOP] Fwd: New Version Notification for draft-perreault-dnsop-stats-mib-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:51:48 -0000 Hi, We have just submitted a new draft about a DNS server stats MIB. http://tools.ietf.org/html/draft-perreault-dnsop-stats-mib-00 Any feedback would be appreciated! Thanks, Simon, Jacques, and Jake -------- Original Message -------- Subject: New Version Notification for draft-perreault-dnsop-stats-mib-00.txt Date: Tue, 24 Apr 2012 05:46:44 -0700 From: internet-drafts@ietf.org To: simon.perreault@viagenie.ca CC: jake.zack@cira.ca, jacques.latour@cira.ca A new version of I-D, draft-perreault-dnsop-stats-mib-00.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Filename: draft-perreault-dnsop-stats-mib Revision: 00 Title: DNS Server Statistics Management Information Base (MIB) Creation date: 2012-04-23 WG ID: Individual Submission Number of pages: 17 Abstract: This memo defines a portion of the Management Information Base (MIB) for monitoring statistics of DNS servers. The IETF Secretariat From sra@hactrn.net Tue Apr 24 13:34:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D896221F853E for ; Tue, 24 Apr 2012 13:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KmRUJ5U+cjo for ; Tue, 24 Apr 2012 13:34:23 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 183E521F8533 for ; Tue, 24 Apr 2012 13:34:23 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 24E7728465; Tue, 24 Apr 2012 20:34:21 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EE3F4173B5; Tue, 24 Apr 2012 16:34:20 -0400 (EDT) Date: Tue, 24 Apr 2012 16:34:20 -0400 From: Rob Austein To: Simon Perreault In-Reply-To: <4F96A1E2.9030907@viagenie.ca> References: <20120424124644.4369.11101.idtracker@ietfa.amsl.com> <4F96A1E2.9030907@viagenie.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120424203420.EE3F4173B5@thrintun.hactrn.net> Cc: dnsop@ietf.org Subject: Re: [DNSOP] Fwd: New Version Notification for draft-perreault-dnsop-stats-mib-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 20:34:24 -0000 At Tue, 24 Apr 2012 08:51:46 -0400, Simon Perreault wrote: > We have just submitted a new draft about a DNS server stats MIB. > Any feedback would be appreciated! If you haven't already read RFC 3197, please do so. It's short. From simon.perreault@viagenie.ca Tue Apr 24 13:39:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD8E11E808D for ; Tue, 24 Apr 2012 13:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZZmqKBlWd4c for ; Tue, 24 Apr 2012 13:39:21 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9E011E808A for ; Tue, 24 Apr 2012 13:39:21 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:dd7c:b6ca:a5db:dd69]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5A7F04135B; Tue, 24 Apr 2012 16:39:20 -0400 (EDT) Message-ID: <4F970F77.10002@viagenie.ca> Date: Tue, 24 Apr 2012 16:39:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Rob Austein References: <20120424124644.4369.11101.idtracker@ietfa.amsl.com> <4F96A1E2.9030907@viagenie.ca> <20120424203420.EE3F4173B5@thrintun.hactrn.net> In-Reply-To: <20120424203420.EE3F4173B5@thrintun.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] Fwd: New Version Notification for draft-perreault-dnsop-stats-mib-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 20:39:21 -0000 On 2012-04-24 16:34, Rob Austein wrote: > If you haven't already read RFC 3197, please do so. It's short. We did read it. What we propose is intentionally much simpler. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From A.Hoenes@TR-Sys.de Wed Apr 25 09:59:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B7E21F87A9 for ; Wed, 25 Apr 2012 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.166 X-Spam-Level: X-Spam-Status: No, score=-97.166 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl6vSvTQfQJ8 for ; Wed, 25 Apr 2012 09:59:51 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 73CBA21F87DF for ; Wed, 25 Apr 2012 09:59:49 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA138493111; Wed, 25 Apr 2012 18:58:31 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA13489; Wed, 25 Apr 2012 18:58:29 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204251658.SAA13489@TR-Sys.de> To: vixie@isc.org, kato@wide.ad.jp Date: Wed, 25 Apr 2012 18:58:28 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:59:51 -0000 It has been pointed out that the DNS Referral Response Size Issues I-D should not be left going to final expiry, and I have performed a new review of the last version, draft-ietf-dnsop-respsize-13. I only found a small number of remaining editorial nits -- either formerly overlooked or newly introduced. You might want to take the opportunity of the notes below to refresh the draft. (1) Section 1 (1.1) 1st paragraph a) The object of the first sentence lacks an article; "the" should be supplied. b) In a few places, the draft uses very terse forms of precise citations, which better should be expanded a bit for readability; the first occurrence of this is here as well: "(see [RFC1035] 4.2.1)" should say "(see [RFC1035], Section 4.2.1)" or even better "(see Section 4.2.1 of [RFC1035])" . Chosing the latter form, the corrections will accumulate to: | The original DNS standard limited UDP message size to 512 octets (see | [RFC1035] 4.2.1). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. --- vvvvv | The original DNS standard limited the UDP message size to 512 octets | (see Section 4.2.1 of [RFC1035]). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. (1.2) 2nd paragraph Again, please expand the reference "(see [RFC2671] 2.3, 4.5)" in the same way as above. (1.3) 4th paragraph Again, a definite article is missing, and also whitespace is missing in front of a citation -- both in the first sentence. Please adjust: | While more than twelve years passed since the publication of EDNS0 vv ^ | document[RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. --- | While more than twelve years passed since the publication of the vvv ^^^^ | EDNS0 document [RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. (2) Section 2.3 (2.1) 2nd paragraph When used as a noun, "DNS" should be written with the definite article: | While DNS distinguishes between necessary and optional resource records, [...] --- vvvvv | While the DNS distinguishes between necessary and optional resource records, [...] (2.2) last paragraph There are two grammar flaws in the text. a) s/independent to/independent of/ b) I assume that "... the DNS server _might_ just see ..." is the needed verb that you had in mind. So please correct: | The glue record order should be independent to the version of IP used v ^^ | in the query because the DNS server just see a query from an intermediate server rather than the query from the original client. --- | The glue record order should be independent of the version of IP used vvvvvvv ^^ | in the query because the DNS server might just see a query from an intermediate server rather than the query from the original client. (3) Section 3, last paragraph According to the RFC Editor explanations of the most frequent flaws in grammar and style (see RFC Editor educational presentation material from all recent IETF meetings), "which" is inappropriate in Technical English and should be replaced by "that" here: We're assuming a medium query name size of 64 since that is the typical size seen in trace data at the time of this writing. If | Internationalized Domain Name (IDN) or any other technology which ^^^^^^ results in larger query names be deployed significantly in advance of EDNS, then new measurements and new estimates will have to be made. --- We're assuming a medium query name size of 64 since that is the typical size seen in trace data at the time of this writing. If | Internationalized Domain Name (IDN) or any other technology that results in larger query names be deployed significantly in advance of EDNS, then new measurements and new estimates will have to be made. (4) Section 4 (4.1) 2nd paragraph, last sentence Similar to the above case in Section 1, the text here contains a too terse detailed citation that should be expanded: | [...] See [RFC1996] 2 for more information about stealth servers. --- vvvvvvvvvvvvv v | [...] See Section 2 of [RFC1996] for more information about stealth servers. (4.2) 5th paragraph Here, a comma is missing in front of the (correct) bare "which": More than one address record across protocol families is less likely to lead to or encounter truncation, partly because multiprotocol clients, which are required to handle larger RRsets such as AAAA RRs, | are more likely to speak EDNS which can use a larger UDP response size limit, and partly because the resource records (A and AAAA) are in different RRsets and are therefore divisible from each other. --- More than one address record across protocol families is less likely to lead to or encounter truncation, partly because multiprotocol clients, which are required to handle larger RRsets such as AAAA RRs, | are more likely to speak EDNS, which can use a larger UDP response ^ size limit, and partly because the resource records (A and AAAA) are in different RRsets and are therefore divisible from each other. (4.3) 6th (last) paragraph Again, s/which/that/ : | Name server names which are at or below the zone they serve are more sensitive to referral response truncation, and glue records for them should be considered "more important" than other glue records, in the assembly of referral responses. --- vvvv | Name server names that are at or below the zone they serve are more sensitive to referral response truncation, and glue records for them should be considered "more important" than other glue records, in the assembly of referral responses. (5) Final remark: Depending on the timeline of progress of the drafts, you might want to prepare for a _selective_ reference update from RFC 2671 to RFC 2671bis; this needs some care: - the first ref. to [RFC2671], in the 2nd para od Section 1 should be updated to RFC 2671bis, but - the second ref. to [RFC2671], in the 4th para of Section 1 (see above) should better be left bound to the original document and then changed to clarify the context: | While more than twelve years passed since the publication of the | original EDNS0 document [RFC2671], approximately 65% of the clients ^^^^^^^^^ support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. Hence, [RFC2671bis] needs to be added to the Informative References without deleting the ref. [RFC2671]. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From paul@redbarn.org Wed Apr 25 10:13:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB2621F87FB for ; Wed, 25 Apr 2012 10:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e9nmxcfWq62 for ; Wed, 25 Apr 2012 10:13:44 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id CD68421F86A3 for ; Wed, 25 Apr 2012 10:13:41 -0700 (PDT) Received: from [10.1.22.14] (unknown [207.102.72.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 24F1AEDFCE; Wed, 25 Apr 2012 17:13:41 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F9830BE.5050601@redbarn.org> Date: Wed, 25 Apr 2012 17:13:34 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201204251658.SAA13489@TR-Sys.de> In-Reply-To: <201204251658.SAA13489@TR-Sys.de> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: kato@wide.ad.jp, vixie@isc.org, dnsop@ietf.org Subject: Re: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:13:45 -0000 On 4/25/2012 4:58 PM, Alfred � wrote: > It has been pointed out that the DNS Referral Response Size Issues > I-D should not be left going to final expiry, and I have performed > a new review of the last version, draft-ietf-dnsop-respsize-13. > > I only found a small number of remaining editorial nits -- either > formerly overlooked or newly introduced. You might want to take > the opportunity of the notes below to refresh the draft. thanks. see below. > (1) Section 1 > > (1.1) 1st paragraph > > a) The object of the first sentence lacks an article; "the" should be > supplied. ok. > b) In a few places, the draft uses very terse forms of precise > citations, which better should be expanded a bit for readability; > the first occurrence of this is here as well: > "(see [RFC1035] 4.2.1)" should say > "(see [RFC1035], Section 4.2.1)" or even better > "(see Section 4.2.1 of [RFC1035])" . i don't agree. we'll make the change, since we're not going to stand on minutiae, but for the record this is your personal style preference not an objective style guide reference. i would actually prefer [RFC1035 4.2.1] since terseness is to me virtuous. again: you're over reaching here, but, we'll make the change for you anyway. > Chosing the latter form, the corrections will accumulate to: > > | The original DNS standard limited UDP message size to 512 octets (see > | [RFC1035] 4.2.1). Even though this limitation was due to the > required minimum IP reassembly limit for IPv4, it became a hard DNS > protocol limit and is not implicitly relaxed by changes in a network > layer protocol, for example to IPv6. > --- vvvvv > | The original DNS standard limited the UDP message size to 512 octets > | (see Section 4.2.1 of [RFC1035]). Even though this limitation was > due to the required minimum IP reassembly limit for IPv4, it became a > hard DNS protocol limit and is not implicitly relaxed by changes in a > network layer protocol, for example to IPv6. > > (1.2) 2nd paragraph > > Again, please expand the reference "(see [RFC2671] 2.3, 4.5)" > in the same way as above. > > (1.3) 4th paragraph > > Again, a definite article is missing, and also whitespace is missing > in front of a citation -- both in the first sentence. Please adjust: > > | While more than twelve years passed since the publication of EDNS0 > vv ^ > | document[RFC2671], approximately 65% of the clients support it as > observed at a root name server and this fraction has not changed in > recent few years. The long tail of EDNS deployment may eventually be > measured in decades. > --- > | While more than twelve years passed since the publication of the > vvv ^^^^ > | EDNS0 document [RFC2671], approximately 65% of the clients support it > as observed at a root name server and this fraction has not changed > in recent few years. The long tail of EDNS deployment may eventually > be measured in decades. that's all fine. this, though: > (2) Section 2.3 > > (2.1) 2nd paragraph > > When used as a noun, "DNS" should be written with the definite article: > > | While DNS distinguishes between necessary and optional resource > records, [...] > --- vvvvv > | While the DNS distinguishes between necessary and optional resource > records, [...] "The Domain Name System" as abbreviated to the acronym "DNS" is a proper noun. we do not write "The IP" even though we would write "The Internet Protocol". similarly for TCP, UDP, NFS, and so on. > (2.2) last paragraph > > There are two grammar flaws in the text. > a) s/independent to/independent of/ > b) I assume that "... the DNS server _might_ just see ..." > is the needed verb that you had in mind. > So please correct: > > | The glue record order should be independent to the version of IP used > v ^^ > | in the query because the DNS server just see a query from an > intermediate server rather than the query from the original client. > --- > | The glue record order should be independent of the version of IP used > vvvvvvv ^^ > | in the query because the DNS server might just see a query from an > intermediate server rather than the query from the original client. ok. > (3) Section 3, last paragraph > > According to the RFC Editor explanations of the most frequent flaws > in grammar and style (see RFC Editor educational presentation material > from all recent IETF meetings), "which" is inappropriate in Technical > English and should be replaced by "that" here: > > We're assuming a medium query name size of 64 since that is the > typical size seen in trace data at the time of this writing. If > | Internationalized Domain Name (IDN) or any other technology which > ^^^^^^ > results in larger query names be deployed significantly in advance of > EDNS, then new measurements and new estimates will have to be made. > --- > We're assuming a medium query name size of 64 since that is the > typical size seen in trace data at the time of this writing. If > | Internationalized Domain Name (IDN) or any other technology that > results in larger query names be deployed significantly in advance of > EDNS, then new measurements and new estimates will have to be made. ok. > (4) Section 4 > > (4.1) 2nd paragraph, last sentence > > Similar to the above case in Section 1, the text here contains a > too terse detailed citation that should be expanded: > > | [...] See [RFC1996] 2 for more information about stealth > servers. > --- vvvvvvvvvvvvv v > | [...] See Section 2 of [RFC1996] for more information about > stealth servers. ok. > (4.2) 5th paragraph > > Here, a comma is missing in front of the (correct) bare "which": > > More than one address record across protocol families is less likely > to lead to or encounter truncation, partly because multiprotocol > clients, which are required to handle larger RRsets such as AAAA RRs, > | are more likely to speak EDNS which can use a larger UDP response > size limit, and partly because the resource records (A and AAAA) are > in different RRsets and are therefore divisible from each other. > --- > More than one address record across protocol families is less likely > to lead to or encounter truncation, partly because multiprotocol > clients, which are required to handle larger RRsets such as AAAA RRs, > | are more likely to speak EDNS, which can use a larger UDP response > ^ > size limit, and partly because the resource records (A and AAAA) are > in different RRsets and are therefore divisible from each other. ok. though the construct "xxx, which yyy, which zzz" is itself rather awkward. > (4.3) 6th (last) paragraph > > Again, s/which/that/ : > > | Name server names which are at or below the zone they serve are more > sensitive to referral response truncation, and glue records for them > should be considered "more important" than other glue records, in the > assembly of referral responses. > --- vvvv > | Name server names that are at or below the zone they serve are more > sensitive to referral response truncation, and glue records for them > should be considered "more important" than other glue records, in the > assembly of referral responses. ok. > (5) Final remark: > > Depending on the timeline of progress of the drafts, you might want > to prepare for a _selective_ reference update from RFC 2671 to > RFC 2671bis; this needs some care: > > - the first ref. to [RFC2671], in the 2nd para od Section 1 should be > updated to RFC 2671bis, but > > - the second ref. to [RFC2671], in the 4th para of Section 1 (see above) > should better be left bound to the original document and then changed > to clarify the context: > > | While more than twelve years passed since the publication of the > | original EDNS0 document [RFC2671], approximately 65% of the clients > ^^^^^^^^^ > support it as observed at a root name server and this fraction has > not changed in recent few years. The long tail of EDNS deployment > may eventually be measured in decades. > > Hence, [RFC2671bis] needs to be added to the Informative References > without deleting the ref. [RFC2671]. we depend upon the rfc editor to make such last minute changes since they depend on the order of publication of rfc's. -- "But I'm not done complaining." --Dagon, 2012 From A.Hoenes@TR-Sys.de Wed Apr 25 11:09:14 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E6921F8713 for ; Wed, 25 Apr 2012 11:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.132 X-Spam-Level: X-Spam-Status: No, score=-97.132 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA3NH9RcUHIF for ; Wed, 25 Apr 2012 11:09:14 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 105AC21F872D for ; Wed, 25 Apr 2012 11:09:11 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA138857273; Wed, 25 Apr 2012 20:07:53 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA13801; Wed, 25 Apr 2012 20:07:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204251807.UAA13801@TR-Sys.de> To: paul@redbarn.org Date: Wed, 25 Apr 2012 20:07:51 +0200 (MESZ) In-Reply-To: <4F9830BE.5050601@redbarn.org> from paul vixie at Apr "25, " 2012 "05:13:34" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: kato@wide.ad.jp, vixie@isc.org, dnsop@ietf.org Subject: Re: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:09:14 -0000 Paul, thanks for your expedite response to my review comments. Please see a few inline follow-up remarks below. I have deleted all parts that don't need further elaboration. >> (1) Section 1 >> >> (1.1) 1st paragraph >> >> [...] > >> b) In a few places, the draft uses very terse forms of precise >> citations, which better should be expanded a bit for readability; >> the first occurrence of this is here as well: >> "(see [RFC1035] 4.2.1)" should say >> "(see [RFC1035], Section 4.2.1)" or even better >> "(see Section 4.2.1 of [RFC1035])" . > > i don't agree. we'll make the change, since we're not going to stand on > minutiae, but for the record this is your personal style preference not > an objective style guide reference. i would actually prefer [RFC1035 > 4.2.1] since terseness is to me virtuous. again: you're over reaching > here, but, we'll make the change for you anyway. I have observed various instances of the RFC Editor changing "RFC xxxx, Section yy" to "Section yy of RFC xxxx", and accommodating the preferred style helps to minimize changes of a document at the RFC Editor and thereby to speed up RFC Editor processing of a draft (and less changes for the authors to review in AUTH48), so if an opportunity exists, I try to accommodate RFC Editor preferences in advance and suggest doing so to others. >> [...] > > this, though: > >> (2) Section 2.3 >> >> (2.1) 2nd paragraph >> >> When used as a noun, "DNS" should be written with the definite article: >> >> | While DNS distinguishes between necessary and optional resource >> records, [...] >> --- vvvvv >> | While the DNS distinguishes between necessary and optional resource >> records, [...] > > "The Domain Name System" as abbreviated to the acronym "DNS" is a proper > noun. we do not write "The IP" even though we would write "The Internet > Protocol". similarly for TCP, UDP, NFS, and so on. I indeed found and observed that a few "*P" acronyms have attained that kind of "personality" during long usage (e.g. IP, TCP), but that "System" (as the trailing 'S' in the acronyms under consideration) has not found similar assimilation -- the nouns DNS, NFS, AFS, UMTS, etc. are (still?) usually spelled out in spoken language, at least by people with not so much focus on a specific technology. Further, perhaps non-native speakers of English generally prefer to spell out acronyms -- in particular those in a foreign language -- much more frequently than you may be used to do. But, agreed, opinions may vary. >> [...] >> >> (4) Section 4 >> >> [...] >> >> (4.2) 5th paragraph >> >> Here, a comma is missing in front of the (correct) bare "which": >> >> More than one address record across protocol families is less likely >> to lead to or encounter truncation, partly because multiprotocol >> clients, which are required to handle larger RRsets such as AAAA RRs, >> | are more likely to speak EDNS which can use a larger UDP response >> size limit, and partly because the resource records (A and AAAA) are >> in different RRsets and are therefore divisible from each other. >> --- >> More than one address record across protocol families is less likely >> to lead to or encounter truncation, partly because multiprotocol >> clients, which are required to handle larger RRsets such as AAAA RRs, >> | are more likely to speak EDNS, which can use a larger UDP response >> ^ >> size limit, and partly because the resource records (A and AAAA) are >> in different RRsets and are therefore divisible from each other. > > ok. though the construct "xxx, which yyy, which zzz" is itself rather > awkward. o.k. -- how about this to make it less awkward: ... multiprotocol clients, which are required to handle larger RRsets such as AAAA RRs, | are more likely to speak EDNS in order to be able to use larger UDP | response sizes, and partly because ... >> [...] >> >> (5) Final remark: >> >> Depending on the timeline of progress of the drafts, you might want >> to prepare for a _selective_ reference update from RFC 2671 to >> RFC 2671bis; this needs some care: >> >> - the first ref. to [RFC2671], in the 2nd para of Section 1 should be >> updated to RFC 2671bis, but >> >> - the second ref. to [RFC2671], in the 4th para of Section 1 (see above) >> should better be left bound to the original document and then changed >> to clarify the context: >> >> | While more than twelve years passed since the publication of the >> | original EDNS0 document [RFC2671], approximately 65% of the clients >> ^^^^^^^^^ >> support it as observed at a root name server and this fraction has >> not changed in recent few years. The long tail of EDNS deployment >> may eventually be measured in decades. >> >> Hence, [RFC2671bis] needs to be added to the Informative References >> without deleting the ref. [RFC2671]. > > we depend upon the rfc editor to make such last minute changes since > they depend on the order of publication of rfc's. Well, rfc2671bis is in the IESG and it seems likely that the IESG Comments and the single Discuss could be addressed and resolved in a single additional draft iteration, but the subject draft has not even be forwarded to the IESG with a publication request ... So I guess it's *very* unlikely that the respsize draft catches up so quickly that it surpasses the rfc2671 draft -- and even that could be addressed via clustering in the Queue (leading to coordinated publication). So, upon revising the draft now, you could still add a reference to the rfc2671bis I-D, which later indeed would be fixed up by the RFC Editor to point to the published RFC 2671bis. At least, this should reduce the chances that the argument in the draft gets messed up later by a mechanical switch of the (single) ref. to RFC 2671 to its successor. Kind regards, Alfred. From wmaton@ryouko.imsb.nrc.ca Thu Apr 26 10:10:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9A821F8697 for ; Thu, 26 Apr 2012 10:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OmlAzgCljHr for ; Thu, 26 Apr 2012 10:10:51 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCC821F8694 for ; Thu, 26 Apr 2012 10:10:51 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.5/8.14.4) with ESMTP id q3QHANV4029371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 13:10:28 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.5/8.14.4/Submit) with ESMTP id q3QHANrI029368; Thu, 26 Apr 2012 13:10:23 -0400 Date: Thu, 26 Apr 2012 13:10:23 -0400 (EDT) From: "William F. Maton Sotomayor" To: Joe Abley In-Reply-To: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> Message-ID: References: <2C9D9E11-5618-49A9-8504-2108BA6E6F3C@icann.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-159118721-788058400-1335460223=:19373" Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:10:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---159118721-788058400-1335460223=:19373 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Alright, some time on my plate ... On Wed, 4 Apr 2012, Joe Abley wrote: > > On 2012-04-04, at 08:20, William F. Maton Sotomayor wrote: > >> =09It seems that after delivering my presentation on subsequent AS112 >> delegations in Quebec City, I hadn't recalled what the group thought abo= ut >> adopting this work as a dnsop item. So, I'm soliciting feedback on this >> request. I have posted version 03 for your consideration. > > I think that we need a better mechanism to avoid lame delegations to the = AS112 servers, given their loosely-coordinated nature. The add/drop problem= for those servers (the difficulty in requesting zone changes across from a= potentially wide and unknown population of server administrators, and bein= g effectively unable to measure whether those changes are complete) is a fu= ndamental weakness in the 112 project as it is operated today. > > I like the idea that came up in Qu=E9bec (which I shall attribute to Warr= en Kumari since I've seen other people do that, although I was not in the r= oom at the time) that the add/drop problem is a lot simpler if every AS112 = node hosts the zone +1. It's needs more testing admittedly, and I think having an extra=20 prefix as a test to demonstrate how it would work would be beneficial=20 before operational roll-out, but I'm getting way ahead of this already. As George subsequently stated, there needs to be a deletion process just=20 as there's a removal process. > - update RFC 6304 and 6305 as necessary > - write something that cleans up and unifies the various registries that = currently contain RFC 6303-like names, with appropriate IANA actions (ipv4-= cull contains some references in section 2, see also draft-cheshire-dnsext-= special-names) > - write something that provides guidance for future document authors on w= hen they should specify an IANA action to add a new zone to the grand unifi= ed as112 registry and cause a delegation to "something" and "sensible" to h= appen. > > This document (as112-cull) attempts to do some of this work, but I don't = see a reason to bite off small mouthfuls if we can expend a small amount of= extra effort and eat the whole sandwich at once. Yeah, cull is actually part I of II, the second draft was destined to=20 include a process for adding/removing plus maintaining AS112 servers in=20 general, an exposition on lameness in AS112, etc. But that can be rolled= =20 into a possible bis. > I am very happy to spend time on this. I as well. wfms ---159118721-788058400-1335460223=:19373--