Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 12 October 2020 22:23 UTC
Return-Path: <kaduk@mit.edu>
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 9D49C3A0BDC; Mon, 12 Oct 2020 15:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EMK24xOWHLmB; Mon, 12 Oct 2020 15:23:08 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03343A0BC6; Mon, 12 Oct 2020 15:23:07 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09CMMxoC026122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Oct 2020 18:23:04 -0400
Date: Mon, 12 Oct 2020 15:22:59 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Wessels, Duane" <dwessels@verisign.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-dnsop-dns-zone-digest@ietf.org" <draft-ietf-dnsop-dns-zone-digest@ietf.org>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>
Message-ID: <20201012222259.GG1212@kduck.mit.edu>
References: <160247539257.14934.7821393078907455062@ietfa.amsl.com> <1B53DFDF-4A87-46F2-AEC7-20D966DC32E4@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1B53DFDF-4A87-46F2-AEC7-20D966DC32E4@verisign.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MC0EJZcZySxQgFDu42PoQjO23Jc>
Subject: Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2020 22:23:10 -0000
Hi Duane, Thanks -- this all sounds good (and it sounds like Rob is okay with the new thought for text about reporting, as well). Thanks again! -Ben On Mon, Oct 12, 2020 at 03:54:02PM +0000, Wessels, Duane wrote: > > > > On Oct 11, 2020, at 9:03 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dnsop-dns-zone-digest-13: Yes > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for addressing my discuss (and comment!) points. There are still > > a few more threads to tidy up, but I'm happy with the direction we're > > going. > > > > Section 1 > > > > We (implicitly) mention "integrity" here as provided in the absence of > > DNSSEC, but later in Section 1.1 we say that integrity can only be assured > > when the zone is signed. I leave it to Roman to say when his discuss is > > resolved, but it seems likely that we should be consistent about which way > > we go with it. > > Looks like I missed that spot in when addressing Roman's point. Now changed > to this: > > It allows a receiver of the > zone to verify the zone's integrity and authenticity when used in > combination with DNSSEC. > > > > > Section 1.1 > > > > It's perhaps unusual to follow "the motivation for this protocol" with "a > > secondary motivation"; instead writing "the primary motivation" would reduce > > the surprise at seeing a secondary motivation added later. > > Agreed. This has been changed. > > > > > > Section 2.2.2 > > > > This change seems to be a regression? The value 1 in question is the > > scheme value, not a Hash Algorithm value. (I would make this a > > Discuss point but I am sure we will get it resolved quickly.) > > Oops, I changed that in the wrong place. Now it says "with Scheme value 1" there > and "with Hash Algorithm value 1" in the next section. > > > > > > Section 3 > > > > (nit) Right now the literal reading of "identical" is that the ZONEMD and > > the signature and the denial-of-existence records are identical, which > > is of course nonsensical. Perhaps adding "to the ones produced by this > > procedure" or similar would reduce the stress for people who habitually > > make sentence diagrams. > > Changed to this: > > Implementations that deviate from the > described algorithm are advised to ensure that it produces ZONEMD > RRs, signatures, and dential-of-existence records that are identical > to the ones generated by this procedure. > > > > > Section 4 > > > > I can't tell if there's a duplicate line in the XML source or not, here > > (as an editing leftover), but that's my guess as to what happened. In > > particular, I'm not sure how one would query for a DS RR *in the anchor*. > > If I'm reading the previous thread correctly we were only proposing to talk > > about querying for (and validating) DS RRs in the parent zone, not the > > anchor (whatever that means). > > Yes indeed there was a line duplicated during editing. Now: > > This is done by examining locally > configured trust anchors, and, if necessary, querying for (and > validating) DS RRs in the parent zone. > > > > > Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD > > report" above and just say this:]"? (I'd be fine with it, for what little > > it's worth, but I don't think my opinion is anywhere close to the most > > relevant one.) > > Both you and Rob asked about this -- the possibility of overly verbose reporting. > I'd like to hear Rob's opinion. > > DW > >
- [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-… Benjamin Kaduk via Datatracker
- Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dn… Wessels, Duane
- Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dn… Benjamin Kaduk