Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones
"John Levine" <johnl@taugh.com> Sun, 05 January 2020 19:00 UTC
Return-Path: <johnl@iecc.com>
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 CCB441200C3 for <dnsop@ietfa.amsl.com>; Sun, 5 Jan 2020 11:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Q5sCIyF1; dkim=pass (1536-bit key) header.d=taugh.com header.b=W8JJ+Q7P
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 llM3AGdAvLqM for <dnsop@ietfa.amsl.com>; Sun, 5 Jan 2020 11:00:37 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 47AF91200B1 for <dnsop@ietf.org>; Sun, 5 Jan 2020 11:00:37 -0800 (PST)
Received: (qmail 87930 invoked from network); 5 Jan 2020 19:00:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=15778.5e123254.k2001; i=printer-iecc.com@submit.iecc.com; bh=HRZA9Yrdi1sXUXimwR0MEAOtDQJ5V6o0Aqr3D3VPXy0=; b=Q5sCIyF1bPAc1WWYtvesEqTOpcvG86Sb4KZdcbTNP1qAxm8Ld+RiPfu0oAC4gQljegB5IwxGByYdQ7kM80UabADIApp1V+tD6nr9T6E9uIubHiUnbIoG5+EV+G+MGPVy/TlQwnPLpiRsYL3ygGVGmot+THpUMl+SOJRL6utKevJR5ukknjH52PU/IZA31GkW8xrz06ee9lTc7qyeUDQzWfUyQJpvRTfCQS++7ZoPPf5pPX12UHiieIz30yRvlxH6
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=15778.5e123254.k2001; olt=printer-iecc.com@submit.iecc.com; bh=HRZA9Yrdi1sXUXimwR0MEAOtDQJ5V6o0Aqr3D3VPXy0=; b=W8JJ+Q7PGFOqLS1s2kBLTct86xUBZ6VknuVpYUCWS8UoHnJOgBiUFBQg3C1aAo4LjHsjV5rtTr56wNDkBu/c0az8DGNLA07EW/J9HcOkfycEF649JfHtx5cUcZNfDw00PyRrCIrRj6Vtn2lxPsWBq0yWmU4OTHUkR32tUiKQ23iaVarSvSkV2tui8HuABtfgN3yErfQb6jlNqM2v56D0TczuERrPqjrRspYhH1TOplwqeV6ivoqcWZjdfeaJm6CC
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 05 Jan 2020 19:00:35 -0000
Received: by ary.qy (Postfix, from userid 501) id 753B411FCFEF; Sun, 5 Jan 2020 14:00:35 -0500 (EST)
Date: Sun, 05 Jan 2020 14:00:35 -0500
Message-Id: <20200105190035.753B411FCFEF@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Cc: msj@nthpermutation.com
In-Reply-To: <84650844-1d13-9377-c913-23dcbc76dc37@nthpermutation.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rmtgKjxKr9X4HMgC4yRi_YRE9Hk>
Subject: Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones
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: Sun, 05 Jan 2020 19:00:39 -0000
In article <84650844-1d13-9377-c913-23dcbc76dc37@nthpermutation.com> you write: >1) A recommendation for the maximum size of the zone (and for that >matter the maximum churn rate). This is hinted at in the abstract, but >missing from the body of the document. I don't get it. The draft makes it clear that ZONEMD in this implementation is intended for statically signed zones. If Verisign wants to put a ZONEMD in the daily download of the three hundred million record .com zone file, I think that would be dandy. If your zone of whatever size is updated too often to deal with recomputing ZONEMD, then don't. Also, advice about what's too big or too slow doesn't age well. I expect most of use remember a time when the idea of a million record zone file seemed absurd. >2) For each of the use cases, an explanation of how this RRSet actually >mitigates or solves the identified problem. I don't get this either. ZONEMD lets you verify that you got the entire zone correctly. If anything, I'd take most of this section out since the list of places where people get zone files isn't likely to age well either. >> This specification utilizes ZONEMD RRs located at the zone apex. >> Non-apex ZONEMD RRs are not forbidden, but have no meaning in this >> specification. >Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client". Does ignore mean they aren't included in the computation of an apex ZONEMD? Ugh. ZONEMD RRs MUST NOT appear anywhere other than the apex of a zone. >> A zone MAY contain multiple ZONEMD RRs to support algorithm agility >> [RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest >> Type and Parameter tuple. >"A client that receives multiple ZONEMD RRs with the same DT and >Parameter MUST try to verify each in turn and MUST accept the zone if >any verify". I think that's an error. If they have the same DT and parameter, either they have the same serial and they're duplicates, or one of them is obsolete. >> It is RECOMMENDED that a zone include only >> one ZONEMD RR, unless the zone publisher is in the process of >> transitioning to a new Digest Type. > >Lower case "recommended" here please. I'd take it out altogether. What problem does multiple signatures cause? Agree with most of the other editorial advice. >13) Missing a section 4.2 which says what you do when a zone doesn't >verify. Otherwise, what's the point? That seems extremely dependent on the context. What I would do on a secondary name server AXFR'ing a zone for which it's authoritative vs. one of the thousand daily CZDS zip file downloads is rather different. With respect to updated zones, perhaps it should say that if zone updates are distributed with IXFR, each update should either have an updated ZONEMD with the new checksum for the full zone or delete the now obsolete old ZONEMD. That seems obvious, but you never know. R's, John
- Re: [DNSOP] Working Group Last Call for: Message … Vladimír Čunát
- Re: [DNSOP] Working Group Last Call for: Message … Tim Wicinski
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- [DNSOP] Working Group Last Call for: Message Dige… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Paul Vixie
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Joe Abley
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Paul Hoffman
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Brian Dickson
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Bob Harold
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- [DNSOP] future-proofing (Re: Working Group Last C… Paul Vixie
- Re: [DNSOP] future-proofing (Re: Working Group La… Brian Dickson
- Re: [DNSOP] future-proofing (Re: Working Group La… Wessels, Duane
- Re: [DNSOP] future-proofing (Re: Working Group La… Michael StJohns
- Re: [DNSOP] future-proofing (Re: Working Group La… Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … Miek Gieben
- Re: [DNSOP] Working Group Last Call for: Message … Wes Hardaker
- Re: [DNSOP] Working Group Last Call for: Message … Wes Hardaker
- Re: [DNSOP] future-proofing (Re: Working Group La… Shane Kerr
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Paul Hoffman
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Brian Dickson
- Re: [DNSOP] future-proofing (Re: Working Group La… Wessels, Duane
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Wessels, Duane
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Michael StJohns
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Paul Hoffman
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Paul Vixie
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Michael StJohns
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… John Levine