Re: [Gen-art] Gen-ART telechat review of draft-ietf-dnsop-delegation-trust-maintainance-13.txt (updated)
Jari Arkko <jari.arkko@ericsson.com> Tue, 10 June 2014 12:30 UTC
Return-Path: <jari.arkko@ericsson.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 9A9281A007E for <gen-art@ietfa.amsl.com>; Tue, 10 Jun 2014 05:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CyeiA417wYtN for <gen-art@ietfa.amsl.com>; Tue, 10 Jun 2014 05:30:27 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A481A0032 for <gen-art@ietf.org>; Tue, 10 Jun 2014 05:30:26 -0700 (PDT)
X-AuditID: c1b4fb2d-f79776d000001085-c8-5396fa60a69e
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 03.93.04229.06AF6935; Tue, 10 Jun 2014 14:30:25 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.174.1; Tue, 10 Jun 2014 14:30:24 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6948F110206; Tue, 10 Jun 2014 15:30:24 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6093E578F0; Tue, 10 Jun 2014 15:30:31 +0300 (EEST)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E2EB9578EF; Tue, 10 Jun 2014 15:30:30 +0300 (EEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7D12A9D7-EBA9-4EEC-9A73-24799C56FD29"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Jari Arkko <jari.arkko@ericsson.com>
In-Reply-To: <5391238C.9090706@gmail.com>
Date: Tue, 10 Jun 2014 15:30:25 +0300
Message-ID: <57E7A2FA-A306-42B1-96EB-6112F38E5F36@ericsson.com>
References: <5391238C.9090706@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rjfx17Rgg65rrBZtF/cxWTzZ+prN 4uqrzywOzB47Z91l91iy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mj7+n81a8Dak4tOqXqYG xjafLkZODgkBE4mvHQtYIGwxiQv31rN1MXJxCAkcZZQ4e2UOWEJIYAOjxMU9AhCJvYwSj+fe Y4JIrGOUWHAqEMKexyjxpFsapIhZYAqjROvi9WBFvAIGEusWH2MEsYUFCiXe3O4Ds9kEtCQ2 Ll/ABmJzCmhKXG/dAGazCKhKzP05lR3EZhYok5gyezHUHHuJP2cfsEIs05BYfnQFM4gtImAs 0dh1mhXiBXmJGe0n2CFsNYmr5zYxQ9SrSNz6e5ZtAqPILGT3zUJy3yywfdoSyxa+Zp7FyAFk 60hMXggVNpV4ffQjlG0tMePXQTYIW1FiSvdD9gWM7KsYRYtTi4tz042M9VKLMpOLi/Pz9PJS SzYxAuPt4JbfujsYV792PMQowMGoxMOr8G1qsBBrYllxZe4hRmkOFiVx3ksa1cFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGJ0PaL0t/3nefz4jv5WGDbtCVtXFMyyM0ZLBO1WksjJvda6q c7zy8rvO4SrVp5OOvZu27tyX5+KiuXnzNpRP6n0m27fy4h1Bjg/yYTO3XKm22MKUW3X/wh4X lcLll47tfCfhtej1kYXbVv8yn+bke6muZtHyzBVpR/13WurG/NknfM6jMa3ELVuJpTgj0VCL uag4EQD4ngCNmAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/F08qDlQ0-kZ_QMI2vdJLYs64eYY
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 12:30:30 -0000
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