From peter@denic.de Fri Apr 1 02:16:34 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC44E3A679C; Fri, 1 Apr 2011 02:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEFOYb0D+I7b; Fri, 1 Apr 2011 02:16:33 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id DC8A43A6781; Fri, 1 Apr 2011 02:16:32 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Q5aUe-0007to-1A; Fri, 01 Apr 2011 11:18:12 +0200 Received: from localhost by x27.adm.denic.de with local id 1Q5aUd-0007S7-TX; Fri, 01 Apr 2011 11:18:11 +0200 Date: Fri, 1 Apr 2011 11:18:11 +0200 From: Peter Koch To: Ron Bonica Message-ID: <20110401091811.GI26225@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: Dan Romascanu , IETF DNSOP WG , iesg-secretary@ietf.org Subject: [DNSOP] Publication Request (Informational) for X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:16:34 -0000 Ron, hope you are doing well. This is the first of a series of three requests for publication of output of the DNSOP WG. These documents cross reference each other and should preferrably proceed in a bundle. Requests have been split for easier processing. Best regards, Peter ============================================================================= This is a PROTO write up and Request for Publication as INFORMATIONAL for "AS112 Nameserver Operations", . ============================================================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Peter Koch is the document shepherd and believes that this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by a number of WG members who have expressed explicit support for the document. Operators of AS112 nodes have been regularly informed about the draft and changes applied. There are no concerns as to the depth or breadth of reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Only a few WG members have participated in the discussions, but the consensus of those members has been strong. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The nits checker warns about a number of IP addresses and domain names. However, these are meant literally and not as an example and thus are rightfully mentioned in the document. The checker also reports an outdated reference to an Internet Draft (draft-ietf-dnsop-default-local-zones). The updated version of this document has been posted without any changes and a publication request will be sent after this one. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. There are references to two other documents that are being submitted to the IESG at the same time (draft-ietf-dnsop-as112-help-help and draft-ietf-dnsop-default-local-zones). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists it documents an address assignment and a domain name delegation under IANA.ORG that both date way back before the work on this document started. This document does not make any new requests to IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Hosts should never normally send DNS reverse mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely-coordinated effort known as the AS112 project. This document provides background information and technical advice to those firewall operators. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group was supportive of this and the associated AS112 operations document. Nothing particularly controversial came up. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document reflects current practice and operational reality. AS112 nodes are wiedely deployed. ============================================================================= From peter@denic.de Fri Apr 1 02:32:29 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0223A67B7; Fri, 1 Apr 2011 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb0uSEXqYZMv; Fri, 1 Apr 2011 02:32:28 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 9FDF03A67A6; Fri, 1 Apr 2011 02:32:27 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Q5ak3-0007xC-6p; Fri, 01 Apr 2011 11:34:07 +0200 Received: from localhost by x27.adm.denic.de with local id 1Q5ak3-0007eY-3I; Fri, 01 Apr 2011 11:34:07 +0200 Date: Fri, 1 Apr 2011 11:34:07 +0200 From: Peter Koch To: Ron Bonica Message-ID: <20110401093407.GJ26225@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: Dan Romascanu , IETF DNSOP WG , iesg-secretary@ietf.org Subject: [DNSOP] Publication Request (Informational+FYI) for X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:32:29 -0000 Ron, this is the second of a series of three requests for publication of AS112/RFC1918 related documents of the DNSOP WG. Please note that we ask for publication as Informational in the FYI series for this draft. Regards, Peter ============================================================================= This is a PROTO write up and Request for Publication as INFORMATIONAL and FYI for "I'm Being Attacked by PRISONER.IANA.ORG!", . ============================================================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Peter Koch is the document shepherd and believes that this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by a number of WG members who have expressed explicit support for the document. This document is for end user consumption and has been exposed to that target audience occasionally with positive feedback regarding its content and comprehensibility. There are no concerns as to the depth or breadth of reviews, but we are looking forward to the GenART review in particular. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Only a few WG members have participated in the discussions, but the consensus of those members has been overwhelmingly positive. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The nits checker warns about a number of IP addresses and domain names. However, these are meant literally and not as an example and thus are rightfully mentioned in the document. The checker also reports an outdated reference to an Internet Draft (draft-ietf-dnsop-default-local-zones). The updated version of this document has been posted without any changes and a publication request will be sent after this one. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. There are references to two other documents that are being submitted to the IESG at the same time (draft-ietf-dnsop-as112-ops and draft-ietf-dnsop-default-local-zones). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists for explanatory purposes only and should remain in the document. The document itself does not make any requests of IANA. document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group was supportive of this and the associated AS112 operations document. Nothing particularly controversial came up. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document is for end user consumption. ============================================================================= From peter@denic.de Fri Apr 1 03:43:58 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFB53A67D3; Fri, 1 Apr 2011 03:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbm01mTreycZ; Fri, 1 Apr 2011 03:43:55 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 53AC63A67E1; Fri, 1 Apr 2011 03:43:55 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Q5brC-0008M8-NA; Fri, 01 Apr 2011 12:45:34 +0200 Received: from localhost by x27.adm.denic.de with local id 1Q5brC-00009B-Ij; Fri, 01 Apr 2011 12:45:34 +0200 Date: Fri, 1 Apr 2011 12:45:34 +0200 From: Peter Koch To: Ron Bonica Message-ID: <20110401104534.GK26225@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: Dan Romascanu , IETF DNSOP WG , iesg-secretary@ietf.org Subject: [DNSOP] Publication Request (BCP) for X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:43:58 -0000 Ron, this is the third and final publication request in a series of DNSOP deliverables. We would like to request the publication of "Locally-served DNS Zones" as a "Best Current Practice" (BCP) RFC. Regards, Peter ============================================================================= This is a PROTO write up and Request for Publication as BEST CURRENT PRACTICE for "Locally-served DNS Zones" ============================================================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Peter Koch is the document shepherd and believes that this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by a number of WG members who have expressed explicit support for the document. There are no concerns as to the depth or breadth of reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Many members of the DNS operational community have supported this approach, including operators of the infrastructure (AS112, IN-ADDR.ARPA) that is currently affected by the query leakage to be addressed by this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The nits checker warns about one IP addresses appearing literally. Since it is not meant as an example and is rightfully mentioned in the document, this warning can be ignored. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. There are references to two other documents that are being submitted to the IESG at the same time (draft-ietf-dnsop-as112-help-help and draft-ietf-dnsop-as112-ops). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This document defines an IANA registry for "locally served zones". It specifies the registration policy and the seed values. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The working group strong but not unanimous consensus. Discussion arose around how exactly to seed the IANA registry that defines the list of zones to locally serve. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are name server implementations that already use the feature described in this document. ============================================================================= From mayer@ntp.org Sun Apr 3 10:51:38 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFE73A6875; Sun, 3 Apr 2011 10:51: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMMUztkLVHmQ; Sun, 3 Apr 2011 10:51:36 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by core3.amsl.com (Postfix) with ESMTP id 502483A6864; Sun, 3 Apr 2011 10:51:36 -0700 (PDT) Received: from cust-63-209-225-22.bos-dynamic.gis.net ([63.209.225.22] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q6RTz-000KeV-B2; Sun, 03 Apr 2011 17:53:14 +0000 Message-ID: <4D98B444.1040204@ntp.org> Date: Sun, 03 Apr 2011 13:54:12 -0400 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Bashinski References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> In-Reply-To: <4D472D2C.9090108@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.225.22 X-SA-Exim-Rcpt-To: jbash@cisco.com, dnsop@ietf.org, dnsext@ietf.org, stenn@ntp.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Sun, 03 Apr 2011 15:32:50 -0700 Cc: Harlan Stenn , "dnsop@ietf.org WG" , dnsext List Subject: Re: [DNSOP] [dnsext] draft-jabley-dnsop-validator-bootstrap-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mayer@ntp.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 17:51:38 -0000 Hi John, I just saw this, so sorry for the late response. See inline for comments. Danny On 1/31/2011 4:44 PM, John Bashinski wrote: > On 2011-01-31 14:32, Joe Abley wrote: > Time > ==== > >> 3.1 Initial State >> [...] >> A validator must confirm that its local clock is sufficiently >> accurate before trust anchors can be established, and before >> processing of DNSSEC signatures can proceed. Discussion of timing >> considerations can be found in Section 4. > > How? > > I know I brought it up, but I'm getting a little nervous about using the > home router as the only reference point. Nonetheless, it's a good > paradigmatic case, and I'll go with it for now. You're a home > router. You've just been plugged in, either new from the box or after > being in a closet for a long time. Do you: > > 1. Rely on your local real-time clock? I'm not saying this is impossible, > but: > > a. Much existing hardware (not just Linksys; many home routers) > doesn't have RTCs. Putting one in would significantly increase the > build cost of the hardware, I'm guessing by several percent. > And it would reduce the reliability and shelf life. > > b. If you've been in a closet for a while, your RTC may have drifted > enough to matter. Perhaps more likely, the battery for your > RTC may have died... an event you may or may not be able to detect > and usually can't report. > > c. The user may have set the RTC wrong before you went into that > closet. This is perhaps more likely for a PC than for a router, > but it could happen... and PCs are also in scope. > > 2. Rely on NTP? If so, then: > > a. How do you know which NTP sources to trust? > b. How do you set up authentication with them? > > Public NTP is unauthenticated, and if I remember correctly it's not > *possible* to authenticate NTP in a public network. The public-key > stuff is used to distribute shared keys. I could be wrong; it's > been a while. But that's how I remember it. Anyway, you'd need some > kind of NTP trust anchor... which puts us back where we started. > While generally people are not doing authentication publicly there is no reason why they cannot do do. NTP Autokey has been around for a long time, probably about 15 years, the latest RFC is RFC5906. The one problem you have is that you need to provision a key, OOB, to be able to authenticate the server and you will have to know what servers to point to to get the NTP packets. If you cannot enter FQDN's, because the servers being pointed to may change addresses and you cannot yet look them up as DNS is not available to you, then you are forced to use IP addresses. The good news is that NTP does not require that initially your local time have a valid time as long it's within 68 years. If your device clock doesn't have an RTC you could always set it initially to the build date and then have NTP set it from there. > 3. GPS? WWVB (or non-US equivalent)? Can't receive either one where my > router is, even if it had the hardware. And both are jammable. WWVB, > at least, is easily falsified, as are the similar but incompatible > systems in use in various places outside North America... those where > such systems exists, that is. I haven't looked into GPS, but I suspect > it's spoofable too. > That would imply that you have an antenna connected to your router. On a home router I don't think so and there are some places that couldn't even receive a signal even if it did. > 4. Make the user enter the time? How does the user know she needs to > do that? > > For us, another question is how we keep the user from buying the > competitor's box that doesn't do DNSSEC and doesn't ask for the > time. Users see all this stuff as a hassle. I was told today > that even entering a PIN to get WiFi up causes a noticeable number > of products to go back to the store. > > The state of the art in enterprise networks is *unauthenticated* NTP > with internal hosts. The state of the art in consumer is unauthenticated > NTP with a pool on the public Internet. > No, state of the art is authenticated NTP. The state of operational art is unauthenticated NTP. > This is a huge problem for us with bootstrapping all kinds of crypto > protocols, actually, not just DNSSEC. There's this pervasive assumption > that the time of day is not only known, but known with such certainty > that it can be trusted to ensure the security of systems that are > otherwise engineered to take CPU-aeons to compromise. The problem is > that it's just not an assumption we know how to meet. > Autokey is one of those which requires a key provided out-of-band on the device just to be able to authenticate the servers and you may need one for each server. Autokey is unique in that it is not an accurate time-dependent authentication protocol for obvious reasons. > In a lot of cases, we just end up having to assume that keys are valid > from the beginning of time to the end of time. I'd very much like to not > have that be true, but I don't know how to fix it. > > I could imagine a distributed system of digital notaries and time > stampers that at least let you establish that it was "no earlier than" > some particular time, and that also gave you some assurance that some > set of past events had happened in a particular sequence and within > particular time parameters. You could build that with mutually > distrustful "authorities", and use a quorum or something to prevent any > one of them from messing it up. I think that sort of thing is (part of) > what Phillip Hallam-Baker is getting at. But I'm not sure we can deploy > it sanely in time to be useful for this application... and I don't > think you can build *anything* that lets you detect lies about the > time if an attacker controls *all* your communications. If you use NTP for accurate time you should provision a minimum of 3 NTP servers to point to and generally 4. In your specific situation I'd recommend 5. Danny From bortzmeyer@nic.fr Sat Apr 9 13:10:30 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756393A69BE for ; Sat, 9 Apr 2011 13:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.174 X-Spam-Level: X-Spam-Status: No, score=-110.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHk4cSVuBHYA for ; Sat, 9 Apr 2011 13:10:29 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id 0C5A93A69BD for ; Sat, 9 Apr 2011 13:10:28 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id D2DB91C00F3; Sat, 9 Apr 2011 22:12:13 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id CE03E1C00DF; Sat, 9 Apr 2011 22:12:13 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C1E3E7B00DF; Sat, 9 Apr 2011 22:12:13 +0200 (CEST) Date: Sat, 9 Apr 2011 22:12:13 +0200 From: Stephane Bortzmeyer To: Peter Koch Message-ID: <20110409201213.GA20082@nic.fr> References: <20110401091811.GI26225@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110401091811.GI26225@x27.adm.denic.de> X-Operating-System: Debian GNU/Linux 6.0 X-Kernel: Linux 2.6.32-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Publication Request (Informational) for X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:10:30 -0000 On Fri, Apr 01, 2011 at 11:18:11AM +0200, Peter Koch wrote a message of 175 lines which said: > This is a PROTO write up and Request for Publication as INFORMATIONAL for > "AS112 Nameserver Operations", . Funny but, as reported on OARC's dns-operations, at this time, ARIN name servers had already drop 168.192.in-addr.arpa.... % dig @x.arin.net NS 168.192.in-addr.arpa. ; <<>> DiG 9.7.2-P3 <<>> @x.arin.net NS 168.192.in-addr.arpa. ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17956 ... From peter@denic.de Mon Apr 11 01:18:44 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55CFE3A6AEA for ; Mon, 11 Apr 2011 01:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2yW8gkfd+KT for ; Mon, 11 Apr 2011 01:18:43 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id A26853A6AE9 for ; Mon, 11 Apr 2011 01:18:42 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Q9CKY-0004U7-8A; Mon, 11 Apr 2011 10:18:42 +0200 Received: from localhost by x27.adm.denic.de with local id 1Q9CKY-0005a4-4O; Mon, 11 Apr 2011 10:18:42 +0200 Date: Mon, 11 Apr 2011 10:18:42 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20110411081842.GT1366@x27.adm.denic.de> References: <20110401091811.GI26225@x27.adm.denic.de> <20110409201213.GA20082@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110409201213.GA20082@nic.fr> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [DNSOP] Publication Request (Informational) for X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 08:18:44 -0000 Stephane, thanks for the heads up. On Sat, Apr 09, 2011 at 10:12:13PM +0200, Stephane Bortzmeyer wrote: > > This is a PROTO write up and Request for Publication as INFORMATIONAL for > > "AS112 Nameserver Operations", . > > Funny but, as reported on OARC's dns-operations, at this time, ARIN > name servers had already drop 168.192.in-addr.arpa.... pending detailed information all we can say is that these undelegations were accidental rather than deliberate. The delegations have been re- instantiated and their temporary absence should not be interpreted as a statement in the direction of AS112. If you think there is anything for this WG to do w.r.t. the draft mentioned above, please feel free to elaborate. -Peter From iesg-secretary@ietf.org Mon Apr 11 09:04:09 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FEFD28C135; Mon, 11 Apr 2011 09:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjDmRoezMqg6; Mon, 11 Apr 2011 09:04:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6134728C13A; Mon, 11 Apr 2011 09:04:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110411160408.30907.33009.idtracker@localhost> Date: Mon, 11 Apr 2011 09:04:08 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] Last Call: (I'm Being Attacked by PRISONER.IANA.ORG!) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:04:09 -0000 The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'I'm Being Attacked by PRISONER.IANA.ORG!' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-under-attack-help-help/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-under-attack-help-help/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Apr 11 11:50:39 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E3E3A69A8; Mon, 11 Apr 2011 11:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdCWPfJqTitP; Mon, 11 Apr 2011 11:50:38 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883183A6B2D; Mon, 11 Apr 2011 11:50:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110411185038.11834.21660.idtracker@localhost> Date: Mon, 11 Apr 2011 11:50:38 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] Last Call: (AS112 Nameserver Operations) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:50:39 -0000 The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'AS112 Nameserver Operations' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-ops/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-ops/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Apr 11 11:51:28 2011 Return-Path: X-Original-To: dnsop@core3.amsl.com Delivered-To: dnsop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02643A6B2F; Mon, 11 Apr 2011 11:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqg+Niz7Ol09; Mon, 11 Apr 2011 11:51:28 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90773A6A47; Mon, 11 Apr 2011 11:51:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110411185127.11834.137.idtracker@localhost> Date: Mon, 11 Apr 2011 11:51:27 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] Last Call: (Locally-served DNS Zones) to BCP X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:51:29 -0000 The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Locally-served DNS Zones' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsop-default-local-zones/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsop-default-local-zones/ No IPR declarations have been submitted directly on this I-D. From johnl@iecc.com Wed Apr 13 11:04:55 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C710BE083D for ; Wed, 13 Apr 2011 11:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EB4B6STlD53 for ; Wed, 13 Apr 2011 11:04:55 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfc.amsl.com (Postfix) with ESMTP id C6396E080B for ; Wed, 13 Apr 2011 11:04:54 -0700 (PDT) Received: (qmail 14745 invoked from network); 13 Apr 2011 18:04:53 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 Apr 2011 18:04:53 -0000 Date: 13 Apr 2011 18:04:31 -0000 Message-ID: <20110413180431.96986.qmail@joyce.lan> From: "John Levine" To: dnsop@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [DNSOP] Do negative cache entries have to be consistent ? 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, 13 Apr 2011 18:04:55 -0000 Some friends of mine who run DNSBLs have this idea to manage the traffic to their servers: some parts of the IP address space are more likely to get infected than others, so when they send back a NXDOMAIN response, they want to adjust the TTL so that addreses that are unlikely to get listed have a longer TTL and addresses that are more likely to become listed have a shorter TTL. Since the TTL on a negative cache entry comes from the TTL on the SOA returned with the NXDOMAIN, this means that they'll be returning SOAs with different TTLs on different responses. This strikes me as something that's not technically illegal, but that people who write DNS caches didn't anticipate. Is it likely to break anything? Bonus question: with DNSSEC, a cache can use NSEC info to synthesize NXDOMAIN responses for nearby addresses. Will inconsistent TTLs break anything then? If you think this is a stupid idea, please say why. Traffic to DNSBL servers is significant, and traces suggest this will noticably decrease the traffic, so unless it breaks something, it's useful. They realize that there is some possibility of stale data, but that's a given whenever a TTL is greater than zero. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly PS: If you were planning to say that all DNSBLs stink, don't. We know they do, but the alternative stinks worse. From ajs@shinkuro.com Wed Apr 13 11:17:39 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7A3CE07AA for ; Wed, 13 Apr 2011 11:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj1ZlBSGNR5B for ; Wed, 13 Apr 2011 11:17:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id 60978E0697 for ; Wed, 13 Apr 2011 11:17:39 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 904BB1ECB420 for ; Wed, 13 Apr 2011 18:17:38 +0000 (UTC) Date: Wed, 13 Apr 2011 14:17:37 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20110413181736.GY24471@crankycanuck.ca> References: <20110413180431.96986.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110413180431.96986.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] Do negative cache entries have to be consistent ? 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, 13 Apr 2011 18:17:40 -0000 On Wed, Apr 13, 2011 at 06:04:31PM -0000, John Levine wrote: > Since the TTL on a negative cache entry comes from the TTL on the SOA > returned with the NXDOMAIN, this means that they'll be returning SOAs > with different TTLs on different responses. This strikes me as > something that's not technically illegal, but that people who write > DNS caches didn't anticipate. Is it likely to break anything? Strictly, the TTL on a negative cache entry comes from the minimum of the TTL of the SOA and the SOA.MINIMUM subfield. So the strategy won't work if the latter is too low. I'll ignore that and just assume you're dealing with it. In principle, a cache will need to be able to cope with the possibility that the TTL will change on a record in between times the cache looked. That's for two reasons: the authoritative server's records could change, or there could be a cache in between. It strikes me that a cache might not actually overwrite its negative cache for a zone if it already has a negative TTL longer than the one it gets in a given answer, on the grounds that having been given the longer TTL before it is permitted to continue using that. So I think you'll probably need to test widely in order to learn whether your strategy will actually work in practice. > Bonus question: with DNSSEC, a cache can use NSEC info to synthesize > NXDOMAIN responses for nearby addresses. Will inconsistent TTLs break > anything then? I think you'd have to ask implementers of such synthesizing caches. But I can't see how. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From george.barwood@blueyonder.co.uk Wed Apr 13 12:41:06 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE2C7E0796 for ; Wed, 13 Apr 2011 12:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.319 X-Spam-Level: X-Spam-Status: No, score=0.319 tagged_above=-999 required=5 tests=[AWL=1.165, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtAreSf7yueV for ; Wed, 13 Apr 2011 12:41:05 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by ietfc.amsl.com (Postfix) with ESMTP id 63043E0785 for ; Wed, 13 Apr 2011 12:41:05 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.4]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110413194101.WENH13167.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Wed, 13 Apr 2011 20:41:01 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QA5vx-0007ww-LD; Wed, 13 Apr 2011 20:41:01 +0100 Message-ID: From: "George Barwood" To: "John Levine" , References: <20110413180431.96986.qmail@joyce.lan> Date: Wed, 13 Apr 2011 20:43:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=7xR6hbR8plwA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=QLhupLqRAAAA:8 a=48vgC7mUAAAA:8 a=3DW5ysfuAAAA:8 a=HHdnZQ_pAAAA:8 a=s0iCFRxmfHtHE5Gl8DkA:9 a=xNA6PKZhRlGkchbVUiEA:7 a=wPNLvfGTeEIA:10 a=EzGVmGvcixYA:10 a=lZB815dzVvQA:10 a=2SAumGWBsQEA:10 a=3DAnmEeMdI8GEcvH:21 a=MaQDX6T7oAPbBYdH:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [DNSOP] Do negative cache entries have to be consistent ? 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, 13 Apr 2011 19:41:06 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gTGV2aW5lIiA8am9o bmxAdGF1Z2guY29tPg0KVG86IDxkbnNvcEBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMTMsIDIwMTEgNzowNCBQTQ0KU3ViamVjdDogW0ROU09QXSBEbyBuZWdhdGl2ZSBjYWNoZSBl bnRyaWVzIGhhdmUgdG8gYmUgY29uc2lzdGVudCA/DQoNCg0KPiBTb21lIGZyaWVuZHMgb2YgbWlu ZSB3aG8gcnVuIEROU0JMcyBoYXZlIHRoaXMgaWRlYSB0byBtYW5hZ2UgdGhlDQo+IHRyYWZmaWMg dG8gdGhlaXIgc2VydmVyczogc29tZSBwYXJ0cyBvZiB0aGUgSVAgYWRkcmVzcyBzcGFjZSBhcmUg bW9yZQ0KPiBsaWtlbHkgdG8gZ2V0IGluZmVjdGVkIHRoYW4gb3RoZXJzLCBzbyB3aGVuIHRoZXkg c2VuZCBiYWNrIGEgTlhET01BSU4NCj4gcmVzcG9uc2UsIHRoZXkgd2FudCB0byBhZGp1c3QgdGhl IFRUTCBzbyB0aGF0IGFkZHJlc2VzIHRoYXQgYXJlDQo+IHVubGlrZWx5IHRvIGdldCBsaXN0ZWQg aGF2ZSBhIGxvbmdlciBUVEwgYW5kIGFkZHJlc3NlcyB0aGF0IGFyZSBtb3JlDQo+IGxpa2VseSB0 byBiZWNvbWUgbGlzdGVkIGhhdmUgYSBzaG9ydGVyIFRUTC4NCj4gDQo+IFNpbmNlIHRoZSBUVEwg b24gYSBuZWdhdGl2ZSBjYWNoZSBlbnRyeSBjb21lcyBmcm9tIHRoZSBUVEwgb24gdGhlIFNPQQ0K PiByZXR1cm5lZCB3aXRoIHRoZSBOWERPTUFJTiwgdGhpcyBtZWFucyB0aGF0IHRoZXknbGwgYmUg cmV0dXJuaW5nIFNPQXMNCj4gd2l0aCBkaWZmZXJlbnQgVFRMcyBvbiBkaWZmZXJlbnQgcmVzcG9u c2VzLiAgVGhpcyBzdHJpa2VzIG1lIGFzDQo+IHNvbWV0aGluZyB0aGF0J3Mgbm90IHRlY2huaWNh bGx5IGlsbGVnYWwsIGJ1dCB0aGF0IHBlb3BsZSB3aG8gd3JpdGUNCj4gRE5TIGNhY2hlcyBkaWRu J3QgYW50aWNpcGF0ZS4gIElzIGl0IGxpa2VseSB0byBicmVhayBhbnl0aGluZz8NCg0KSXQgc2hv dWxkIGJlIGZpbmUgd2l0aCBtb2Rlcm4gY2FjaGVzLiBUaGUgd2F5IGNhY2hlcyBhcmUgbWVhbnQg dG8gd29yayBhY2NvcmRpbmcgdG8gdGhlDQpETlNTRUMgc3RhbmRhcmQgaXMgdGhhdCB0aGUgY29t cGxldGUgcmVzcG9uc2UgaXMgY2FjaGVkIGFzIHNpbmdsZSBhdG9taWMgZW50cnksDQpjb21wbGV0 ZSB3aXRoIGFueSBhc29jaWF0ZWQgU09BL05TRUMgcmVjb3Jkcy4NCg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNDAzNSNzZWN0aW9uLTQuNQ0KDQpUaGUgVFRMIGlzIGRlcml2ZWQgZnJv bSB0aGUgU09BIG1pbmltdW4gYW5kIHRoZSBsb3dlc3QgVFRMIGluIHRoZSBSUnNldHMgc2VudC4N ClNvIHRoaXMgYmVoYXZpb3IgaXMgbm90IGF0IGFsbCB1bmFudGljaXBhdGVkIEkgdGhpbmsuDQoN Cj4gQm9udXMgcXVlc3Rpb246IHdpdGggRE5TU0VDLCBhIGNhY2hlIGNhbiB1c2UgTlNFQyBpbmZv IHRvIHN5bnRoZXNpemUNCj4gTlhET01BSU4gcmVzcG9uc2VzIGZvciBuZWFyYnkgYWRkcmVzc2Vz LiAgV2lsbCBpbmNvbnNpc3RlbnQgVFRMcyBicmVhaw0KPiBhbnl0aGluZyB0aGVuPw0KDQpOb3Qg YXQgcHJlc2VudC4gSG93ZXZlciB0aGVyZSBhcmUgc3VnZ2VzdGlvbnMgdGhhdCBpZiBhIHBhcmVu dCBOWERPTUFJTiBpcyBmb3VuZCwNCml0IGNvdWxkIGltcGx5IHRoYXQgYWxsIHRoZSByZXNwb25z ZXMgZGVzY2VuZGVkIGZvcm0gdGhhdCBjb3VsZCBiZSBhc3N1bWVkIHRvIGJlIE5YRE9NQUlOLg0K VGhpcyBpcyBub3QgeWV0IHBhcnQgb2YgdGhlIHN0YW5kYXJkIHRob3VnaCwgYW5kIGluIGZhY3Qg b2xkIGF1dGhvcml0YXRpdmUgbmFtZXNlcnZlcnMgc29tZXRpbWVzDQpyZXR1cm4gTlhET01BSU4g ZXZlbiB3aGVuIHRoZXJlIGFyZSBjaGlsZHJlbiwgc28gaW4gcHJhY3RpY2UgaXQgdGhzIHdpbGwg cHJvYmFibHkgaGF2ZQ0KdG8gYmUgcmVzdHJpY3RlZCB0byBETlNTRUMuDQoNCj4gSWYgeW91IHRo aW5rIHRoaXMgaXMgYSBzdHVwaWQgaWRlYSwgcGxlYXNlIHNheSB3aHkuICBUcmFmZmljIHRvIERO U0JMDQo+IHNlcnZlcnMgaXMgc2lnbmlmaWNhbnQsIGFuZCB0cmFjZXMgc3VnZ2VzdCB0aGlzIHdp bGwgbm90aWNhYmx5DQo+IGRlY3JlYXNlIHRoZSB0cmFmZmljLCBzbyB1bmxlc3MgaXQgYnJlYWtz IHNvbWV0aGluZywgaXQncyB1c2VmdWwuDQo+IFRoZXkgcmVhbGl6ZSB0aGF0IHRoZXJlIGlzIHNv bWUgcG9zc2liaWxpdHkgb2Ygc3RhbGUgZGF0YSwgYnV0IHRoYXQncw0KPiBhIGdpdmVuIHdoZW5l dmVyIGEgVFRMIGlzIGdyZWF0ZXIgdGhhbiB6ZXJvLg0KPiANCj4gUmVnYXJkcywNCj4gSm9obiBM ZXZpbmUsIGpvaG5sQGllY2MuY29tLCBQcmltYXJ5IFBlcnBldHJhdG9yIG9mICJUaGUgSW50ZXJu ZXQgZm9yIER1bW1pZXMiLA0KPiBQbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9y ZSByZWFkaW5nIHRoaXMgZS1tYWlsLiBodHRwOi8vamwubHkNCj4gDQo+IFBTOiBJZiB5b3Ugd2Vy ZSBwbGFubmluZyB0byBzYXkgdGhhdCBhbGwgRE5TQkxzIHN0aW5rLCBkb24ndC4gIFdlIGtub3cN Cj4gdGhleSBkbywgYnV0IHRoZSBhbHRlcm5hdGl2ZSBzdGlua3Mgd29yc2UuDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBETlNPUCBtYWls aW5nIGxpc3QNCj4gRE5TT1BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbnNvcA== From johnl@taugh.com Wed Apr 13 13:11:26 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F393FE088E for ; Wed, 13 Apr 2011 13:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.199 X-Spam-Level: X-Spam-Status: No, score=-11.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1Yo8ogb087M for ; Wed, 13 Apr 2011 13:11:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfc.amsl.com (Postfix) with ESMTP id 98379E088D for ; Wed, 13 Apr 2011 13:11:22 -0700 (PDT) Received: (qmail 48247 invoked from network); 13 Apr 2011 20:11:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=bc76.4da60369.k1104; i=johnl@submit.iecc.com; bh=tPhtIqghoSnWD19qkYZmDn8aCr1SDyGh37j+TCZqmJA=; b=UWoLdel8Q2UWN2UoDBc3tE4hRWcIdH3WoFHN2BHFbZlTcW+Et8TNC93BRm7Rp/ThJvqhRd20iLJoun+DVOer/98l93+15qAFa3pdHs7VylBSF68kJ+HrXnZMCFcF422uY3Slotom1QGmQ/thq0YNeZekgh7gSNDJX/jOrIZLCBU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=bc76.4da60369.k1104; olt=johnl@submit.iecc.com; bh=tPhtIqghoSnWD19qkYZmDn8aCr1SDyGh37j+TCZqmJA=; b=L8Hl4FFNaKYSVzigksNHDCWlKLsg+4D93JmXrN1jeVYGlAfvB2h94pYTjh+MQ4VfHtgJ0PD5lG4kzmCpSXQNagtq4gujfwE7lzcKFbp6hBGDmnOcGmCll2kAUPFdglB8akeIzUMB+036vBaFywk27uSX05G4j4KC7mMCKYuQ5gA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Apr 2011 20:10:59 -0000 Date: 13 Apr 2011 16:11:20 -0400 Message-ID: From: "John R Levine" To: "George Barwood" In-Reply-To: References: <20110413180431.96986.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Do negative cache entries have to be consistent ? 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, 13 Apr 2011 20:11:26 -0000 > It should be fine with modern caches. The way caches are meant to work according to the > DNSSEC standard is that the complete response is cached as single atomic entry, > complete with any asociated SOA/NSEC records. Tnx. > This is not yet part of the standard though, and in fact old > authoritative nameservers sometimes return NXDOMAIN even when there are > children, so in practice it ths will probably have to be restricted to > DNSSEC. Oh, I know. I'm trying to figure out how to fix rbldnsd. R's, John From dhc2@dcrocker.net Wed Apr 13 13:59:04 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76BA2E07D9 for ; Wed, 13 Apr 2011 13:59:04 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffpBUiluPWpn for ; Wed, 13 Apr 2011 13:59:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfc.amsl.com (Postfix) with ESMTP id 64D7AE05F5 for ; Wed, 13 Apr 2011 13:59:03 -0700 (PDT) Received: from [192.168.1.12] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p3DKwvmD003648 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 13 Apr 2011 13:59:02 -0700 Message-ID: <4DA60E90.5060906@dcrocker.net> Date: Wed, 13 Apr 2011 13:58:56 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: dnsop@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2011 13:59:02 -0700 (PDT) Subject: [DNSOP] Fwd: I-D Action:draft-crocker-dns-attrleaf-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:59:04 -0000 FYI. Extensive enhancement to the registry table. d/ -------- Original Message -------- Subject: I-D Action:draft-crocker-dns-attrleaf-05.txt Date: Tue, 12 Apr 2011 19:45:02 -0700 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS Scoped Data Through Attribute Leaves Author(s) : D. Crocker Filename : draft-crocker-dns-attrleaf-05.txt Pages : 16 Date : 2011-04-12 Historically, any DNS RR may occur for any domain name. Recent additions have defined DNS leaf nodes that contain a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for DNS records associated with the parent domain. This note explores the nature of this DNS usage and defines the "underscore names" registry with IANA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crocker-dns-attrleaf-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From fweimer@bfk.de Thu Apr 14 00:00:45 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ECE47E0687 for ; Thu, 14 Apr 2011 00:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUxQiw4rxeBw for ; Thu, 14 Apr 2011 00:00:45 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfc.amsl.com (Postfix) with ESMTP id 4E878E065A for ; Thu, 14 Apr 2011 00:00:44 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QAGXh-0007V8-Md; Thu, 14 Apr 2011 07:00:41 +0000 Received: by bfk.de with local id 1QAGXh-0002pD-HX; Thu, 14 Apr 2011 07:00:41 +0000 To: "John Levine" References: <20110413180431.96986.qmail@joyce.lan> From: Florian Weimer Date: Thu, 14 Apr 2011 07:00:41 +0000 In-Reply-To: <20110413180431.96986.qmail@joyce.lan> (John Levine's message of "13 Apr 2011 18\:04\:31 -0000") Message-ID: <82zkntl3l2.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsop@ietf.org Subject: Re: [DNSOP] Do negative cache entries have to be consistent ? 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, 14 Apr 2011 07:00:46 -0000 * John Levine: > Since the TTL on a negative cache entry comes from the TTL on the SOA > returned with the NXDOMAIN, this means that they'll be returning SOAs > with different TTLs on different responses. This strikes me as > something that's not technically illegal, but that people who write > DNS caches didn't anticipate. Is it likely to break anything? > > Bonus question: with DNSSEC, a cache can use NSEC info to synthesize > NXDOMAIN responses for nearby addresses. Will inconsistent TTLs break > anything then? You can avoid both issues by introducing sub-zones for the network ranges which should receive longer TTLs. In the non-DNSSEC case, you can simply return a SOA record whose owner name is the full QNAME. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From peter@denic.de Mon Apr 18 10:41:40 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C192E06F7 for ; Mon, 18 Apr 2011 10:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Saz45aVugdXm for ; Mon, 18 Apr 2011 10:41:39 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by ietfc.amsl.com (Postfix) with ESMTP id BDEB2E066B for ; Mon, 18 Apr 2011 10:41:39 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1QBsSA-00075J-BL; Mon, 18 Apr 2011 19:41:38 +0200 Received: from localhost by x27.adm.denic.de with local id 1QBsSA-0004q2-7f; Mon, 18 Apr 2011 19:41:38 +0200 Date: Mon, 18 Apr 2011 19:41:38 +0200 From: Peter Koch To: IETF DNSOP WG Message-ID: <20110418174138.GH22688@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [DNSOP] WGLC [2011-05-17] 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, 18 Apr 2011 17:41:40 -0000 Dear DNSOP WG, this is to initiate a working group last call (WGLC) on "DNSSEC Operational Practices, Version 2" Owing to the length of the document, the WGLC will last for four weeks instead of the usual two, and will therefore end on Tuesday, 17 May, 23:59 UTC. The IETF tools site gives easy access to the current and previous versions as well as differences and the like at . The document is aimed at a status of "Informational". Please review the document and send any comments you may have to the list. If you have no comments but support (or do not support) the document being published, please send that information to the list. The document is subject to the normal five reviewer threshold. Stephen and Peter DNSOP co-chairs From george.barwood@blueyonder.co.uk Mon Apr 18 12:00:38 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C13DBE087F for ; Mon, 18 Apr 2011 12:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxchSh-AbMKU for ; Mon, 18 Apr 2011 12:00:38 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by ietfc.amsl.com (Postfix) with ESMTP id 0CCF9E089A for ; Mon, 18 Apr 2011 12:00:18 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.2]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110418190015.PITJ18231.mtaout01-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Mon, 18 Apr 2011 20:00:15 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QBtgF-00045B-Cb; Mon, 18 Apr 2011 20:00:15 +0100 Message-ID: <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> From: "George Barwood" To: "Peter Koch" , "IETF DNSOP WG" References: <20110418174138.GH22688@x28.adm.denic.de> Date: Mon, 18 Apr 2011 20:01:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=zhePSyoPQsMA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=6AGNo1izRQksUc-DdMAA:9 a=wPNLvfGTeEIA:10 a=vH2QUTMcjcwA:10 a=lZB815dzVvQA:10 a=vsVen_gcaDrMncfe:21 a=aXUVBbJ_HIPT3eMP:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 18 Apr 2011 19:00:38 -0000 SSBoYXZlIGEgZmV3IGNvbW1lbnRzLg0KDQooMSkgSXQncyBteSBiZWxpZWYgdGhhdCBhbG1vc3Qg YWxsIFpvbmVzIGV4Y2VwdCBmb3IgdGhlIHJvb3Qgem9uZSBzaG91bGQgTk9UIHVzZSBhIEtTSy9a U0sgc3BsaXQuDQpXaXRoIHRoZSBzaWduaW5nIG9mIHRoZSByb290IHpvbmUgYW5kIG1hbnkgVExE cywgbWFudWFsIGRpc3RyaWJ1dGlvbiBvZiB0cnVzdCBhbmNob3JzIGlzIGxpa2VseQ0KdG8gYmUg dW5jb21tb24uIE9uZSBhZHZhbnRhZ2UgKG5vdCBtZW50aW9uZWQgaW4gdGhlIGRvY3VtZW50KSBv ZiB1c2luZyBhIHNpbmdsZSBrZXkgc3lzdGVtIGlzDQp0aGF0IGl0IGlzIG5vdCBuZWNlc3Nhcnkg Zm9yIHZhbGlkYXRvcnMgdG8gY2hlY2sgdGhlIFJSU0lHIGZvciB0aGUgRE5TS0VZIFJSc2V0IHdo ZW4gaXQgaXMNCmNvbXBsZXRlbHkgYXV0aGVudGljYXRlZCBieSB0aGUgcGFyZW50IERTLiBDdXJy ZW50IHByYWN0aWNlIGFwcGVhcnMgdG8gYmUgdGhlIG9wcG9zaXRlLCBzbyBJIHdvdWxkDQpsaWtl IHRvIHNlZSB0aGUgcmVjb21tZW5kYXRpb24gdGlsdGVkIG1vcmUgc3Ryb25nbHkgaW4gZmF2b3Vy IG9mIHNpbmdsZSBrZXlzLCANCiJVc2UgYSBzaW5nbGUga2V5IHVubGVzcyB5b3UgYXJlIHRoZSBy b290IHpvbmUgb3IgeW91IGhhdmUgdW51c3VhbCByZXF1aXJlbWVudHMiDQppbiBvcmRlciAgdG8g cmVkcmVzcyB0aGUgYmFsYW5jZSAoIG9wZXJhdG9ycyBhcmUgbGlrZSBzaGVlcCApLg0KDQooMikg VGhlcmUgaXMgbm8gcG9pbnQgaW4gdXNpbmcgYSBsYXJnZXIga2V5IHNpemUgdGhhbiB0aGUgc21h bGxlc3Qga2V5IHNpemUgaW4gdGhlIHBhcmVudCBjaGFpbg0KKCBhZ2FpbiBhc3N1bWluZyBubyBt YW51YWwgdHJ1c3QgYW5jaG9ycyApLiBpLmUuIGlmIHRoZSBwYXJlbnQgRFMgcmVjb3JkIGlzIHNp Z25lZCB3aXRoIGEgMTAyNCBiaXQga2V5LCANCnRoZXJlIGlzIG5vIHBvaW50IGluIHVzaW5nIGtl eXMgbGFyZ2VyIHRoYW4gMTAyNCBiaXRzLiBBZ2FpbiwgY3VycmVudCBwcmFjdGljZSBhcHBlYXJz IHRvIGJlIHRoZSBvcHBvc2l0ZS4NCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBtZW50aW9uZWQsIGV2 ZW4gaWYgaXQgaXMgb2J2aW91cy4NCg0KKDMpIFVzaW5nIGEgbG9uZ2VyIFRUTCBmb3IgbmVnYXRp dmUgRFMgcmVzcG9uc2VzIG1pZ2h0IGJlIHVzZWZ1bC4gQ3VycmVudGx5IHRoZSBuZWdhdGl2ZSBU VEwgZm9yDQp0aGUgY29tIHpvbmUgaXMgb25seSA5MDAgc2Vjb25kcyAodGhlIFNPQSBUVEwpLiBU aGlzIGlzIHByb2JhYmx5IGFwcHJvcHJpYXRlIGZvciBhIE5hbWVFcnJvcg0KKE54RG9tYWluKSBy ZXNwb25zZSwgYnV0IDEgZGF5IG1pZ2h0IGJlIG1vcmUgYXBwcm9wcmlhdGUgZm9yIGEgbmVnYXRp dmUgRFMgcmVzcG9uc2UsIHRvIGltcHJvdmUNCmNhY2hpbmcgcGVyZm9ybWFuY2UgYW5kIHJlZHVj ZSBsb2FkIG9uIHNlcnZlcnMuDQoNCkkgc3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3Vt ZW50Lg0KDQpSZWdhcmRzLA0KR2VvcmdlIEJhcndvb2QNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206ICJQZXRlciBLb2NoIiA8cGtAREVOSUMuREU+DQpUbzogIklFVEYgRE5T T1AgV0ciIDxkbnNvcEBpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgQXByaWwgMTgsIDIwMTEgNjo0 MSBQTQ0KU3ViamVjdDogW0ROU09QXSBXR0xDIDxkcmFmdC1pZXRmLWRuc29wLXJmYzQ2NDFiaXMt MDYudHh0PiBbMjAxMS0wNS0xN10NCg0K From jabley@hopcount.ca Mon Apr 18 13:26:36 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BA75DE072E for ; Mon, 18 Apr 2011 13:26:36 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuOvzhnS30b9 for ; Mon, 18 Apr 2011 13:26:35 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfc.amsl.com (Postfix) with ESMTP id 76B87E077C for ; Mon, 18 Apr 2011 13:26:35 -0700 (PDT) Received: from [199.212.90.22] (helo=dh22.r1.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBv1k-000Ly1-3G; Mon, 18 Apr 2011 20:26:32 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley X-Priority: 3 In-Reply-To: <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> Date: Mon, 18 Apr 2011 16:26:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> To: George Barwood X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 199.212.90.22 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 18 Apr 2011 20:26:36 -0000 On 2011-04-18, at 15:01, George Barwood wrote: > I have a few comments. >=20 > (1) It's my belief that almost all Zones except for the root zone = should NOT use a KSK/ZSK split. In practice, for a TLD zone operator, rolling a KSK is a more = complicated and time-consuming process than rolling a ZSK. A ZSK roll = can be achieved quickly, entirely using systems operated by the TLD = operator, whilst a KSK roll necessarily involves review by external = organisations which takes more time. (An emergency DS RRSet change for the root zone is required to be = implemented within 48 hours of submission, assuming the request is = well-formed. There have been no such requests to date so it is not = possible to offer data on the actual time for implementation.) Where a KSK/ZSK split exists, the frequency of use of each key is not = the same -- ZSKs are typically exercised more frequently (every time an = RRSIG over any RRSet in the zone needs to be generated) than ZSKs (which = only need to be exercised as part of a ZSK roll). I don't think it's unreasonable for these facts, as an inject to an = appropriate threat analysis, to result in a recommendation to operate = with a ZSK/KSK split -- such an arrangement facilitates different levels = of protection for each key commensurate with the ease with which it = might be rolled and the frequency with which it is required to be used. I'm not saying it's the only way to go, but I think recommending against = the practice makes little sense. Joe From paul@xelerance.com Mon Apr 18 14:35:01 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC122E0786 for ; Mon, 18 Apr 2011 14:35:01 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw2DlnSAMA9u for ; Mon, 18 Apr 2011 14:35:01 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 4E3DDE073C for ; Mon, 18 Apr 2011 14:34:58 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 7BADEC5C0; Mon, 18 Apr 2011 17:34:56 -0400 (EDT) Date: Mon, 18 Apr 2011 17:34:56 -0400 (EDT) From: Paul Wouters To: George Barwood In-Reply-To: <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> Message-ID: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 18 Apr 2011 21:35:02 -0000 On Mon, 18 Apr 2011, George Barwood wrote: > (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split. > With the signing of the root zone and many TLDs, manual distribution of trust anchors is likely > to be uncommon. Not true. Any responsible organisation will configure their own zone's trust anchoes in their resolvers, so they can operate internally when their WAN/UPlink is down. > (2) There is no point in using a larger key size than the smallest key size in the parent chain See 1) Those will benefit from additional strength that seems excessive to any parent. > (3) Using a longer TTL for negative DS responses might be useful. Currently the negative TTL for > the com zone is only 900 seconds (the SOA TTL). This is probably appropriate for a NameError > (NxDomain) response, but 1 day might be more appropriate for a negative DS response, to improve > caching performance and reduce load on servers. I think this issue should probably looked at in the light of the "child centric" vs "parent centric" issues we have seen. I don't know the right answer, but some others might have better feedback on this. Paul From george.barwood@blueyonder.co.uk Mon Apr 18 16:13:05 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 828CCE0801 for ; Mon, 18 Apr 2011 16:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXrTch3jS0WC for ; Mon, 18 Apr 2011 16:13:04 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by ietfc.amsl.com (Postfix) with ESMTP id 879B3E073B for ; Mon, 18 Apr 2011 16:13:04 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.1]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110418231301.FOPU18231.mtaout01-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Tue, 19 Apr 2011 00:13:01 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QBxcr-0005FJ-75; Tue, 19 Apr 2011 00:13:01 +0100 Message-ID: From: "George Barwood" To: "Paul Wouters" References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> Date: Tue, 19 Apr 2011 00:14:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=zhePSyoPQsMA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=iSxEJr3ZAAAA:8 a=a5Gf7U6LAAAA:8 a=48vgC7mUAAAA:8 a=YiVwxKbhRW91zCyC1foA:9 a=2G9K-mHbd3Ah4WZfMyUA:7 a=wPNLvfGTeEIA:10 a=gGybslbakVAA:10 a=yHIqe9kG5mgA:10 a=lZB815dzVvQA:10 a=F7A1cYEQFecXAGXQ:21 a=UwtkKrHIyfub7C1J:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 18 Apr 2011 23:13:05 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgV291dGVycyIgPHBh dWxAeGVsZXJhbmNlLmNvbT4NClRvOiAiR2VvcmdlIEJhcndvb2QiIDxnZW9yZ2UuYmFyd29vZEBi bHVleW9uZGVyLmNvLnVrPg0KQ2M6ICJJRVRGIEROU09QIFdHIiA8ZG5zb3BAaWV0Zi5vcmc+DQpT ZW50OiBNb25kYXksIEFwcmlsIDE4LCAyMDExIDEwOjM0IFBNDQpTdWJqZWN0OiBSZTogW0ROU09Q XSBXR0xDIDxkcmFmdC1pZXRmLWRuc29wLXJmYzQ2NDFiaXMtMDYudHh0PiBbMjAxMS0wNS0xN10N Cg0KDQo+IE9uIE1vbiwgMTggQXByIDIwMTEsIEdlb3JnZSBCYXJ3b29kIHdyb3RlOg0KPiANCj4+ ICgxKSBJdCdzIG15IGJlbGllZiB0aGF0IGFsbW9zdCBhbGwgWm9uZXMgZXhjZXB0IGZvciB0aGUg cm9vdCB6b25lIHNob3VsZCBOT1QgdXNlIGEgS1NLL1pTSyBzcGxpdC4NCj4+IFdpdGggdGhlIHNp Z25pbmcgb2YgdGhlIHJvb3Qgem9uZSBhbmQgbWFueSBUTERzLCBtYW51YWwgZGlzdHJpYnV0aW9u IG9mIHRydXN0IGFuY2hvcnMgaXMgbGlrZWx5DQo+PiB0byBiZSB1bmNvbW1vbi4NCj4gDQo+IE5v dCB0cnVlLiBBbnkgcmVzcG9uc2libGUgb3JnYW5pc2F0aW9uIHdpbGwgY29uZmlndXJlIHRoZWly IG93biB6b25lJ3MgdHJ1c3QgYW5jaG9lcyBpbiB0aGVpcg0KPiByZXNvbHZlcnMsIHNvIHRoZXkg Y2FuIG9wZXJhdGUgaW50ZXJuYWxseSB3aGVuIHRoZWlyIFdBTi9VUGxpbmsgaXMgZG93bi4NCg0K UG9zc2libHkuIEJ1dCBJIHRoaW5rIHRoaXMgd2lsbCBiZSBxdWl0ZSByYXJlLCBhbmQgd2lsbCBv bmx5IGFwcGx5IHRvIG9yZ2FuaXNhdGlvbnMgd2l0aA0KdmVyeSBzaWduaWZpY2FudCByZXNvdXJj ZXMgKG1heWJlIGdvdmVybm1lbnRzKS4gSSByZWFsbHkgZG91YnQgdGhlIHNpZ25pZmljYW50IGV4 dHJhDQpjb21wbGV4aXR5IG9mIG1hbmFnaW5nIHRoZXNlIHRydXN0IGFuY2hvcnMgaXMgbGlrZWx5 IHRvIGxlYWQgdG8gYW4gb3ZlcmFsbCBpbmNyZWFzZSBpbiBzZWN1cml0eS4NCkhvdyBhcmUgeW91 IGdvaW5nIHRvIGRpc3RyaWJ1dGUgdGhlbT8gSWYgeW91IGhhdmUgYSBkaXN0cmlidXRpb24gbWVj aGFuaXNtICggb3RoZXIgdGhhbiB0aGUgcHVibGljDQpvbmUgKSB0aGVuIHlvdSBjYW4gcHJlc3Vt YWJseSB1cGRhdGUgdGhlIHRydXN0IHJvb3QgY29uZmlnIGluIGEgdGltZWx5IHdheSB3aGVuIG5l ZWRlZCwgc28gbm90aGluZyBpcyBnYWluZWQuDQoNCj4+ICgyKSBUaGVyZSBpcyBubyBwb2ludCBp biB1c2luZyBhIGxhcmdlciBrZXkgc2l6ZSB0aGFuIHRoZSBzbWFsbGVzdCBrZXkgc2l6ZSBpbiB0 aGUgcGFyZW50IGNoYWluDQo+IA0KPiBTZWUgMSkgVGhvc2Ugd2lsbCBiZW5lZml0IGZyb20gYWRk aXRpb25hbCBzdHJlbmd0aCB0aGF0IHNlZW1zIGV4Y2Vzc2l2ZSB0byBhbnkgcGFyZW50Lg0KDQpJ IHJlYWxseSBkb3VidCBzZWN1cml0eSB3b3VsZCBiZSBpbXByb3ZlZCBpbiBwcmFjdGljYWwgdGVy bXMuDQpUaGUgZXh0cmEgY29tcGxleGl0eSBvZiBub24tc3RhbmRhcmQgY29uZmlndXJhdGlvbiB3 b3VsZCBwcm9iYWJseSBvdXR3ZWlnaA0KdGhlIG1pbnV0ZSBiZW5lZml0IG9mIGxvbmdlciBrZXlz LCBib3RoIGluIHNlY3VyaXR5IHRlcm1zLCBhbmQgZXZlbiBtb3JlIGNlcnRhaW5seQ0KaW4gdGVy bXMgb2YgcmVsaWFiaWxpdHkuIEJ1dCBhbnl3YXksIHllcywgaWYgeW91IGFyZSByZWFsbHkgcGxh bm5pbmcgdGhpcywgdGhlbg0KYSBaU0svS1NLIHNwbGl0IG1pZ2h0IHBvc3NpYmx5IGJlIGhlbHBm dWwsIGJ1dCBub3QgZm9yIHR5cGljYWwgZG9tYWlucy4NCiANCj4+ICgzKSBVc2luZyBhIGxvbmdl ciBUVEwgZm9yIG5lZ2F0aXZlIERTIHJlc3BvbnNlcyBtaWdodCBiZSB1c2VmdWwuIEN1cnJlbnRs eSB0aGUgbmVnYXRpdmUgVFRMIGZvcg0KPj4gdGhlIGNvbSB6b25lIGlzIG9ubHkgOTAwIHNlY29u ZHMgKHRoZSBTT0EgVFRMKS4gVGhpcyBpcyBwcm9iYWJseSBhcHByb3ByaWF0ZSBmb3IgYSBOYW1l RXJyb3INCj4+IChOeERvbWFpbikgcmVzcG9uc2UsIGJ1dCAxIGRheSBtaWdodCBiZSBtb3JlIGFw cHJvcHJpYXRlIGZvciBhIG5lZ2F0aXZlIERTIHJlc3BvbnNlLCB0byBpbXByb3ZlDQo+PiBjYWNo aW5nIHBlcmZvcm1hbmNlIGFuZCByZWR1Y2UgbG9hZCBvbiBzZXJ2ZXJzLg0KPiANCj4gSSB0aGlu ayB0aGlzIGlzc3VlIHNob3VsZCBwcm9iYWJseSBsb29rZWQgYXQgaW4gdGhlIGxpZ2h0IG9mIHRo ZSAiY2hpbGQgY2VudHJpYyIgdnMgInBhcmVudCBjZW50cmljIg0KPiBpc3N1ZXMgd2UgaGF2ZSBz ZWVuLiBJIGRvbid0IGtub3cgdGhlIHJpZ2h0IGFuc3dlciwgYnV0IHNvbWUgb3RoZXJzIG1pZ2h0 IGhhdmUgYmV0dGVyIGZlZWRiYWNrIG9uIHRoaXMuDQoNClRoZSBETlNTRUMgc3RhbmRhcmQgc2Vl bXMgdmFndWUgKEFGQUlDUykgb24gdGhlIFRUTCBvZiB0aGUgbmVnYXRpdmUgRFMgaW5mb3JtYXRp b24gaW5jbHVkZWQgd2l0aCBhIHJlZmVycmFsDQpmcm9tIGEgc2VjdXJlIHRvIGEgbm9uLXNlY3Vy ZSB6b25lICh0aGUgU09BIGlzIG5vdCBzZW50KS4gSSdtIHJlYWxseSBub3Qgc3VyZSBob3cgaXQn cyBtZWFudCB0byB3b3JrICggdGhpcyBpcyBwb3NzaWJseSBhIGJpdCBvZmYtdG9waWMgaGVyZSB0 aG91Z2ggLSBJIGFza2VkIGEgcXVlc3Rpb24gaW4gZG5zZXh0IHJlY2VudGx5LCBubyByZXNwb25z ZSB5ZXQgKS4NCg0KPiBQYXVs From dougb@dougbarton.us Mon Apr 18 16:22:33 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93D42E070C for ; Mon, 18 Apr 2011 16:22: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1ahs9Bt7EIR for ; Mon, 18 Apr 2011 16:22:32 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfc.amsl.com (Postfix) with ESMTP id A8E08E067C for ; Mon, 18 Apr 2011 16:22:32 -0700 (PDT) Received: (qmail 11352 invoked by uid 399); 18 Apr 2011 23:22:30 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 18 Apr 2011 23:22:30 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DACC7B4.9080003@dougbarton.us> Date: Mon, 18 Apr 2011 16:22:28 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: George Barwood References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 18 Apr 2011 23:22:33 -0000 On 04/18/2011 16:14, George Barwood wrote: > > ----- Original Message ----- > From: "Paul Wouters" >> On Mon, 18 Apr 2011, George Barwood wrote: >> >>> (1) It's my belief that almost all Zones except for the root zone >>> should NOT use a KSK/ZSK split. With the signing of the root zone >>> and many TLDs, manual distribution of trust anchors is likely to >>> be uncommon. >> >> Not true. Any responsible organisation will configure their own >> zone's trust anchoes in their resolvers, so they can operate >> internally when their WAN/UPlink is down. > > Possibly. But I think this will be quite rare, and will only apply to > organisations with very significant resources (maybe governments). I would do this at any enterprise I was involved with. > I really doubt the significant extra complexity of managing these trust > anchors is likely to lead to an overall increase in security. How are > you going to distribute them? The same way that I would distribute all of the other name server configuration files. > If you have a distribution mechanism ( > other than the public one ) then you can presumably update the trust > root config in a timely way when needed, so nothing is gained. I'm not sure how that's germane to Paul's point. I'm going to have the root zone trust anchor configured already, but I would not want to have to configure all of the relevant TLD trust anchors as well. I would much rather configure the trust anchors for _my_ zones that I care about being able to continue functioning should the big-I Internet be unavailable. >>> (2) There is no point in using a larger key size than the >>> smallest key size in the parent chain >> >> See 1) Those will benefit from additional strength that seems >> excessive to any parent. > > I really doubt security would be improved in practical terms. The > extra complexity of non-standard configuration would probably > outweigh the minute benefit of longer keys, both in security terms, > and even more certainly in terms of reliability. But anyway, yes, if > you are really planning this, then a ZSK/KSK split might possibly be > helpful, but not for typical domains. TIMTOWTDI. :) This could also be useful for situations where you are anticipating the parent moving to a stronger key, or where the primary value of the signatures is in an island of trust scenario. I also wanted to voice my agreement with Joe's response. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From matthijs@nlnetlabs.nl Tue Apr 19 01:19:48 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A695E06EF for ; Tue, 19 Apr 2011 01:19:48 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nIuQNOqcBOV for ; Tue, 19 Apr 2011 01:19:47 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 16AFBE070C for ; Tue, 19 Apr 2011 01:19:46 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:215:afff:fed2:e121] ([IPv6:2001:7b8:206:1:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3J8JfMd040746; Tue, 19 Apr 2011 10:19:41 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAD459D.1000507@nlnetlabs.nl> Date: Tue, 19 Apr 2011 10:19:41 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: George Barwood References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> In-Reply-To: <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 19 Apr 2011 10:19:42 +0200 (CEST) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 08:19:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi George, dnsop, On 04/18/2011 09:01 PM, George Barwood wrote: > I have a few comments. > > (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split. > With the signing of the root zone and many TLDs, manual distribution of trust anchors is likely > to be uncommon. One advantage (not mentioned in the document) of using a single key system is > that it is not necessary for validators to check the RRSIG for the DNSKEY RRset when it is > completely authenticated by the parent DS. Current practice appears to be the opposite, so I would > like to see the recommendation tilted more strongly in favour of single keys, > "Use a single key unless you are the root zone or you have unusual requirements" > in order to redress the balance ( operators are like sheep ). This document is *not* intended to become a BCP. Therefore, I am not eager to add such a recommendation. I believe the operational motivation for ZSK/KSK split (3.1) is sufficient for operators to be able to decide whether a split or a Single Type Signing Scheme is recommended. > (2) There is no point in using a larger key size than the smallest key size in the parent chain > ( again assuming no manual trust anchors ). i.e. if the parent DS record is signed with a 1024 bit key, > there is no point in using keys larger than 1024 bits. Again, current practice appears to be the opposite. > I don't think this is mentioned, even if it is obvious. The document does mention that an attacker will attack the key that costs lowest resources. The comparison with TLS trust anchors is made. Perhaps, a clarifying note on DS records can be made here as well. > (3) Using a longer TTL for negative DS responses might be useful. Currently the negative TTL for > the com zone is only 900 seconds (the SOA TTL). This is probably appropriate for a NameError > (NxDomain) response, but 1 day might be more appropriate for a negative DS response, to improve > caching performance and reduce load on servers. You might be right, I don't know whether which value is more appropriate in one case or another. In one case 900 seconds might be preferred, in the other case 1 day is maybe the best solution. I don't want to advocate BCP values for SOA TTL and SOA MINIMUM. (What I don't understand is how you would set different TTLs for DS-related negative answers and not DS-related negative answers) Best regards, Matthijs > I support publication of this document. > > Regards, > George Barwood > > ----- Original Message ----- > From: "Peter Koch" > To: "IETF DNSOP WG" > Sent: Monday, April 18, 2011 6:41 PM > Subject: [DNSOP] WGLC [2011-05-17] > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrUWcAAoJEA8yVCPsQCW5EYIIAISWmzitwxdpU8vqWW2KPSX2 +KwgXD4DcYQY87d5Uz4Hp8XPbqDOMRZwMv3AcexiFGrgBE4DT4jnlaweXbKFqqUR /dB5gmZiFGmxcx2HN+pxHIoxPn9s4OXsnIWgO0RzUVlFdXmjpfktsbtWIQUIcDcH 5jeTsIH8LqxtPVGdEYA1z1/3gd66PngG6zcDjJNQbhwFMjygyTH2KgnLm4OzlQ78 Oc2kDMvXl1Yw1qqOA2eybs0W9DF51DBSkxNBzkPfDIicNbif2d+KPQMcC0rfKfgT WBTtQ1LL9UIrMv7/RW4PMP+55bQkXTujQAkdE7HK+Duf/UxXBZuyquvDVUXjfwA= =970Y -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Tue Apr 19 02:42:01 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A59F9E06C8 for ; Tue, 19 Apr 2011 02:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcCC6V1qMh8b for ; Tue, 19 Apr 2011 02:42:00 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id 8BB51E0680 for ; Tue, 19 Apr 2011 02:42:00 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3J9fxYj007082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 19 Apr 2011 11:41:59 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 19 Apr 2011 11:41:47 +0200 Message-ID: <4DAD58EA.5020505@sidn.nl> Date: Tue, 19 Apr 2011 11:42:02 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> In-Reply-To: <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 09:42:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18-04-11 21:01, George Barwood wrote: > I have a few comments. > > (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split. I don't think this is true. I think the split of when to use a KSK/ZSK and when not is not that clear. But it depends on: - -Time and operational difficulty to communicate a new DS to parent - -Size of the zone, and frequency of updates to zone content. A large zone, that has frequent updates, and has a timeconsuming, difficult or strict parent-child relation is better off using KSK/ZSK. A small zone, that has very few updates, can just as well use 1 key. I have some more questions on the draft. In section 3.4.3 I read: "Although not mandatory, one could administer a zone using a "hidden master" scheme that minimize the risk. In this arrangement the master that processes the updates is unavailable from general hosts on the Internet; it is not listed in the NS RRSet, although its name appears in the SOA RRs MNAME field." This seems to me to define what should be listed in the SOA RRs MNAME field in case a hidden master is used. Another definition could well be that when you use a hidden master, one of the public nameservers should be appointed to be the public master, and it's name should be in the SOA RRs MNAME field, as that server should allways be accesible over the public Internet, and the name in the MNAME field should allways resolve (to a public IP) and be in the NS RRset. If would appreciate if someone could point me to standard-track text where this is defined. Section 4.3.5.2, first paragraph: "If the registry and registrars allow for DS records to be published, that do not point to a published DNSKEY in the child zone, the Double-DS KSK Rollover is preferred to resolve the non-cooperative case." I think this should be: "the Double-DS KSK Rollover is preferred to resolve the cooperative case." In the non-cooperative case even a Double-DS does not make sense, and one should go insecure. I have not finnished to review the complete document yet, but will do before the deadline. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrVjlAAoJEDqHrM883AgnzzAH/0fB5pxb2RFZDw5pj+84Phcx er7wqozZh0RBQZN1DCdir6GiZe7ILcnWrl48Mbf9wMV4TwZrws7a08NP4zxLr3yp 2SB2kKK+lW6OEgtyx3T0RcuIEEubXZRgZRAvbrThAh5qvDXzwObzpsMWGu7jmVFc 7csFgQKVrn+ioVHIkIpx2CGlk++8gyJBiec2nf5slUz2DFPVWHEEi2141cuEpEYg j1LFx2B/F74Vobyq6vq8eb0rScT8F4NdywRyw/fcgMZPYGUcPEtGfE4DBicX7w7k +svTDcAd34pQucIjKpxabzyFz5YGE23FWkpgMjmSC7pvbADaf2oxkHW4itW4ReY= =XGYz -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Tue Apr 19 02:59:29 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70B4BE0682 for ; Tue, 19 Apr 2011 02:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK7VO32Ooz0a for ; Tue, 19 Apr 2011 02:59:28 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id 84575E0680 for ; Tue, 19 Apr 2011 02:59:28 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3J9xRRV007285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 19 Apr 2011 11:59:27 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 19 Apr 2011 11:59:27 +0200 Message-ID: <4DAD5D0F.8000807@sidn.nl> Date: Tue, 19 Apr 2011 11:59:43 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: References: <20110418174138.GH22688@x28.adm.denic.de> In-Reply-To: <20110418174138.GH22688@x28.adm.denic.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 09:59:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18-04-11 19:41, Peter Koch wrote: > Please review the document and send any comments you may have to the > list. If you have no comments but support (or do not support) the > document being published, please send that information to the list. Another observation on the examples in section 4.1.*: - -I don't understand why the DNSKEY RRset should be signed with the ZSK. It's not wrong, but I don't see the point of signing the DNSKEY RRset with a ZSK. It's not needed and enlarges the zone. It's sufficiant if the DNSKEY RRset is signed by the KSK only. All RRSIG_Z_*(DNSKEY) can be removed. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrV0PAAoJEDqHrM883AgnJB4H/1hxmkSY11lumbbC2T86XQkI 55hf3JGPUxDO25IHVBnUW7vNuCq1S8Bl0EptFvge5QbBdbpsCqljBgXn+hA+MBh6 mBL2J6OHsuJkDgcpqzIgA1hpVDYVPr9yrREJORwwTYP8zER3rLsyr72X2B6qFSFI ptiltI+eEl8BWgwE7Rn7Gop4MYWOS7tgFO7Af+w2OPiE3JVL+Ywjv+ShntiLzJAw uEUAXKm7WrlAKpZXgMKpo7SpLC+uqmw5t4HFryxsRZ0uKzTMBk3hkYXz0dFZNiTo YvcWaMM4FUoJJ4/ijdjJKCoVzXmtpZJuMnHeug1dX4IKOLBFFQOc/LgQW5OFq1g= =6nIr -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Tue Apr 19 03:18:28 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6337AE0665 for ; Tue, 19 Apr 2011 03:18:28 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPo5fAeNbWoE for ; Tue, 19 Apr 2011 03:18:27 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A7EDE0728 for ; Tue, 19 Apr 2011 03:18:26 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:215:afff:fed2:e121] ([IPv6:2001:7b8:206:1:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3JAIMTC046295; Tue, 19 Apr 2011 12:18:22 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAD616B.50106@nlnetlabs.nl> Date: Tue, 19 Apr 2011 12:18:19 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Antoin Verschuren References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> In-Reply-To: <4DAD58EA.5020505@sidn.nl> X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 19 Apr 2011 12:18:22 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 10:18:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Antoin, On 04/19/2011 11:42 AM, Antoin Verschuren wrote: > On 18-04-11 21:01, George Barwood wrote: >> I have a few comments. > >> (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split. > > I don't think this is true. > I think the split of when to use a KSK/ZSK and when not is not that > clear. But it depends on: > > -Time and operational difficulty to communicate a new DS to parent > -Size of the zone, and frequency of updates to zone content. > > A large zone, that has frequent updates, and has a timeconsuming, > difficult or strict parent-child relation is better off using KSK/ZSK. > > A small zone, that has very few updates, can just as well use 1 key. > > > I have some more questions on the draft. > In section 3.4.3 I read: > "Although > not mandatory, one could administer a zone using a "hidden master" > scheme that minimize the risk. In this arrangement the master that > processes the updates is unavailable from general hosts on the > Internet; it is not listed in the NS RRSet, although its name appears > in the SOA RRs MNAME field." > This seems to me to define what should be listed in the SOA RRs MNAME > field in case a hidden master is used. Another definition could well be > that when you use a hidden master, one of the public nameservers should > be appointed to be the public master, and it's name should be in the SOA > RRs MNAME field, as that server should allways be accesible over the > public Internet, and the name in the MNAME field should allways resolve > (to a public IP) and be in the NS RRset. > If would appreciate if someone could point me to standard-track text > where this is defined. Would it be resolved if we use the following text? s/appears/may appear/ ...; it is not listed in the NS RRSet, although its name may appear in the SOA RRs MNAME field. > Section 4.3.5.2, first paragraph: > "If the registry and registrars allow for DS records to be published, > that do not point to a published DNSKEY in the child zone, the > Double-DS KSK Rollover is preferred to resolve the non-cooperative > case." > > I think this should be: > > "the Double-DS KSK Rollover is preferred to resolve the cooperative > case." > > In the non-cooperative case even a Double-DS does not make sense, and > one should go insecure. You are right. Best regards, Matthijs > I have not finnished to review the complete document yet, but will do > before the deadline. > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrWFqAAoJEA8yVCPsQCW5cHMH/1Owj4PBlDByl4Qm/HzjWnSh WRXgrvTuwlsPomSbyUSSF7wSYZbq3S2MsRMizTR+IonGCBtbtlPC3WhKSZ4ZKyrd kDzzHthLauplspFZ8pwVZMQ9dzfZZ73PUErlpM2Jt1qnXeuWvAPK+G/0WboUnPkS iorowB/llIL+bXu9ugfagehk3m8XvlaEgMLNm5X6rzeZnrpl5osbFVMhaeOagzhV 6+QvwAEBBIc3Ttro1cz3rCtzqFdt6GOAUDC1yT15v1L6f6yDW6bCtdvwFUAaGYrQ WqqH/ZcxjOZtpOepmuRjX9N/YD1TWupOSccQochfqKTLLILQsAw4M6GDVP7/MXU= =6MqR -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Tue Apr 19 03:54:59 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33762E0731 for ; Tue, 19 Apr 2011 03:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvPFdlwWE26K for ; Tue, 19 Apr 2011 03:54:58 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id 414D1E072B for ; Tue, 19 Apr 2011 03:54:58 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3JAsu4n008104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Tue, 19 Apr 2011 12:54:56 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 19 Apr 2011 12:54:56 +0200 Message-ID: <4DAD6A0F.3020300@sidn.nl> Date: Tue, 19 Apr 2011 12:55:11 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Matthijs Mekking References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAD616B.50106@nlnetlabs.nl> In-Reply-To: <4DAD616B.50106@nlnetlabs.nl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 10:54:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19-04-11 12:18, Matthijs Mekking wrote: > Hi Antoin, > > Would it be resolved if we use the following text? > s/appears/may appear/ > > ...; it is not listed in the NS RRSet, although its name may appear > in the SOA RRs MNAME field. I think the definition of a hidden master is that it is not reachable from the public Internet, and therefor it's hostname does not need to resolve on the public Internet. The SOA RRs MNAME field was defined before hidden masters were used, so I don't know if a hostname in the MNAME field should resolve and be reachable. If it is, then it's no longer a hidden master, but just a public master that is not in the NS set. I think the best way forward for now is to say "it is not listed in the NS RRSet" and not mention anything about the MNAME field. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrWoPAAoJEDqHrM883AgnyrAIAMeCRff1Q4tdhMpTGWUFkNoA XpD+BhyrXhRRqGDSatOQ1wnDiIvFn/pOqAgIq1rg/uxmb2PSvSl32FGJuMt3ug66 nTj84ivAYEQ8IJdwwdOQwDdzR/uz17yo91S0VMSbllkU6qCP7FwgVHRfr75iiNfv g6dEsze5S1hmkiRt5BR0Q0BnncsIo4I5aAzHHNscVC7pWt3Er9hmMR+hHsFat1lA aZ9REGsUJItiR6u1La36jVZmtKL/UONTKrAqFQo/xNKuLu+Y1EWD8VN4x3+vAhGi 8Xah/CulothdZg3NehbfR2x2kdhAGSgFmwW9JvjuGc7gbnIxXp430xpo6Qef6nA= =TfWl -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Tue Apr 19 05:37:38 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 173A1E06A7 for ; Tue, 19 Apr 2011 05:37:38 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfPNWKc8Y44H for ; Tue, 19 Apr 2011 05:37:37 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfc.amsl.com (Postfix) with ESMTP id 23455E0691 for ; Tue, 19 Apr 2011 05:37:36 -0700 (PDT) X-ASG-Debug-ID: 1303216654-036949163802330001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id EFOiACGYXDC5x1B1 for ; Tue, 19 Apr 2011 14:37:34 +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 3F6E9E4076 for ; Tue, 19 Apr 2011 14:31: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 fbO2CKO203Kq for ; Tue, 19 Apr 2011 14:31:02 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 2B6B7E4065 for ; Tue, 19 Apr 2011 14:31:02 +0200 (CEST) From: "Marc Lampo" To: "'IETF DNSOP WG'" References: <20110418174138.GH22688@x28.adm.denic.de> In-Reply-To: <20110418174138.GH22688@x28.adm.denic.de> Date: Tue, 19 Apr 2011 14:31:02 +0200 (CEST) X-ASG-Orig-Subj: RE: [DNSOP] WGLC [2011-05-17] Message-ID: <010801cbfe8e$8e960a80$abc21f80$@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.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acv9795f3h2g9TU+Rvm0tE+I079BsgAmpU+Q Content-Language: en-za X-Originating-IP: [172.20.1.130] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1303216654 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 12:37:38 -0000 Some comments : 3.1 Operational Motivation for ZSK and KSK I explicitly agree with Antoin Verschuren [antoin.verschuren@sidn.nl] that more criteria should be taken into account, more then listed in the present document (like the ones he proposes). As extra observation, I would prefer "child-parent" rather then "registrar-registry" (globally : any reference to "registrar" or "registry"). Motivation : registrar is linked to the "customer" layer and "registry" to the "tld" layer of a "customer.tld." domain name. But DNSSEC can go below that level ! As I am in Belgium, "just.fgov.be." is a delegated subdomain : if they will, one day, soon ?, implement DNSSEC, the communicating DS information is not between registrar and registry. In broader scope : the document should not limit to DNSSEC between a label and a top-level-domain (or tld - root-domain). 4.1 Key Rollovers For non-tld's, I agree, again, with Antoin Verschuren [antoin.verschuren@sidn.nl] : recommend double-sign rollover. The present document states, "neutrally", that double-sign rollover involves more signatures and hence, larger zone files. While this is true, well maintained (public) zone files should be small anyway (except for tld's). The average company does not offer hundreds of services on hundreds of IP addresses. A DNS administrator who leaves data like "test-mx" in hers or his public data should learn not to publish anything not meant to be distributed. Recommending pre-publish for "large" zone files (with "lots" of unnecessary data in it) is "pearls to the pigs" ;-) 4.1.2 Key Signing Rollovers I see some tld's perform rollover with 3 keys (not 2). Assuming a start position with 2 keys : Initial : KSK1 & KSK2 (both being used for signing) Start of rollover : add KSK3 --> KSK1 & KSK2 & KSK3 (all used for signing) End of rollover : remove KSK1 --> KSK2 & KSK3 (both used for signing) Advantage : Only 2 actions to complete key rollover During the rollover, there is one key that is completely untouched. --> if chain-of-trust would break via KSK1 or KSK3, that KSK2 (DS/DNSKEY/RRSIG) is always available. As the KSK signs only the DNSKEY RRset, this "costs" only one extra RRSIG in the zone file. Kind regards, Marc Lampo -----Original Message----- From: Peter Koch [mailto:pk@DENIC.DE] Sent: 18 April 2011 07:42 PM To: IETF DNSOP WG Subject: [DNSOP] WGLC [2011-05-17] Dear DNSOP WG, this is to initiate a working group last call (WGLC) on "DNSSEC Operational Practices, Version 2" Owing to the length of the document, the WGLC will last for four weeks instead of the usual two, and will therefore end on Tuesday, 17 May, 23:59 UTC. The IETF tools site gives easy access to the current and previous versions as well as differences and the like at . The document is aimed at a status of "Informational". Please review the document and send any comments you may have to the list. If you have no comments but support (or do not support) the document being published, please send that information to the list. The document is subject to the normal five reviewer threshold. Stephen and Peter DNSOP co-chairs From Antoin.Verschuren@sidn.nl Tue Apr 19 05:56:05 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 97414E0663 for ; Tue, 19 Apr 2011 05:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9wJLXSQjJ7T for ; Tue, 19 Apr 2011 05:56:04 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id 899EEE065A for ; Tue, 19 Apr 2011 05:56:04 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3JCu3cA010623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 19 Apr 2011 14:56:03 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Tue, 19 Apr 2011 14:55:57 +0200 Message-ID: <4DAD866C.2050806@sidn.nl> Date: Tue, 19 Apr 2011 14:56:12 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: References: <20110418174138.GH22688@x28.adm.denic.de> In-Reply-To: <20110418174138.GH22688@x28.adm.denic.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 12:56:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18-04-11 19:41, Peter Koch wrote: > Please review the document and send any comments you may have to the > list. If you have no comments but support (or do not support) the > document being published, please send that information to the list. More comments: Section 4.1.2 last paragraph: "In this mechanism, there are periods where there are two DS RRs at the parent. Since at the moment of writing the protocol for this interaction has not been developed, further discussion is out of scope for this document." This is strange, as the Double DS rollover mechanism is used furtheron in the document in section 4.1.3 figure 5. I think this text is a leftover from a previous version. It is true that an automated rollover with an in-band interaction has not been developped yet, but this text seems to sugest that Double-DS has not been invented yet. And if such interaction were developped, this should be discussed in section 4.1.3 where Double-DS is defined, as this is what the interaction is trying to automate. When I take section 4.3.5 into considderation, I think that the Double-DS mechanism is almost mandatory for a parent to implement, otherwise you cannot accomodate secure child dns operator changes. Since this mechanism can also be used for regular rollovers, as section 4.1.3 describes, I think Double-DS will be the default rollover mechanism, and double signature only an alternative that will not be deployed by all parents like registries that need to implement these procedures. They will want to stick to one size fits all. Sugestion: Remove the last paragraph of section 4.1.2 starting at "An alternative mechanism has been considered." There's no use in discussing something that doen't excist yet. section 4.1.3: "A zone key rollover can be handled ...." Please use the same syntax: "A ZSK rollover can be handled..... " It's less confusing. Section 4.1.4 last paragraph: "Since this leads to increase in zone and packet size at both child and parent there are little benefits to a Double-DS rollover with a Single Type signing scheme." Same as above. A Double-DS rollover is the only rollover mechanism you can use during a secure dns operator change. Even with a Single Type signing scheme. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrYZsAAoJEDqHrM883AgnKtUIAMzfK4qdRedGP0aGuzln06Qq 4UQdUED62kK4kYppYWXhIz8nj04Ak1WgpmNGrFPZJtEdTnBwNZ5j7laSJaBbe0bF Out4qlk/AqxLfeGkywfYYIDRTi6n/xujF+4MwQ3Q1mrKP1q0lSarC9GTQN7MQf/L ZMjNfE+MNh5UNR5snctfBgJbZyCUPuxN/bLTFaA2PeYSxQw+gPJy+gnuwyp2ubPX GqeUfJk5Uu5v75RftAHmM588wX0zQ6qHwEm5OrFxSoZl3852iwPXGi/t+V5eEMQZ DUcxihwqldLFTQKYRID8gdeQzjUJkpsM+lUJp22sxCaaNgn9i0RTGU4yD28urt4= =0nZO -----END PGP SIGNATURE----- From eosterweil@verisign.com Tue Apr 19 08:15:01 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9362BE079F for ; Tue, 19 Apr 2011 08:15:01 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkJyzcEXMGFP for ; Tue, 19 Apr 2011 08:15:00 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfc.amsl.com (Postfix) with ESMTP id 2B6C7E079E for ; Tue, 19 Apr 2011 08:14:57 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKTa2m7joXN9hT97JneC9ZsHG+NZj+R5i4@postini.com; Tue, 19 Apr 2011 08:15:00 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p3JFErN6031584; Tue, 19 Apr 2011 11:14:53 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 11:14:53 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Apr 2011 15:14:53 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 19 Apr 2011 11:14:52 -0400 From: "Osterweil, Eric" To: Joe Abley , George Barwood Message-ID: Thread-Topic: [DNSOP] WGLC [2011-05-17] Thread-Index: Acv+BwT83bZxbuVkS5KPUWGopludswAnYMEy In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Apr 2011 15:14:53.0774 (UTC) FILETIME=[890EEEE0:01CBFEA4] Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 15:15:01 -0000 On 4/18/11 4:26 PM, "Joe Abley" wrote: > > > On 2011-04-18, at 15:01, George Barwood wrote: > >> I have a few comments. >> >> (1) It's my belief that almost all Zones except for the root zone should NOT >> use a KSK/ZSK split. > > In practice, for a TLD zone operator, rolling a KSK is a more complicated and > time-consuming process than rolling a ZSK. A ZSK roll can be achieved quickly, > entirely using systems operated by the TLD operator, whilst a KSK roll > necessarily involves review by external organisations which takes more time. > > (An emergency DS RRSet change for the root zone is required to be implemented > within 48 hours of submission, assuming the request is well-formed. There have > been no such requests to date so it is not possible to offer data on the > actual time for implementation.) > > Where a KSK/ZSK split exists, the frequency of use of each key is not the same > -- ZSKs are typically exercised more frequently (every time an RRSIG over any > RRSet in the zone needs to be generated) than ZSKs (which only need to be > exercised as part of a ZSK roll). > > I don't think it's unreasonable for these facts, as an inject to an > appropriate threat analysis, to result in a recommendation to operate with a > ZSK/KSK split -- such an arrangement facilitates different levels of > protection for each key commensurate with the ease with which it might be > rolled and the frequency with which it is required to be used. > > I'm not saying it's the only way to go, but I think recommending against the > practice makes little sense. +1 Eric From paul@xelerance.com Tue Apr 19 09:48:34 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B899E0774 for ; Tue, 19 Apr 2011 09:48:34 -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.400, BAYES_00=-2.599, SARE_BAYES_7x5=0.8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfXnQ20CYFCr for ; Tue, 19 Apr 2011 09:48:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 823A7E06F9 for ; Tue, 19 Apr 2011 09:48:31 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id D816DC5C4; Tue, 19 Apr 2011 12:48:29 -0400 (EDT) Date: Tue, 19 Apr 2011 12:48:29 -0400 (EDT) From: Paul Wouters To: Marc Lampo In-Reply-To: <010801cbfe8e$8e960a80$abc21f80$@lampo@eurid.eu> Message-ID: References: <20110418174138.GH22688@x28.adm.denic.de> <010801cbfe8e$8e960a80$abc21f80$@lampo@eurid.eu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'IETF DNSOP WG' Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 16:48:34 -0000 On Tue, 19 Apr 2011, Marc Lampo wrote: > The present document states, "neutrally", that double-sign rollover > involves more signatures and hence, larger zone files. While this is > true, well maintained (public) zone files should be small anyway (except > for tld's). > The average company does not offer hundreds of services on hundreds of IP > addresses. In almost all enterprises and government locations I have seen, there is one very large dhcp based zone, with thousands or tens of thousands of entries in a single zone. Picking the latest customer I was at, these are the top sizes: [paul@bofh]$ for zone in intranet/*ldns; do wc -l $zone | sed "s/ .*$//"; done | sort -n -r | head -10 144711 132489 52430 41155 20312 17326 15087 11196 10289 8587 These zones, all hosted on the same primary server, would see an additional half a million RRSIGs with a double-sign rollover. And for redundancy, this customer also loads all their auth zones on most of their name servers globally, and it would surely mean they need to upgrade hardware just to comply with this recommendation. -1 for this recommendation. TLDs are not that special in size. Whether this is "well maintained" or "public" I will not judge on. It is just what I encounter in the wild. > A DNS administrator who leaves data like "test-mx" in hers or his public > data should learn not to publish anything not meant to be distributed. I don't think 4641bis is supposed to make any value judgement about DNS data. Nor in fact, do we really know what other new RRTYPE records (like HASTLS and TLSA) will end up in the "well maintained public zone files". 4641bis should be about what is safe for the general use. If anything, TLDs are less important for 4641bis because I expect TLDs to have DNS experts that can make their own judgement and interpretation, whereas 4641bis will hopefully be a "default" setting for most DNS servers/signers for organisations with less embedded DNS skills. Paul From paul@xelerance.com Tue Apr 19 09:53:33 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89CA1E07A3 for ; Tue, 19 Apr 2011 09:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocd2oNjvNJUt for ; Tue, 19 Apr 2011 09:53:32 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id D0A49E07AE for ; Tue, 19 Apr 2011 09:53:31 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 478D1C5C4; Tue, 19 Apr 2011 12:53:31 -0400 (EDT) Date: Tue, 19 Apr 2011 12:53:31 -0400 (EDT) From: Paul Wouters To: Antoin Verschuren In-Reply-To: <4DAD6A0F.3020300@sidn.nl> Message-ID: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAD616B.50106@nlnetlabs.nl> <4DAD6A0F.3020300@sidn.nl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org, Matthijs Mekking Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 16:53:33 -0000 On Tue, 19 Apr 2011, Antoin Verschuren wrote: > I think the definition of a hidden master is that it is not reachable > from the public Internet, and therefor it's hostname does not need to > resolve on the public Internet. > The SOA RRs MNAME field was defined before hidden masters were used, so > I don't know if a hostname in the MNAME field should resolve and be > reachable. If it is, then it's no longer a hidden master, but just a > public master that is not in the NS set. > > I think the best way forward for now is to say "it is not listed in the > NS RRSet" and not mention anything about the MNAME field. It wouldn't be bad to mention something about not putting "bogus" text in the MNAME field. One example (not to pick on them specifically) is easydns, which puts dns0.easydns.com in the MNAME, with the idea that no one should resolve that anyway because it is not in the NS RRSet of their domains. But it still leaks out RFC19198 space (hopefully into a close by AS112 server) Though perhaps this is too out of scope for 4641bis Paul From paul@xelerance.com Tue Apr 19 10:10:13 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 891CBE07B2 for ; Tue, 19 Apr 2011 10:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoycnvbEVsCo for ; Tue, 19 Apr 2011 10:10:13 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id D9C99E079F for ; Tue, 19 Apr 2011 10:10:12 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 1DADEC605; Tue, 19 Apr 2011 13:10:12 -0400 (EDT) Date: Tue, 19 Apr 2011 13:10:11 -0400 (EDT) From: Paul Wouters To: Antoin Verschuren In-Reply-To: <4DAD58EA.5020505@sidn.nl> Message-ID: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 17:10:13 -0000 On Tue, 19 Apr 2011, Antoin Verschuren wrote: > Section 4.3.5.2, first paragraph: > "If the registry and registrars allow for DS records to be published, > that do not point to a published DNSKEY in the child zone, the > Double-DS KSK Rollover is preferred to resolve the non-cooperative > case." > > I think this should be: > > "the Double-DS KSK Rollover is preferred to resolve the cooperative > case." > > In the non-cooperative case even a Double-DS does not make sense, and > one should go insecure. I'm not sure if this is true in all cases. Let's split the cases of non-cooperative. I think these will be: 1) shut down all dns 2) make no changes 3) make malicious changes Against 1) and 3) you cannot do much (technically). Queries going to the losing DNS operator will be manipulated, with or without valid RRSIGs. One could argue here to immediately drop their DS record so at least their manipulation does not enjoy the protection of DNSSEC validation. Putting in your own DS might even change those queries from "insecure" to "bogus", which would be even better. For queries that do not go to the losing DNS operator, having a new DS record would cause new queries to be "secure" instead of "insecure". For queries that have partially cached trust paths, adding your new DS won't hurt, removing the old DS might make it better So with this case, I agree with you. But these are likely the more rare cases. 2) I believe is the more common case. It is eve more important to child centric zones. Adding a DS won't hurt, and leaving the old DS in there won't hurt either. Once most of the child centric zones finally caught up with the new parents, the old DS can be removed. Perhaps it is worth splitting the non-cooperative in these use cases? Paul From davidb@verisign.com Tue Apr 19 10:26:07 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 97153E06DE for ; Tue, 19 Apr 2011 10:26:07 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI6nVyXHs3dM for ; Tue, 19 Apr 2011 10:26:06 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfc.amsl.com (Postfix) with ESMTP id 751A4E0685 for ; Tue, 19 Apr 2011 10:26:06 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKTa3FrIryQHH96w71f4t4Q2eT3lRQSZ8C@postini.com; Tue, 19 Apr 2011 10:26:06 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p3JHQ3Ld005409; Tue, 19 Apr 2011 13:26:03 -0400 Received: from dul1dblacka-m2.vcorp.ad.vrsn.com ([10.131.29.13]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 13:26:03 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David Blacka X-Priority: 3 In-Reply-To: <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> Date: Tue, 19 Apr 2011 13:26:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> To: George Barwood X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 19 Apr 2011 17:26:03.0099 (UTC) FILETIME=[DB8AA2B0:01CBFEB6] Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 19 Apr 2011 17:26:07 -0000 On Apr 18, 2011, at 3:01 PM, George Barwood wrote: > I have a few comments. >=20 > (1) It's my belief that almost all Zones except for the root zone = should NOT use a KSK/ZSK split. A compelling reason to use the KSK/ZSK split is that you want to use = different security practices for the SEP key (which is harder to roll) = vs. the zone signing keys. A common example of this is to keep the KSK = "offline", which may be impractical for a ZSK. >=20 > (2) There is no point in using a larger key size than the smallest key = size in the parent chain > ( again assuming no manual trust anchors ). i.e. if the parent DS = record is signed with a 1024 bit key,=20 > there is no point in using keys larger than 1024 bits. Again, current = practice appears to be the opposite. > I don't think this is mentioned, even if it is obvious. I don't think I agree with this logic. It is true that the security of = the whole chain is only as strong as the weakest link, but there is = value in having your more difficult-to-roll KSK not be the weakest link. -- David Blacka =20 Principal Engineer Verisign Infrastructure Engineering From Antoin.Verschuren@sidn.nl Wed Apr 20 01:07:06 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 204CFE0778 for ; Wed, 20 Apr 2011 01:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgvUj3EgiZ5O for ; Wed, 20 Apr 2011 01:07:05 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id 15EE5E069C for ; Wed, 20 Apr 2011 01:07:04 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3K873e3031055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Wed, 20 Apr 2011 10:07:03 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 20 Apr 2011 10:06:56 +0200 Message-ID: <4DAE9431.2070901@sidn.nl> Date: Wed, 20 Apr 2011 10:07:13 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Paul Wouters References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 08:07:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19-04-11 19:10, Paul Wouters wrote: > > Perhaps it is worth splitting the non-cooperative in these use cases? That's excactly what was done in the draft. There was just a mistake of putting the word "non-cooperative" where "cooperative" was meant in the first sentence. And then continues to describe the non-cooperative case. There's realy nothing to describe in the non-cooperative case. If your DNS provider wants to screw up, he can. Be warned. Be consious about it, and sign a good contract with your DNS provider to prevent him from screwing up. That's the only advise we can give. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrpQwAAoJEDqHrM883AgnvD8H/ApbYptw2MRkuHLcHpkP78jo psno0wFi6hClDxzNTNUxA8iWNQWpEyhWRgsWhceJE0w+kDXaBoXotMKEYKJqcYQH Lvso9z25nRS/qvqx+YLVsr2bFyr6l7SLcVLGY0HmaAOBbWa1jecEB+zTWy8Lh+TO Wyw2xVr37C0BAR9MsLNsoGnZLx3MfzL/GEt8EdbuHYy9uszK9D+8ggw/jPirF6y0 1EREfjpaD1r0DJ+aPd61zN47J/QcLYDKNhK5vm0U4W8UR9S8PDmlCRRfDSkNXClH CfpR36z6yn+3rbxLzPVRBTfwaoIfRIB9XewHt5KHxt929+iYEIIHfc7qSGUmoM8= =DtIO -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Wed Apr 20 01:23:45 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EBB74E0670 for ; Wed, 20 Apr 2011 01:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxCg6-YapNco for ; Wed, 20 Apr 2011 01:23:45 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id 75434E067C for ; Wed, 20 Apr 2011 01:23:44 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3K8NhuS032252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 20 Apr 2011 10:23:43 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 20 Apr 2011 10:23:37 +0200 Message-ID: <4DAE981A.3090301@sidn.nl> Date: Wed, 20 Apr 2011 10:23:54 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: References: <20110418174138.GH22688@x28.adm.denic.de> <010801cbfe8e$8e960a80$abc21f80$@lampo@eurid.eu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 08:23:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19-04-11 18:48, Paul Wouters wrote: > On Tue, 19 Apr 2011, Marc Lampo wrote: > >> The average company does not offer hundreds of services on hundreds of IP >> addresses. > > > -1 for this recommendation. TLDs are not that special in size. I aggree with Paul here. There are enough large zones out there that are not a TLD, but on a deeper level in the DNS. And they are just as important. There is no judgment to be made about importance. You just look at zone size, and the decision to use double-DS or double-signature should be made on the operational impact. For a small zone, double-signature may have almost the same impact as double-DS, and in that case a faster rollover with less parent interaction (double-signature) may be prefered. For a larger zone, the increase in size may not be neglected, and more parent interaction in the double-DS rollover may be prefered over the larger zone file. And again, if the rollover includes a change of DNS operator, Double-DS is the only way to go if you want to stay secure. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrpgaAAoJEDqHrM883AgnI9YIAJ4HosM4Lk3Jjs4RsUVouMnd HURnqmQAy5r4Dx7N0dB+uIb13jlqByH7h/bRA/V8FSZA7GUlW5vS06ii0fmaIOdp qb5Y1sv9KwnP8NuSs5yhaiUEruGcmaZw77UtBQRBOKg+3ZQWA98PCDQFlefKwUSi sQYAJ6GOUIFO4XujvObrJuegwdr4eUzdxKQxkJnF+mJx9NaswarKSMtfYn0N/u9E 2zVxzZwLYIOHCeMsd4yrcV5+fAA3B9gGQOcfnjI8uqnFQyVmewIWOXypGZurS/gh 2T5/7CDOcZzvS7D7I8J7leuE5jTpdKSPFbx6wlL+ZPmJ55dYr0jMe4xJJYhf6IQ= =OQZZ -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Apr 20 01:43:22 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4EDBEE0668 for ; Wed, 20 Apr 2011 01:43:22 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqC1A1zNv5rF for ; Wed, 20 Apr 2011 01:43:21 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id A5E59E0655 for ; Wed, 20 Apr 2011 01:43:20 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:215:afff:fed2:e121] ([IPv6:2001:7b8:206:1:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3K8hJqL042692; Wed, 20 Apr 2011 10:43:19 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAE9CA7.2050702@nlnetlabs.nl> Date: Wed, 20 Apr 2011 10:43:19 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Paul Wouters References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 20 Apr 2011 10:43:19 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 08:43:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 04/19/2011 07:10 PM, Paul Wouters wrote: > On Tue, 19 Apr 2011, Antoin Verschuren wrote: > >> Section 4.3.5.2, first paragraph: >> "If the registry and registrars allow for DS records to be published, >> that do not point to a published DNSKEY in the child zone, the >> Double-DS KSK Rollover is preferred to resolve the non-cooperative >> case." >> >> I think this should be: >> >> "the Double-DS KSK Rollover is preferred to resolve the cooperative >> case." >> >> In the non-cooperative case even a Double-DS does not make sense, and >> one should go insecure. > > I'm not sure if this is true in all cases. > > Let's split the cases of non-cooperative. I think these will be: > > 1) shut down all dns > 2) make no changes > 3) make malicious changes > > Against 1) and 3) you cannot do much (technically). Queries going to > the losing DNS operator will be manipulated, with or without valid > RRSIGs. One could argue here to immediately drop their DS record so > at least their manipulation does not enjoy the protection of DNSSEC > validation. Putting in your own DS might even change those queries from > "insecure" to "bogus", which would be even better. > > For queries that do not go to the losing DNS operator, having a new DS > record > would cause new queries to be "secure" instead of "insecure". > > For queries that have partially cached trust paths, adding your new DS > won't hurt, removing the old DS might make it better > > So with this case, I agree with you. But these are likely the more rare > cases. > > 2) I believe is the more common case. It is eve more important to child > centric zones. Adding a DS won't hurt, and leaving the old DS in there > won't hurt either. Once most of the child centric zones finally caught > up with the new parents, the old DS can be removed. > > Perhaps it is worth splitting the non-cooperative in these use cases? The losing operator still needs to publish the DNSKEYs of the winning operator. Otherwise, you can get in a situation where a validator fetches RRs from the gaining operators name server, but still have the losing operator DNSKEY RRset in cache (that thus does not contain the DNSKEYs of the winning operator). Best regards, Matthijs > Paul > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrpymAAoJEA8yVCPsQCW5JfYH/1LUWOXjtuKlAUZE9qzGYO0L wERbYJKxQIs8PBRn42Cl9syJGbmM2L37ebPXGl0lcjoRP5bSKU7mZj4Ksq+MZQ3s iHap6l+7nmA4rmCx7G64EKlF7cqMjrh1Eq0PnW8OZmpWUP2lokPEYa2fSjWBl1Y7 KWnEpL2SQ+1v5RbLOhCFgmn0daQJVh3eWpAltPLKdJaCakcQA7ua3rXvNQhh+hvg tjRJdFfCSeNiR+ismIJnZxCzqXDijySF2EOki5i86puRtfJQBnNqSPu+44wrrIrh 9iaB+xDhziWlW0LIkKQ8/ZwSyQezvuMwx86lT2bWBOgQMxTJ5NK39+hGObT3a58= =s+ku -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Apr 20 01:52:20 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7B190E077D for ; Wed, 20 Apr 2011 01:52:20 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6zhrD5II0tX for ; Wed, 20 Apr 2011 01:52:19 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B104E067C for ; Wed, 20 Apr 2011 01:52:19 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:215:afff:fed2:e121] ([IPv6:2001:7b8:206:1:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3K8qI9s051499; Wed, 20 Apr 2011 10:52:18 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAE9EC2.20909@nlnetlabs.nl> Date: Wed, 20 Apr 2011 10:52:18 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Antoin Verschuren References: <20110418174138.GH22688@x28.adm.denic.de> <4DAD5D0F.8000807@sidn.nl> In-Reply-To: <4DAD5D0F.8000807@sidn.nl> X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 20 Apr 2011 10:52:18 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 08:52:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Antoin, I agree those signatures for the DNSKEY RRset with the ZSK are redundant. Also in Figure 9: Rollover for cooperating operators. Furthermore, in the STSS Rollovers, I think the DNSKEY_K_* notations should be replaced with DNSKEY_S_*. Best regards, Matthijs On 04/19/2011 11:59 AM, Antoin Verschuren wrote: > On 18-04-11 19:41, Peter Koch wrote: > >> Please review the document and send any comments you may have to the >> list. If you have no comments but support (or do not support) the >> document being published, please send that information to the list. > > Another observation on the examples in section 4.1.*: > > -I don't understand why the DNSKEY RRset should be signed with the ZSK. > It's not wrong, but I don't see the point of signing the DNSKEY RRset > with a ZSK. It's not needed and enlarges the zone. It's sufficiant if > the DNSKEY RRset is signed by the KSK only. > All RRSIG_Z_*(DNSKEY) can be removed. > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrp7BAAoJEA8yVCPsQCW5MugH/0TfLlGWdoAUHuZi07yXY3s4 EjhCU2Tp/qXMmlQxDsl5ifMAs+Gqmj0lFHglm+SOxwBgS8mdIwj/gV2tZWbffPYR 1AAoF3UPzZd+Ubkct04SmzneGmpaKGi3KZOJJOXXntqvM50/rGj/Aog4Ip8V1uxi MstFYFOcB+cCS6VlagDcHi1Z9Ze0URfZI14t+gqYP9g64EmA96Wrum9DxpmwZZq5 /au0RWyozfnpa0d84k9tS2FHFjZelpX+pEYBg1p3KBptpcPREuVz/S8U9UeSkepx NlxHk/hlc2dyz9Fd+txwB95gyNDtxNGeaHUhdBO5gSWS7iAAltoMc+iYReC0m9A= =zChq -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Apr 20 02:06:38 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6CEDE06C1 for ; Wed, 20 Apr 2011 02:06:38 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNzQJ8+KZBIw for ; Wed, 20 Apr 2011 02:06:38 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id B27C5E0710 for ; Wed, 20 Apr 2011 02:06:37 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:215:afff:fed2:e121] ([IPv6:2001:7b8:206:1:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3K96aLj064768; Wed, 20 Apr 2011 11:06:36 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAEA21C.1030900@nlnetlabs.nl> Date: Wed, 20 Apr 2011 11:06:36 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Antoin Verschuren References: <20110418174138.GH22688@x28.adm.denic.de> <4DAD866C.2050806@sidn.nl> In-Reply-To: <4DAD866C.2050806@sidn.nl> X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Wed, 20 Apr 2011 11:06:36 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 09:06:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, On 04/19/2011 02:56 PM, Antoin Verschuren wrote: > On 18-04-11 19:41, Peter Koch wrote: > >> Please review the document and send any comments you may have to the >> list. If you have no comments but support (or do not support) the >> document being published, please send that information to the list. > > More comments: > > Section 4.1.2 last paragraph: > "In this mechanism, there are periods where there are two DS > RRs at the parent. Since at the moment of writing the protocol for > this interaction has not been developed, further discussion is out of > scope for this document." > > This is strange, as the Double DS rollover mechanism is used furtheron > in the document in section 4.1.3 figure 5. I think this text is a > leftover from a previous version. It is true that an automated rollover > with an in-band interaction has not been developped yet, but this text > seems to sugest that Double-DS has not been invented yet. > And if such interaction were developped, this should be discussed in > section 4.1.3 where Double-DS is defined, as this is what the > interaction is trying to automate. > > When I take section 4.3.5 into considderation, I think that the > Double-DS mechanism is almost mandatory for a parent to implement, > otherwise you cannot accomodate secure child dns operator changes. > Since this mechanism can also be used for regular rollovers, as section > 4.1.3 describes, I think Double-DS will be the default rollover > mechanism, and double signature only an alternative that will not be > deployed by all parents like registries that need to implement these > procedures. They will want to stick to one size fits all. I don't think the Double-DS is mandatory, you can still accommodate the secure child dns operator change with the ZSK Pre-Publish/ KSK Double-Signature approach (Figure 9). > Sugestion: Remove the last paragraph of section 4.1.2 starting at "An > alternative mechanism has been considered." > There's no use in discussing something that doen't excist yet. Consider it done. > section 4.1.3: > "A zone key rollover can be handled ...." > Please use the same syntax: > "A ZSK rollover can be handled..... " > It's less confusing. Ok. > Section 4.1.4 last paragraph: > "Since this > leads to increase in zone and packet size at both child and parent > there are little benefits to a Double-DS rollover with a Single Type > signing scheme." > Same as above. > A Double-DS rollover is the only rollover mechanism you can use during a > secure dns operator change. Even with a Single Type signing scheme. As I said above, it's not. Best regards, Matthijs _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrqIbAAoJEA8yVCPsQCW58voH/0KeQm0/IBXLND6mhR1+JOvW pFh3Lu6PYb8lipa+/Cf/V0Sh5dlzqYOiwpDwBX3j1AfH6CDWuZsa6dAWhZS5B8YW jL5WGnxfHJuOuy5Rd5fPup0dxIoxY1BSrYPy4pb0jra4cs8PEZe7m9vORIlwonw3 pkBBD9GxG4Zlf7FGacy7m5Jw8zhW2dWU2sBYUEVVzD+5FKcNPnIW1dnQuF+3SXMX CZwQ1OoaJ/V9biIawJivJttfWCNIXd/tihMb+NXgsiEkvsNsNL5Gkr461/FeXMvA I2TNO+DHzSwoHkPaurS08sVZsBrWErG30AqCdjerOnAY7R9xQihaQV/IaLVAcko= =NvfN -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Wed Apr 20 02:53:45 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 73105E06A0 for ; Wed, 20 Apr 2011 02:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80Znc1OWju6w for ; Wed, 20 Apr 2011 02:53:44 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id 7E2ADE0677 for ; Wed, 20 Apr 2011 02:53:44 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3K9rgRj007192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Wed, 20 Apr 2011 11:53:42 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 20 Apr 2011 11:53:42 +0200 Message-ID: <4DAEAD37.1000705@sidn.nl> Date: Wed, 20 Apr 2011 11:53:59 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Matthijs Mekking References: <20110418174138.GH22688@x28.adm.denic.de> <4DAD866C.2050806@sidn.nl> <4DAEA21C.1030900@nlnetlabs.nl> In-Reply-To: <4DAEA21C.1030900@nlnetlabs.nl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 09:53:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20-04-11 11:06, Matthijs Mekking wrote: Hi Matthijs, > > I don't think the Double-DS is mandatory, you can still accommodate the > secure child dns operator change with the ZSK Pre-Publish/ KSK > Double-Signature approach (Figure 9). Aagh, I missed that one. Figure 9 is not possible! RRSIG_K_B(DNSKEY) can never be generated at child A, because he does not have B's private key ! Same for RRSIG_K_A(DNSKEY) at child B. Child B cannot create sigs with child A's private key ! This example is wrong. Really, the only way it can work is with double-DS Child A can only generate RRSIG_K_A(DNSKEY) and child B can only generate RRSIG_K_B(DNSKEY) Both DS_A and DS_B need to be at the parrent for the rollover. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrq03AAoJEDqHrM883AgnMFYIAM89rhb2TZIJk/AaJHDAHniW 3bTbbRKureJz1xNr0sMTXr3cpJ/jxzIxsG8MgivvL++DvgNTQdqJlTzqoR4sFUcr to6J7hZEZZmquo58MTeBWMFlepHRJVKk3jiJKUvP+9Q1mxSAAtP/E80VyAXTywH1 HvT9VunB29sQ2xI/w9MhkeP3zAQtoCFDMRb93kkcmhRbOU3Jud79PKcpu0IjDS7J 6M2dilK5L41XU/7tD8SrRTbiEWJvgTeRljeBpwmBWlmGfB5hPAAKBgDH1Rp7tAzR xoRE0p0UJoKIFPqTal4Kmds6R4aPmPS3T/qzZuG8VyZJbDDtaN+NPa24MCdAVzE= =9Ogx -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Apr 20 02:59:01 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFF60E0689 for ; Wed, 20 Apr 2011 02:59:01 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mmYMOoUBk7G for ; Wed, 20 Apr 2011 02:59:01 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 158E5E0677 for ; Wed, 20 Apr 2011 02:59:00 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:222:15ff:fe7a:e15c] ([IPv6:2001:7b8:206:1:222:15ff:fe7a:e15c]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3K9wxGs037932; Wed, 20 Apr 2011 11:58:59 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAEAE63.1000605@nlnetlabs.nl> Date: Wed, 20 Apr 2011 11:58:59 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Antoin Verschuren References: <20110418174138.GH22688@x28.adm.denic.de> <4DAD866C.2050806@sidn.nl> <4DAEA21C.1030900@nlnetlabs.nl> <4DAEAD37.1000705@sidn.nl> In-Reply-To: <4DAEAD37.1000705@sidn.nl> X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 20 Apr 2011 11:58:59 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 09:59:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Antoin, It is assumed that in the cooperating case, both operators allow publishing of the signatures. So they don't create the signature themselves, they merely copy the signature and publish it in their version of the zone. Best regards, Matthijs On 04/20/2011 11:53 AM, Antoin Verschuren wrote: > On 20-04-11 11:06, Matthijs Mekking wrote: > > Hi Matthijs, > > >> I don't think the Double-DS is mandatory, you can still accommodate the >> secure child dns operator change with the ZSK Pre-Publish/ KSK >> Double-Signature approach (Figure 9). > > Aagh, I missed that one. > Figure 9 is not possible! > > RRSIG_K_B(DNSKEY) can never be generated at child A, because he does not > have B's private key ! > Same for RRSIG_K_A(DNSKEY) at child B. Child B cannot create sigs with > child A's private key ! > > This example is wrong. > > Really, the only way it can work is with double-DS > > Child A can only generate RRSIG_K_A(DNSKEY) > and child B can only generate RRSIG_K_B(DNSKEY) > > Both DS_A and DS_B need to be at the parrent for the rollover. > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrq5jAAoJEA8yVCPsQCW5VzcIAM86FiZLKoWH6pbOw++dyU8T DOPVVOd8IVkebTvdA/45fr1KGG4p8mGd9hFPrTd77d41WWx2EeX8vYxzibnaVlUn u/6ShOeEWfIBweRBAOnog+Mgi/g9EM6Mi3px+koQLkwBykoTwrAAZ1gPtwoIw0OL dekY2FBe2w/L8dLLO/pnLpOY9c+wkuHiUKqmMNYRjwrpkOW+lpxEiU/RwHbmCDQK I2pm9h6A8Pc3Y4ZMK6mCMA8xE2gN5Diti6rp5wMNHHQd07cAARx07QQWhaC9NXI1 mEnSP2cvTMh8rM1zmSzLZ4BIrsX2kK+2T20mET/I5GpAWRkmnNi4X0CzZOAUUdc= =XslP -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Wed Apr 20 04:42:52 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB9C9E0680 for ; Wed, 20 Apr 2011 04:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0obYnBw4Bn3 for ; Wed, 20 Apr 2011 04:42:51 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfc.amsl.com (Postfix) with ESMTP id B5B19E05F5 for ; Wed, 20 Apr 2011 04:42:51 -0700 (PDT) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p3KBgonG010757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Wed, 20 Apr 2011 13:42:50 +0200 Received: from [192.168.129.125] (192.168.129.125) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 20 Apr 2011 13:42:49 +0200 Message-ID: <4DAEC6CA.7060808@sidn.nl> Date: Wed, 20 Apr 2011 13:43:06 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Matthijs Mekking References: <20110418174138.GH22688@x28.adm.denic.de> <4DAD866C.2050806@sidn.nl> <4DAEA21C.1030900@nlnetlabs.nl> <4DAEAD37.1000705@sidn.nl> <4DAEAE63.1000605@nlnetlabs.nl> In-Reply-To: <4DAEAE63.1000605@nlnetlabs.nl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 11:42:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20-04-11 11:58, Matthijs Mekking wrote: > Hi Antoin, > > It is assumed that in the cooperating case, both operators allow > publishing of the signatures. > > So they don't create the signature themselves, they merely copy the > signature and publish it in their version of the zone. Ok, so that's a second option I hadn't thought about, because it is impractical in practice. I guess in theory this will work, but only if the zone, DNSKEYset and RRSIGs are static for the complete rollover period. In the case I have seen and discussed so far, only the public keys were exchanged, and not the signatures. Exchanging signatures takes again another step in the process, as a new signature can only be created after recieving the new keys. And it only works if the signatures have an expire that is longer than the transfer process. When you use the Doule-DS rollover, child A only needs to recieve B's new public keys, and signs it only with KSK_A. child B has allready queried A's public keys and has allready signed the DNSKEY set with only KSK_B. For the Double-DS method, that is sufficiant. I guess you can now also have child A copy RRSIG_K_B(DNSKEY) and child B copy RRSIG_K_A(DNSKEY), but this is another step in the process that consumes propagation time and extra interaction. It also disallows the childs to refresh the signatures when they expire, unless they have yet another interaction. This was the scheme I had in mind with Double-DS and cooperating DNS providers: - ------------------------------------------------------------ initial | Double DS | ------------------------------------------------------------ Parent: NS_A NS_A DS_A DS_A DS_B ------------------------------------------------------------ Child at A: Child at A: Child at B: SOA_A0 SOA_A1 SOA_B0 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) NS_A NS_A NS_B RRSIG_Z_A(NS) RRSIG_Z_A(NS) RRSIG_Z_B(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A DNSKEY_K_A DNSKEY_Z_B DNSKEY_Z_B RRSIG_K_A(DNSKEY) DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ ------------------------------------------------------------ Redelegation | post migration | ------------------------------------------------------------ Parent: NS_B NS_B DS_A 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) NS_B NS_B NS_B RRSIG_Z_A(NS) RRSIG_Z_B(NS) RRSIG_Z_B(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_B DNSKEY_K_A DNSKEY_K_A RRSIG_K_B(DNSKEY) DNSKEY_K_B DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ There is less data to exchange. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNrsbKAAoJEDqHrM883Agnq7IH/2S1bb0639QslS8bytaOws03 Urqcxe++tryi9L2PYX8GFurU6WrlspgK5ynzYQdOrcuuDHRiMPuCdXQhM4mtMF8M GdoyZ9UcKgTn4Ae8kvRt8op5NBE9ZT+NAHjbLbK/qGuh7fffgB2iDP8EEXETtAki PO/L2Cf9tOOLF2PpGdi2w3ups94n1/xRtml23MV/MaBn5YBh+Fh+o8He7KopaaWq Or5JZRmywWlZRmQAgDJsYNPD61xrFICV/oocVcOg2KlTYg/2JFK4eSdJgDOBoS8u EZ2PEbXvbnt+MbomvSLz3xt1Diw9ETPorEuAJtUyVjXOeHVOe8TC/l2iaYMUdBE= =3ScI -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Apr 20 05:31:42 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E30B8E0722 for ; Wed, 20 Apr 2011 05:31:42 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxDjBCH5aJ5M for ; Wed, 20 Apr 2011 05:31:41 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id A6533E07D6 for ; Wed, 20 Apr 2011 05:31:39 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:222:15ff:fe7a:e15c] ([IPv6:2001:7b8:206:1:222:15ff:fe7a:e15c]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3KCVbW2062334; Wed, 20 Apr 2011 14:31:37 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAED229.3030406@nlnetlabs.nl> Date: Wed, 20 Apr 2011 14:31:37 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Antoin Verschuren References: <20110418174138.GH22688@x28.adm.denic.de> <4DAD866C.2050806@sidn.nl> <4DAEA21C.1030900@nlnetlabs.nl> <4DAEAD37.1000705@sidn.nl> <4DAEAE63.1000605@nlnetlabs.nl> <4DAEC6CA.7060808@sidn.nl> In-Reply-To: <4DAEC6CA.7060808@sidn.nl> X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 20 Apr 2011 14:31:38 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 12:31:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I agree that the Double-DS approach is more practicable than the current rollover for cooperating operators. This is mentioned very briefly in the -06 version (last paragraph 4.3.5.1). However, we do want to provide an alternative for registries and registrars that does not allow a Double-DS rollover scheme. I do want to describe the cons of the current approach in more detail (the ones you have mentioned in your mail). If it is necessary to add the corresponding figure, it should then probably go into an appendix. Proposed text (to replace the last paragraph in 4.3.5.1): The requirement to exchange signatures has a couple of drawbacks. It requires more operational overhead, because not only the operators have to exchange public keys, they also have to exchange the signatures of the new DNSKEY RRset. Also, it disallows the children to refresh the signatures when they expire for a certain period. Both drawbacks do not exist if you replace the Double Signature KSK rollover with a Double-DS KSK rollover. Thus, if the registry and registrars allow for DS records to be published, that do not point to a published DNSKEY in the child zone, the Double-DS KSK rollover is preferred (also known as Pre- Publication KSK Rollover, see Figure 5), in combination with the Pre- Publish ZSK rollover. This does not require to share the KSK signatures between the operators. Both the losing and the gaining operator still need to publish the public ZSK of each other. Best regards, Matthijs On 04/20/2011 01:43 PM, Antoin Verschuren wrote: > On 20-04-11 11:58, Matthijs Mekking wrote: >> Hi Antoin, > >> It is assumed that in the cooperating case, both operators allow >> publishing of the signatures. > >> So they don't create the signature themselves, they merely copy the >> signature and publish it in their version of the zone. > > Ok, so that's a second option I hadn't thought about, because it is > impractical in practice. I guess in theory this will work, but only if > the zone, DNSKEYset and RRSIGs are static for the complete rollover period. > > In the case I have seen and discussed so far, only the public keys were > exchanged, and not the signatures. Exchanging signatures takes again > another step in the process, as a new signature can only be created > after recieving the new keys. And it only works if the signatures have > an expire that is longer than the transfer process. > > When you use the Doule-DS rollover, child A only needs to recieve B's > new public keys, and signs it only with KSK_A. child B has allready > queried A's public keys and has allready signed the DNSKEY set with only > KSK_B. > For the Double-DS method, that is sufficiant. > > I guess you can now also have child A copy RRSIG_K_B(DNSKEY) and child B > copy RRSIG_K_A(DNSKEY), but this is another step in the process that > consumes propagation time and extra interaction. It also disallows the > childs to refresh the signatures when they expire, unless they have yet > another interaction. > > This was the scheme I had in mind with Double-DS and cooperating DNS > providers: > > ------------------------------------------------------------ > initial | Double DS | > ------------------------------------------------------------ > Parent: > NS_A NS_A > DS_A DS_A > DS_B > ------------------------------------------------------------ > Child at A: Child at A: Child at B: > SOA_A0 SOA_A1 SOA_B0 > RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) > > NS_A NS_A NS_B > RRSIG_Z_A(NS) RRSIG_Z_A(NS) RRSIG_Z_B(NS) > > > DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A > DNSKEY_K_A DNSKEY_Z_B DNSKEY_Z_B > RRSIG_K_A(DNSKEY) DNSKEY_K_A DNSKEY_K_A > DNSKEY_K_B DNSKEY_K_B > RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) > ------------------------------------------------------------ > > ------------------------------------------------------------ > Redelegation | post migration | > ------------------------------------------------------------ > Parent: > NS_B NS_B > DS_A 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) > > NS_B NS_B NS_B > RRSIG_Z_A(NS) RRSIG_Z_B(NS) RRSIG_Z_B(NS) > > > DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B > DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_B > DNSKEY_K_A DNSKEY_K_A RRSIG_K_B(DNSKEY) > DNSKEY_K_B DNSKEY_K_B > RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) > > > ------------------------------------------------------------ > > There is less data to exchange. > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNrtIpAAoJEA8yVCPsQCW53+EIALPXM+p5pHPyc3ZmEXvbwMJz YEUanA6RJioVDrM2UCtu6c5MToYTBI4tLUbTzNJy7ngR36MG55GkHnasIHKA3Jxw K8ETro5Y1FZsxRS4q5FWXCVNBcd62/W0b2oI3LwZZ3d25oH+1QWfothzmmQMgkSH QFRd5iJXbL3iiNEaC+VG322eNNn65LUwtu32mMwnng0Gj64GV8dKjCk+84ct2EIK aQQvNHEf2bgrxtyS+7KYP2HiVaInb/EU6d+JzsVwIdUHuJgEi8OU/9zBEFbBZJPf DDd0hE2TLZbyup7Fcy9v3vbmDaqYt0OhilIoTK2JWG9IMrDNsP59Z8bgFPvkh3c= =ukah -----END PGP SIGNATURE----- From paul@xelerance.com Wed Apr 20 07:30:52 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 538C2E06EE for ; Wed, 20 Apr 2011 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8zj5wRhnSJY for ; Wed, 20 Apr 2011 07:30:51 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id AE336E0613 for ; Wed, 20 Apr 2011 07:30:51 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id E174AC60C; Wed, 20 Apr 2011 10:30:48 -0400 (EDT) Date: Wed, 20 Apr 2011 10:30:48 -0400 (EDT) From: Paul Wouters To: Matthijs Mekking In-Reply-To: <4DAE9CA7.2050702@nlnetlabs.nl> Message-ID: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAE9CA7.2050702@nlnetlabs.nl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 14:30:52 -0000 On Wed, 20 Apr 2011, Matthijs Mekking wrote: >> 2) I believe is the more common case. It is eve more important to child >> centric zones. Adding a DS won't hurt, and leaving the old DS in there >> won't hurt either. Once most of the child centric zones finally caught >> up with the new parents, the old DS can be removed. >> >> Perhaps it is worth splitting the non-cooperative in these use cases? > > The losing operator still needs to publish the DNSKEYs of the winning > operator. Otherwise, you can get in a situation where a validator > fetches RRs from the gaining operators name server, but still have the > losing operator DNSKEY RRset in cache (that thus does not contain the > DNSKEYs of the winning operator). How would the RRs be fetched from the new operator? That means the NS set was updated. For which it needed the new DS to confirm the NS set. In which case there might be old (validated) cache from the losing operator, but no new records from that losing operator needing old DNSKEYs? Paul From george.barwood@blueyonder.co.uk Wed Apr 20 14:49:02 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0C3DE0751 for ; Wed, 20 Apr 2011 14:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZggolwFJk0Y for ; Wed, 20 Apr 2011 14:49:02 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by ietfc.amsl.com (Postfix) with ESMTP id 134B7E0738 for ; Wed, 20 Apr 2011 14:49:01 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.1]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110420214858.CHKK14839.mtaout01-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Wed, 20 Apr 2011 22:48:58 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QCfGc-0001WQ-OD; Wed, 20 Apr 2011 22:48:58 +0100 Message-ID: <876A07254E3241BB8C1108B4DD667D6E@local> From: "George Barwood" To: "Joe Abley" References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> Date: Wed, 20 Apr 2011 22:50:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=zhePSyoPQsMA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=a5Gf7U6LAAAA:8 a=48vgC7mUAAAA:8 a=8rAFeLOxhePVAovYH4oA:9 a=wPNLvfGTeEIA:10 a=yHIqe9kG5mgA:10 a=vH2QUTMcjcwA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 21:49:03 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZSBBYmxleSIgPGphYmxl eUBob3Bjb3VudC5jYT4NClRvOiAiR2VvcmdlIEJhcndvb2QiIDxnZW9yZ2UuYmFyd29vZEBibHVl eW9uZGVyLmNvLnVrPg0KQ2M6ICJQZXRlciBLb2NoIiA8cGtAREVOSUMuREU+OyAiSUVURiBETlNP UCBXRyIgPGRuc29wQGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBBcHJpbCAxOCwgMjAxMSA5OjI2 IFBNDQpTdWJqZWN0OiBSZTogW0ROU09QXSBXR0xDIDxkcmFmdC1pZXRmLWRuc29wLXJmYzQ2NDFi aXMtMDYudHh0PiBbMjAxMS0wNS0xN10NCg0KDQoNCj4gSSBkb24ndCB0aGluayBpdCdzIHVucmVh c29uYWJsZSBmb3IgdGhlc2UgZmFjdHMsIGFzIGFuIGluamVjdCB0byBhbiBhcHByb3ByaWF0ZSB0 aHJlYXQgYW5hbHlzaXMsIHRvIHJlc3VsdCBpbiBhIA0KPiByZWNvbW1lbmRhdGlvbiB0byBvcGVy YXRlIHdpdGggYSBaU0svS1NLIHNwbGl0IC0tIHN1Y2ggYW4gYXJyYW5nZW1lbnQgZmFjaWxpdGF0 ZXMgZGlmZmVyZW50IGxldmVscyBvZiBwcm90ZWN0aW9uIA0KPiBmb3IgZWFjaCBrZXkgY29tbWVu c3VyYXRlIHdpdGggdGhlIGVhc2Ugd2l0aCB3aGljaCBpdCBtaWdodCBiZSByb2xsZWQgYW5kIHRo ZSBmcmVxdWVuY3kgd2l0aCB3aGljaCBpdCBpcyByZXF1aXJlZCB0byA+IGJlIHVzZWQuDQoNCj4g SSdtIG5vdCBzYXlpbmcgaXQncyB0aGUgb25seSB3YXkgdG8gZ28sIGJ1dCBJIHRoaW5rIHJlY29t bWVuZGluZyBhZ2FpbnN0IHRoZSBwcmFjdGljZSBtYWtlcyBsaXR0bGUgc2Vuc2UuDQoNClRoZSBh cmd1bWVudHMgZm9yICBvcGVyYXRpbmcgd2l0aCBhIHNwbGl0IHN0aWxsIHNlZW0gdmVyeSB3ZWFr IHRvIG1lLg0KVGhlIG9ubHkgc3Ryb25nIGFyZ3VtZW50IHNlZW1zIHRvIGJlIHRoYXQgaWYgdGhl cmUgYXJlIGhpZ2ggY29zdHMgZm9yIHJvbGxpbmcgdGhlIEtTSywNCnRoZSByaXNrIG9mIHRob3Nl IGNvc3RzIGJlaW5nIGluY3VycmVkIGNhbiBiZSByZWR1Y2VkIGJ5IGhhdmluZyBzdHJvbmdlciBL U0sgcHJvdGVjdGlvbi4NCkhvd2V2ZXIgcm9sbGluZyB0aGUgS1NLIHNob3VsZCBiZSBlYXN5LCBz aW5jZSBpdCBpcyBnb29kIHNlY3VyaXR5IHByYWN0aWNlIHRvIGNoYW5nZQ0Kc2VjcmV0IGtleXMg cmVndWxhcmx5Lg0KDQpBbiBhZGRpdGlvbmFsIHBvaW50IDogaWYgYSBzcGxpdCBpcyB1c2VkLCBi eSBwdWJsaXNoaW5nIGEgRFMgcmVjb3JkIGZvciB0aGUgWlNLLA0KdGhlIHBlcmZvcm1hbmNlIGJl bmVmaXRzIG9mIHRoZSBzaW5nbGUga2V5IHNjaGVtZSBjYW4gYmUgb2J0YWluZWQgKCB0aGUgRE5T S0VZDQpSUnNldCBjYW4gYmUgZnVsbHkgdmFsaWRhdGVkIHdpdGhvdXQgZG9pbmcgYW4gZXhwZW5z aXZlIGFuZCBzbG93IHB1YmxpYyBrZXkgb3BlcmF0aW9uICkuDQpJZiB0aGUgRFMgcmVjb3JkIGlz IG5vdCBmb3IgdGhlIGN1cnJlbnQgWlNLLCBpdCB3aWxsIHN0aWxsIHdvcmssIGJ1dCBzbG93ZXIg KCB0aGUgRE5TS0VZDQpzaWduYXR1cmUgd2lsbCBuZWVkIHRvIGJlIGNoZWNrZWQgKS4NCg0KRnVs bHkgYXV0b21hdGljIHVwZGF0ZXMgb2YgdGhlIHBhcmVudCBEUyBSUnNldCB3b3VsZCBtYWtlIHRo aXMgdGVjaG5pcXVlIG1vcmUgcHJhY3RpY2FsLg0KDQpHZW9yZ2UNCg0KDQo= From jabley@hopcount.ca Wed Apr 20 15:01:37 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B464E0777 for ; Wed, 20 Apr 2011 15:01: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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSmVj6fwoKEx for ; Wed, 20 Apr 2011 15:01:36 -0700 (PDT) Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfc.amsl.com (Postfix) with ESMTP id 8C33CE0728 for ; Wed, 20 Apr 2011 15:01:36 -0700 (PDT) Received: from [199.212.90.21] (helo=dh21.r1.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QCfSm-000F5W-Vs; Wed, 20 Apr 2011 22:01:33 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Abley X-Priority: 3 In-Reply-To: <876A07254E3241BB8C1108B4DD667D6E@local> Date: Wed, 20 Apr 2011 18:01:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7924C40F-7076-4D73-A27A-BBEA10C9A50C@hopcount.ca> References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <876A07254E3241BB8C1108B4DD667D6E@local> To: George Barwood X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Cc: Peter Koch , IETF DNSOP WG Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 20 Apr 2011 22:01:37 -0000 On 2011-04-20, at 17:50, George Barwood wrote: > The arguments for operating with a split still seem very weak to me. Since you're proposing a SHOULD NOT, I think the pertinent point is (a) = whether it does any harm, and (b) whether it is useful in some = circumstances. I have seen no discussion of any harm, and several examples of why it = might be useful. Hence, to me, SHOULD NOT does not seem appropriate. > However rolling the KSK should be easy, since it is good security = practice to change > secret keys regularly. The first clause seems like a rampant generalisation, and the second is = contentious (see ekr's various comments on this list regarding the = cryptographic benefit of rolling non-compromised RSA keys). > Fully automatic updates of the parent DS RRset would make this = technique more practical. Given that there is no sign of such a mechanism in general, and (in my = opinion) there's at least one significant use case where any such = mechanism is unlikely to be deployed (the root zone), I don't see a lot = of practical value in that comment, either. Joe= From matthijs@nlnetlabs.nl Thu Apr 21 00:17:10 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 994E4E0712 for ; Thu, 21 Apr 2011 00:17:10 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnoxIDfUpa00 for ; Thu, 21 Apr 2011 00:17:09 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DB3EE070B for ; Thu, 21 Apr 2011 00:17:09 -0700 (PDT) Received: from [192.168.1.9] (ip123-112-174-82.adsl2.static.versatel.nl [82.174.112.123]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3L7H5o6052526; Thu, 21 Apr 2011 09:17:06 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DAFD9F1.5030904@nlnetlabs.nl> Date: Thu, 21 Apr 2011 09:17:05 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Paul Wouters References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAE9CA7.2050702@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [213.154.224.1]); Thu, 21 Apr 2011 09:17:06 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 21 Apr 2011 07:17:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 04/20/2011 04:30 PM, Paul Wouters wrote: > On Wed, 20 Apr 2011, Matthijs Mekking wrote: > >>> 2) I believe is the more common case. It is eve more important to child >>> centric zones. Adding a DS won't hurt, and leaving the old DS in there >>> won't hurt either. Once most of the child centric zones finally caught >>> up with the new parents, the old DS can be removed. >>> >>> Perhaps it is worth splitting the non-cooperative in these use cases? >> >> The losing operator still needs to publish the DNSKEYs of the winning >> operator. Otherwise, you can get in a situation where a validator >> fetches RRs from the gaining operators name server, but still have the >> losing operator DNSKEY RRset in cache (that thus does not contain the >> DNSKEYs of the winning operator). > > How would the RRs be fetched from the new operator? That means the NS > set was updated. For which it needed the new DS to confirm the NS set. > In which case there might be old (validated) cache from the losing > operator, > but no new records from that losing operator needing old DNSKEYs? Suppose 11111 is the keytag of the DNSKEY of the losing operator and 22222 is the keytag of the DNSKEY of the winning operator. I have still in my cache the DNKEY RRset with only the 11111 keytag. I have received a request for . It is not in the cache, I am going to query for it. The NS set was updated, pointing me to the version of the zone of the winning operator. www.example.com A 1.2.3.4 www.example.com RRSIG A ... 22222 example.com ... Signature made with keytag 22222 does not match the cached DNSKEY RRset with key 11111. Best regards, Matthijs > > Paul > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNr9nxAAoJEA8yVCPsQCW5UFkH/ijaxFmbtTz/24p4lI2FPo9e UABSsdrThqf5Ttd7HxHCSeZAIgjduzN5srJ8DRSJRvJJvTaafDUvvgbY8T+PDbCH I1+BXzzsJtaXPwf2C0c8rZEQYm+ouUVvUPeD8mHaNHR86/2XHDksbZBz/BPaP8l9 +hYwTfrC2ElwBvUBg4uIap9RBGL2oRXjnlKlYdRLGnBVCXmgD9cYUGrBbQXl6UpX IoWTkwNzeZY04B7NbTseCo9SJs6VWLSYKGrvP2ADjtt3uWPLzKtVfLFg8zf5PCFf KXjZ8KBOFJwsLla9FcTkKRwhUFqFlGRkWTzMSENoCivOHJHFx5BC7Nrc9l4sEIY= =fTTo -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Thu Apr 21 06:26:26 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1253CE06A5 for ; Thu, 21 Apr 2011 06:26:26 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2NL-rqFYWpM for ; Thu, 21 Apr 2011 06:26:25 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfc.amsl.com (Postfix) with ESMTP id 1BAD7E0655 for ; Thu, 21 Apr 2011 06:26:24 -0700 (PDT) X-ASG-Debug-ID: 1303392382-0369491639084b0001-lPZdTi Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id bnfNYGOPG6lSew4X for ; Thu, 21 Apr 2011 15:26:22 +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 CDDDDE407F for ; Thu, 21 Apr 2011 15:19:43 +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 gS8Qg23T-pyt for ; Thu, 21 Apr 2011 15:19:43 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id AEAAFE4052 for ; Thu, 21 Apr 2011 15:19:43 +0200 (CEST) From: "Marc Lampo" To: "'IETF DNSOP WG'" Date: Thu, 21 Apr 2011 15:19:43 +0200 (CEST) X-ASG-Orig-Subj: comments on Message-ID: <00f501cc0027$b4dc4200$1e94c600$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Content-Language: en-za Thread-Index: AcwAJ7SV2/BSRe9ySS+wLv4LBH4d0g== X-Originating-IP: [172.20.1.130] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1303392382 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: [DNSOP] comments on 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, 21 Apr 2011 13:26:26 -0000 Hello, As promised during IETF80, Prague, my comments on this draft : 2.2. KSK Rollovers ... In the KSK case this can never be a problem as the KSK is only used for one signature ... Administrators should use the KSK only to sign the DNSKEY RRset, but implementations may allow to use the KSK for *all* RRset's. --> shouldn't the "is only used" be "should only be used" ? (next paragraph) Trust in the KSK is either due to the existence of a DS record in the parent zone (which is itself trusted) or ... I object to the phrasing : "which is itself trusted". It should not be interpreted that the mere existence of a DS record makes it trustworthy. In reality, the DS record is trusted because the accompanying RRSIG can be validated. 2.3. Summary (only) two methods : ZSK Method and KSK Method. In draft-ietf-dnsop-rfc4641bis-06.txt, section 3.1, there is motivation to not always distinguish between KSK and ZSK. (While I am not in favour of global recommendation for this (no distinction), if an administrator chooses not to differentiate, this does introduce a third method, combining both. I think this draft should describe associated issues as well) In addition, in my comment on that draft, earlier this week, I contributed my observation that some DNSSEC'd domains use 3 keys for rollover : initial situation : key1 & key2 start of rollover : add key3 --> key1 & key2 & key3 end of rollover : remove key1 --> key2 & key3 I don't think this is covered by any of the Methods in this draft (of key-timing). Leave it to the authors if they want to consider and include this method for timing considerations. For clarity : I did *not* invent this method, I merely noticed it being used "out there" ! Nor do I know if the authors of rfc4641bis will include this method of rollover at all ! 3.1 Key States Ready : The new key data has been published for long enough to guarantee that any previous versions of it have expired from cache. I object to the phrasing : "previous versions of it". (as long as a key exists, all "versions" are identical (keyid, algorithm, value); What is really meant : "any previous versions of the DNSKEY RRset". Where the next "preceding" version of the DNSKEY RRset, is a RRset where the new key is not yet present, with its DNSKEY record) Retired : The key is in the zone but a successor key has become active. As there may still be information in caches that that (word is present twice !) require use of the key, it is being retained until this information expires. I would additionally state : The key, in Retired state, is no longer used for generating RRSIG's. Also, instead of "information in caches", I propose : As there may be RRSIG's present in caches, RRSIG's that were generated with this key, the key is being retained until those RRSIG's expire themselves. (because : "information" is really "RRSIG's generated with this key", isn't it ?) 3.2.1 - 3.2.2 - 3.2.3 - 3.3.1 - 3.3.2 - 3.3.3 (each time : the time flow) There is always an event "Tgen", but there is never an event "generation of the new key". To be consistent, the generation of the new key should be added. However, this complicates the time flow. My recommendation is not to show "Tgen" at all. It is obvious that a key must be generated before it can be published. But I don't think showing this event in the time flow has any additional contribution. I do realise that the text that goes with this event states that Tgen might be the generation of "a pool of keys". OK - perhaps we can live with this single "Tgen" + text; otherwise there is no reason for the state "Generated", and keys would come "out of nowhere" to the state "Published", which might be even more confusing. Kind regards, Marc Lampo Security Officer       EURid     Woluwelaan 150         1831 Diegem - Belgium     marc.lampo@eurid.eu     http://www.eurid.eu From paul@xelerance.com Thu Apr 21 08:19:08 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2C8F0E0752 for ; Thu, 21 Apr 2011 08:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBc5D-g-FnGj for ; Thu, 21 Apr 2011 08:19:07 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 94DB1E0705 for ; Thu, 21 Apr 2011 08:19:07 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id D8DC9C5BB; Thu, 21 Apr 2011 11:19:04 -0400 (EDT) Date: Thu, 21 Apr 2011 11:19:04 -0400 (EDT) From: Paul Wouters To: Matthijs Mekking In-Reply-To: <4DAFD9F1.5030904@nlnetlabs.nl> Message-ID: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAE9CA7.2050702@nlnetlabs.nl> <4DAFD9F1.5030904@nlnetlabs.nl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 21 Apr 2011 15:19:08 -0000 On Thu, 21 Apr 2011, Matthijs Mekking wrote: > Suppose 11111 is the keytag of the DNSKEY of the losing operator and > 22222 is the keytag of the DNSKEY of the winning operator. > > I have still in my cache the DNKEY RRset with only the 11111 keytag. > I have received a request for . > It is not in the cache, I am going to query for it. > The NS set was updated, pointing me to the version of the zone of the > winning operator. How is the NS set "updated" without validating that NS set using the DNSKEY set and DS record of the winning operator? > www.example.com A 1.2.3.4 > www.example.com RRSIG A ... 22222 example.com ... > > Signature made with keytag 22222 does not match the cached DNSKEY RRset > with key 11111. But you can only get here if you had followed the new glue at the TLD, validated the new NS set at the new operator, using its new DNSKEY set, for which you would need the new DS. So by the time you're passed the NS set, you have all the DNSKEY's needed for other zone content. The situation described in the draft cannot happen for proper validators. Paul From Ed.Lewis@neustar.biz Thu Apr 21 08:30:25 2011 Return-Path: X-Original-To: dnsop@ietfc.amsl.com Delivered-To: dnsop@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9064CE07C5 for ; Thu, 21 Apr 2011 08:30:25 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMIJTZqSiYN4 for ; Thu, 21 Apr 2011 08:30:25 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfc.amsl.com (Postfix) with ESMTP id AE47BE0655 for ; Thu, 21 Apr 2011 08:30:24 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p3LFVJDL004875; Thu, 21 Apr 2011 11:31:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.105] by work-laptop-2 (PGP Universal service); Thu, 21 Apr 2011 11:30:18 -0400 X-PGP-Universal: processed; by work-laptop-2 on Thu, 21 Apr 2011 11:30:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAE9CA7.2050702@nlnetlabs.nl> <4DAFD9F1.5030904@nlnetlabs.nl> Date: Thu, 21 Apr 2011 11:30:14 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [DNSOP] validating referrals was Re: WGLC <...rfc4641bis... 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, 21 Apr 2011 15:30:25 -0000 At 11:19 -0400 4/21/11, Paul Wouters wrote: >But you can only get here if you had followed the new glue at the TLD, >validated the new NS set at the new operator, using its new DNSKEY set, >for which you would need the new DS. So by the time you're passed the >NS set, you have all the DNSKEY's needed for other zone content. You don't have to pre-validate hints (referrals). In fact, it's better if you don't. >The situation described in the draft cannot happen for proper validators. I'd design a validating iterative resolver to be goal-directed and thus depth-first. As one traverses from the root (or last cached point) to the answer, relying on optimism is expedient. Once you get the suspected answer and then apply validation - if the result validates what does it matter if you got there through some shady paths? Once the answer is delivered to the client, then it is wise to spend time validating and caching the hints. If the suspected answer doesn't validate, then it's time to become pessimistic and chunk down the tree via validated referrals. This is the approach I used when writing an early version of a validator (i.e., back in the 20th century). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From matthijs@nlnetlabs.nl Tue Apr 26 06:09:43 2011 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 1DE06E077B for ; Tue, 26 Apr 2011 06:09: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P+SZxXvhQDS for ; Tue, 26 Apr 2011 06:09: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 D69BDE0779 for ; Tue, 26 Apr 2011 06:09:41 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:215:afff:fed2:e121] ([IPv6:2001:7b8:206:1:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3QD9cOf046674; Tue, 26 Apr 2011 15:09:39 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DB6C412.9030707@nlnetlabs.nl> Date: Tue, 26 Apr 2011 15:09:38 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Paul Wouters References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAE9CA7.2050702@nlnetlabs.nl> <4DAFD9F1.5030904@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 26 Apr 2011 15:09:39 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 26 Apr 2011 13:09:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 04/21/2011 05:19 PM, Paul Wouters wrote: > On Thu, 21 Apr 2011, Matthijs Mekking wrote: > >> Suppose 11111 is the keytag of the DNSKEY of the losing operator and >> 22222 is the keytag of the DNSKEY of the winning operator. >> >> I have still in my cache the DNKEY RRset with only the 11111 keytag. >> I have received a request for . >> It is not in the cache, I am going to query for it. >> The NS set was updated, pointing me to the version of the zone of the >> winning operator. > > How is the NS set "updated" without validating that NS set using the > DNSKEY set and DS record of the winning operator? How do you know which DNSKEY is from the winning operator? There are two DS records at the parent (DS 11111, DS 22222) and the first one matches the cached DNSKEY RR. Best regards, Matthijs >> www.example.com A 1.2.3.4 >> www.example.com RRSIG A ... 22222 example.com ... >> >> Signature made with keytag 22222 does not match the cached DNSKEY RRset >> with key 11111. > > But you can only get here if you had followed the new glue at the TLD, > validated the new NS set at the new operator, using its new DNSKEY set, > for which you would need the new DS. So by the time you're passed the > NS set, you have all the DNSKEY's needed for other zone content. > > The situation described in the draft cannot happen for proper validators. > > Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNtsQSAAoJEA8yVCPsQCW5wTsH/0lKs5wCgXeSGlZIP5bNTZW2 a+kqxF4J1683nHUIO1F1b9Mw3x7nZvg2EnZWV3bdjOdy6rVPVUSVwXsJ6dYc8/R9 RDU2bhqw0yS8Ck2os2czyuLTk/jiWOHJsYe8xsY22vVpNgEAWaTXyWlbyMzppuWc QCPNBXqcC3u1MtqN7A64oVF3qN8RJ8FrL7MuF5fM1I5ph+WBYXGnDdT4r9Y+2fhu wRK1U1DcwFgqSpPIC7ksPVNeiCS7AKkIirDeNT0PRkQTEeuycOq5wlUEYmX1YJ7e 2xHB2vWdq04NcCsq5S8SWwFbXV1X9nHZszEBgqWgVgDmvLzZG1ICVVmtBSEJlOc= =oy2D -----END PGP SIGNATURE----- From paul@xelerance.com Tue Apr 26 07:14:24 2011 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 9ADE2E0783 for ; Tue, 26 Apr 2011 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OP5MiM5yF0W for ; Tue, 26 Apr 2011 07:14:23 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7B626E06A8 for ; Tue, 26 Apr 2011 07:14:23 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2DDE9C632; Tue, 26 Apr 2011 10:14:21 -0400 (EDT) Date: Tue, 26 Apr 2011 10:14:20 -0400 (EDT) From: Paul Wouters To: Matthijs Mekking In-Reply-To: <4DB6C412.9030707@nlnetlabs.nl> Message-ID: References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAE9CA7.2050702@nlnetlabs.nl> <4DAFD9F1.5030904@nlnetlabs.nl> <4DB6C412.9030707@nlnetlabs.nl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 26 Apr 2011 14:14:24 -0000 On Tue, 26 Apr 2011, Matthijs Mekking wrote: >> How is the NS set "updated" without validating that NS set using the >> DNSKEY set and DS record of the winning operator? > > How do you know which DNSKEY is from the winning operator? > > There are two DS records at the parent (DS 11111, DS 22222) and the > first one matches the cached DNSKEY RR. Again, how did YOU validate the new NSset if you don't have the right DNSKEY? Please read the original text again. It assumes you somehow got an updated *validated* NSset of the new operator, without having the DNSKEY that validated that NSset. I keep telling you that is not possible. Paul From matthijs@nlnetlabs.nl Tue Apr 26 07:39:09 2011 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 07DF4E07A5 for ; Tue, 26 Apr 2011 07:39: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxw-1IlYGB3i for ; Tue, 26 Apr 2011 07:39: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 CAB48E0799 for ; Tue, 26 Apr 2011 07:39:07 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:215:afff:fed2:e121] ([IPv6:2001:7b8:206:1:215:afff:fed2:e121]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3QEd3ih027152; Tue, 26 Apr 2011 16:39:03 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4DB6D907.4030507@nlnetlabs.nl> Date: Tue, 26 Apr 2011 16:39:03 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Paul Wouters References: <20110418174138.GH22688@x28.adm.denic.de> <0D72B7DB6CA44336A2DFB2412D1F1B1D@local> <4DAD58EA.5020505@sidn.nl> <4DAE9CA7.2050702@nlnetlabs.nl> <4DAFD9F1.5030904@nlnetlabs.nl> <4DB6C412.9030707@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 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.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 26 Apr 2011 16:39:04 +0200 (CEST) Cc: dnsop@ietf.org Subject: Re: [DNSOP] WGLC [2011-05-17] 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, 26 Apr 2011 14:39:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I seem to be unable to find it in the specification that you need to validate the new NS set. So, I don't assume that NS RRset is validated, just updated. I do know that the referral should be authenticated with the DS RRset, signed with the parent key. So, I assume that the following is possible: 1. If that DS is validated with a DNSKEY RR from the parent, and it matches the algorithm and key tag of a DNSKEY RR of the child, the referral is considered authenticated. 2. I can use the NS RRset *from the parent* to resend my query for . 3. From there, I get the new RRset signed with a key from the winning operator. Please show me the text from the specification that tells me that this is impossible. Best regards, Matthijs On 04/26/2011 04:14 PM, Paul Wouters wrote: > On Tue, 26 Apr 2011, Matthijs Mekking wrote: > >>> How is the NS set "updated" without validating that NS set using the >>> DNSKEY set and DS record of the winning operator? >> >> How do you know which DNSKEY is from the winning operator? >> >> There are two DS records at the parent (DS 11111, DS 22222) and the >> first one matches the cached DNSKEY RR. > > Again, how did YOU validate the new NSset if you don't have the right > DNSKEY? Please read the original text again. It assumes you somehow got > an updated *validated* NSset of the new operator, without having the > DNSKEY that validated that NSset. I keep telling you that is not possible. > > Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNttkHAAoJEA8yVCPsQCW5YlgIAIKWTuT4eh1s5YdHjqnUGQOA QYg+qTYpfdxWhv7nH2Lr+Q7tOVgUu4s/U6TvMXls7/wIFP7br0yxL0YLrqoNz489 FBOlIByLq6s7q2J43yK0h2EXsLd8ex5XBP6/jKrHyK0WWWZ24m/t9eQFeBWxWKz0 LqY2fTP7OxAfiByjSKFRsUlnj13hxQX+sqJEFqUwtRP+l2EQFdehq2NFUaHczwYH XDU6z03abbJ00H8/bbHk8Oylt1X5w3ujjE5rsNMsV53G98E9uTFvykU+bjwULCLQ vmAzO2s3yT5CsQCdss7WNMDw5O0c4JAzQplqSHQv0WFBpsqBUPGzQy1Qv9zyORs= =YK1Z -----END PGP SIGNATURE-----