Re: [Gen-art] Gen-ART telechat review of draft-ietf-dnsop-delegation-trust-maintainance-13.txt (updated)
Olafur Gudmundsson <ogud@ogud.com> Tue, 10 June 2014 14:57 UTC
Return-Path: <ogud@ogud.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E235B1A01BB for <gen-art@ietfa.amsl.com>; Tue, 10 Jun 2014 07:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9Ag30PQ7Kec for <gen-art@ietfa.amsl.com>; Tue, 10 Jun 2014 07:57:34 -0700 (PDT)
Received: from smtp69.ord1c.emailsrvr.com (smtp69.ord1c.emailsrvr.com [108.166.43.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82521A019D for <gen-art@ietf.org>; Tue, 10 Jun 2014 07:57:33 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id CD62F2812DD; Tue, 10 Jun 2014 10:57:32 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp9.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id EAE6C2812BE; Tue, 10 Jun 2014 10:57:31 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <57E7A2FA-A306-42B1-96EB-6112F38E5F36@ericsson.com>
Date: Tue, 10 Jun 2014 10:57:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6373E522-4086-4AFB-8E0F-7256145720C9@ogud.com>
References: <5391238C.9090706@gmail.com> <57E7A2FA-A306-42B1-96EB-6112F38E5F36@ericsson.com>
To: Jari Arkko <jari.arkko@ericsson.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/9_rv1mEQt5SRGv98uGbW1vjwSxI
Cc: draft-ietf-dnsop-delegation-trust-maintainance.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART telechat review of draft-ietf-dnsop-delegation-trust-maintainance-13.txt (updated)
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jun 2014 14:57:37 -0000
Jari, we will push one out today Olafur On Jun 10, 2014, at 8:30 AM, Jari Arkko <jari.arkko@ericsson.com> wrote: > Thanks for the review, Brian, and thank you Warren and Olafur for answers. I do agree with the remaining issues as listed by Brian below; can I expect a new draft revision to address these? > > Jari > > On 06 Jun 2014, at 05:12, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-dnsop-delegation-trust-maintainance-13.txt >> Reviewer: Brian Carpenter >> Review Date: 2014-06-06 >> IETF LC End Date: 2014-05-26 >> IESG Telechat date: 2014-06-12 >> >> Summary: Almost ready >> -------- >> >> Comment: >> -------- >> >> These are my Last Call comments on version -13. The authors responded >> with helpful explanations, and I understand that they plan some >> corresponding changes before publication. >> >> Minor issues: >> ------------- >> >>> 1. Introduction >> ... >>> Any manual process is susceptible to mistakes and / or errors. >> >> Also susceptible to social engineering or malicious leaks, I think. >> There's a fairly strong security argument for getting humans out >> of the process. >> >>> 3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions >> ... >>> it is up to the consumer of the records to >>> translate that into the appropriate add/delete operations in the >>> provisioning systems >> >> Not clear here whether this is expected to be an automated or manual process. >> >>> If no CDS / CDNSKEY RRset is present in child, >>> this means that no change is needed. >> >> Not clear here how we ensure that update is performed exactly once. See below. >> >>> 4. Automating DS Maintenance With CDS / CDNSKEY records >>> >>> CDS / CDNSKEY resource records are intended to be "consumed" by >>> delegation trust maintainers. The use of CDS / CDNSKEY is optional. >> >> I think that could be OPTIONAL. >> >>> The child SHOULD publish both CDS and CDNSKEY resource records. >> >> Given the previous sentence, I think this needs to be >> >> If the child publishes either the CDS or the CDNSKEY resource record, it >> SHOULD publish both. >> >>> 4.1. CDS / CDNSKEY Processing Rules >> ... >>> If there are no CDS / CDNSKEY RRset in the child, this signals that >>> no change should be made to the current DS set. This means that, >>> once the child and parent are in sync, the Child DNS Operator MAY >>> remove all CDS and CDNSKEY resource records from the zone. >> >> Does that mean the the child MAY/SHOULD/MUST monitor what the >> parent is publishing in order to automate this process? If not, you >> are calling for a manual operation. (The text in section 5 >> is repetitious, by the way, but still doesn't clarify this.) >> >>> If any these conditions fail the CDS / CDNSKEY resource record MUST >>> be ignored. >> >> Silently? Should this be logged? Any DOS potential here? Should use of >> these RRs be rate-limited in both child and parent to avoid any DOS risk? >> >>> 6. Parent Side CDS / CDNSKEY Consumption >> >> I don't think you specify what the parent should do if it receives >> both a CDS and a CDNSKEY and they are inconsistent (in violation >> of section 4). Yes, it's a corner case but Murphy's law always applies. >> >>> 9. Security Considerations >> ... >>> While it may be tempting, this SHOULD NOT be used for initial >>> enrollment of keys since there is no way to ensure that the initial >>> key is the correct one. If is used, strict rules for inclusion of >>> keys such as hold down times, challenge data inclusion or similar, >>> ought to be used, along with some kind of challenge mechanism. >> >> Shouldn't that "ought to" be MUST? Weak protection against a bogus >> initial key really seems like a "Crypto Won't Save You Either" poster >> child. >> >> Nits: >> ----- >> >> (from the shepherd's write-up) >> "The document references the document draft-ietf-dnsop-dnssec-key-timing, which had >> been approved for publication but never followed through on, and is shown to be expired." >> >> This is an informational reference and could probably be deleted without harm. >> >> "Additionally, the document references RFC2119 key word "NOT RECOMMENDED" without referencing it. " >> >> That is a well known bug in RFC 2119 itself. The citation can be fixed as per >> http://www.rfc-editor.org/errata_search.php?eid=499 >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >
- [Gen-art] Gen-ART telechat review of draft-ietf-d… Brian E Carpenter
- Re: [Gen-art] Gen-ART telechat review of draft-ie… Jari Arkko
- Re: [Gen-art] Gen-ART telechat review of draft-ie… Olafur Gudmundsson
- Re: [Gen-art] Gen-ART telechat review of draft-ie… Jari Arkko
- Re: [Gen-art] Gen-ART telechat review of draft-ie… Olafur Gudmundsson
- Re: [Gen-art] Gen-ART telechat review of draft-ie… Brian E Carpenter
- Re: [Gen-art] Gen-ART telechat review of draft-ie… Olafur Gudmundsson