Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones
Michael StJohns <msj@nthpermutation.com> Sun, 05 January 2020 01:14 UTC
Return-Path: <msj@nthpermutation.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 1755A12008D for <dnsop@ietfa.amsl.com>; Sat, 4 Jan 2020 17:14:25 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 9ruKxLlI-tpC for <dnsop@ietfa.amsl.com>; Sat, 4 Jan 2020 17:14:21 -0800 (PST)
Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBC512008F for <dnsop@ietf.org>; Sat, 4 Jan 2020 17:14:21 -0800 (PST)
Received: by mail-qv1-xf43.google.com with SMTP id o18so17739647qvf.1 for <dnsop@ietf.org>; Sat, 04 Jan 2020 17:14:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=tiTyTZbPwatAdpTWtY3G0IiOJ5yt9xgS+j67ysvbx58=; b=q2G/ftEP9oOxv18CoijoX+WB9VIeDEmeXurdg1hctXFwXVIQLLzoKARYUFfoucU4qC fpymkmZSFFzyUO1TJpqbYUZoiz8g3V7q1PUlWgsJbcv6W5lDkS12e7PLdKkWaXPpGcfj b0GgftUofX6yOiuJge1EhxJG78jhc5rW02EwWIcfEUP6LjQW0IhJ+eMCkC4zdAAwe731 IL8Dnnb6TdyvIb3bFSHG6OvCVk0IppgP/2bnVCR828Teu2dZZ88nArz3bVmOF2KWZsf1 /rway6gAz6aC12IgUgTEAX3eJFC5ncH0LHtO7PYtK7xmDvRMoXsCmftqC0itLjhXuAve ITow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=tiTyTZbPwatAdpTWtY3G0IiOJ5yt9xgS+j67ysvbx58=; b=eQq3TvskOIBIDErl+qMIivlRKz2vY+Fmh3SRDVWbB9EfeXaL88sZ3JU+A2zzxQGavH ww33gQMDQaY0ckeB1CEpxO4/EHudaRYpZD4X9Hhk+DCuxknovl10M3SJzrywWbPqZj0r J4C7fkSrtGNBukkZrZpscZB/YVqRXxR4Yd1/gCPMxuCMgyaxZ/d5uza+T2kwnjKOvGsu 0rgJh715gx+0gO7B/m9E3VJasMWNbGBkV3q93vInohygJB5qggucEtS/87BqC/x1WfNb hQiaF83g/g36131Jb4OJG27H6N49XjRdV5CD56TUmta4kNt1HViEInNbV8I3y3YFKonE P/Gw==
X-Gm-Message-State: APjAAAUpuH4eiMc86R3lPCcUrdHWzp/mWHDuO+y+gGa5aO+qB6C5ppQ7 cDSvtJQ/Uw9sJusU+R8CZGDwJGyMHms=
X-Google-Smtp-Source: APXvYqzDKQp7c2HUCn8ZTc2ohYjbouODb6VRAurKwBBw95gd+O5uFcahvA3wbCpSwDbbBjtIx6lJVw==
X-Received: by 2002:ad4:4949:: with SMTP id o9mr72182324qvy.189.1578186860045; Sat, 04 Jan 2020 17:14:20 -0800 (PST)
Received: from ?IPv6:2601:152:4400:437c:9c30:d77e:59a5:ff6b? ([2601:152:4400:437c:9c30:d77e:59a5:ff6b]) by smtp.gmail.com with ESMTPSA id z4sm18539844qkz.62.2020.01.04.17.14.19 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jan 2020 17:14:19 -0800 (PST)
To: dnsop@ietf.org
References: <CADyWQ+G1w9_vcU3oO9MsKcP4hTLPXKFb+xY7LJGExbAfjzsDMw@mail.gmail.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <84650844-1d13-9377-c913-23dcbc76dc37@nthpermutation.com>
Date: Sat, 04 Jan 2020 20:14:17 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CADyWQ+G1w9_vcU3oO9MsKcP4hTLPXKFb+xY7LJGExbAfjzsDMw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------D79C355EC3D9671CA2A601F7"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MOej1S6rBnlG1YjRo_yawWbQXl8>
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 01:14:25 -0000
Hi Tim et al - I read through this back a few versions ago and mostly thought it harmless as an experimental RFC. I'm not sure that it's quite ready for prime time as a Standards track RFC. Here's what I think is missing: 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. 2) For each of the use cases, an explanation of how this RRSet actually mitigates or solves the identified problem. E.g. at least a paragraph each for each the subsections of 1.3. That paragraph should lay out why the receiver of the zone should actually want to do this verification and the cost/benefit of that for the end user. 3) Section 2 uses SHOULD or MUST related to data content rather than protocol. That's a problem in that humans are notorious for making mistakes and screwing up the records. > This section describes the ZONEMD Resource Record, including its > fields, wire format, and presentation format. The Type value for the > ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of > the resource record consists of four fields: Serial, Digest Type, > Parameter, and Digest. > > 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". > > 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". and "If there are multiple ZONEMD RRs with distinct DT and Parameters, the zone is acceptable if the client can verify at least one of those RRs" > 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. 4) 2.1.3 - The parameter field MUST be set to 0 for SHA384-SIMPLE on creation, and the client MUST NOT accept the RR if this field is not set to zero for SHA384-SIMPLE. 5) 3.1.2 - This is I believe different than how DNSSEC does it? If it's the same, then this is fine, otherwise this protocol should be calculating the RRSet wire representation the same as DNSSEC does it. 6) 3.2 - another set of data set MUSTs (the recommended isn't an issue, but should probably be lower case) that need guidance for the accepting client if the MUST doesn't hold because of human error. 7) 3.3 - Probably lower case may for DNSSEC. The rest of this is operational guidance that really doesn't give anything useful for the protocol. 8) 3.4.1, there is no reason whatsoever to make the setting of the parameter field a SHOULD here. MUST is correct. 9) 3.4.2 - Third bullet. See above and also, as currently written here this implies you ignore ALL RRs at that owner/class/type/RDATA if there are duplicates. Rephrase at least. 10) 3.5 - This section needs a bit of re-working. Generally, what you want to say is that if you have ZONEMD RRs, that they have to be published at the same time as the matching SOA. You also want to probably make a note somewhere that if the SOA and ZONEMD RR do not match on receipt you do ... something? Not sure what. 11) I really need to write an RFC on "SHOULD considered harmful (if not qualified)". For section 4, bullet 1 - explain what you mean by SHOULD - e.g. is this a configuration option, or a implementation option. If a configuration option, in which case might a recipient not want to do this? If an implementation option, why isn't this a MUST? Also, if you don't do the DNSSEC thing, identify the next step to be executed (i.e. 4). 11.1) Sorry for the numbering - missed step 4 in section 4 - see point 3 and reconcile or remove 3rd and subsequent paras from section 2 to make this section the only normative one. 12) 4.1 vs my point 3 above - reconcile, or remove 3rd and subsequent paras from section 2 to make this section the only normative one. 13) Missing a section 4.2 which says what you do when a zone doesn't verify. Otherwise, what's the point? 14) Section 6.1, third paragraph is incorrect. Note that Section 4 step 2 is part of the stuff that's skipped if the zone is provably insecure or if you decide that SHOULD means "I'm lazy and I don't want to do it". E.g. Section 4 does not "REQUIRE" this because of the preceding and enclosing "RECOMMENDED". 15) Add a section 6.3 to security considerations which describe the downsides of this RR - e.g. for example that it can make a zone more fragile by requiring complete coherence in the zone and that this is a substantial change both to DNSSEC and the original design of DNS. Or when applied to a large dynamic zone may never be able to calculate a valid digest in time, nor have a recipient accept it. I think Experimental is fine. I'm not sure without a clear text addressing my points 1,2, 13 and 15 that this is useful as a standards track document for general use. Later, Mike On 1/4/2020 5:30 PM, Tim Wicinski wrote: > All, > > The chairs would like to welcome the new year with some work. > The authors and chairs feel this document is ready to move forward. > > One thing to note: This document has the status "Experimental", but > the authors feel they've performed their experiments and their current > status is "Standards Track". > > This starts a Working Group Last Call for "Message Digest for DNS Zones" > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ > > The Current Intended Status of this document is: *Standards Track* > Please speak out if the intended status seems incorrect. > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, > please speak out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: > 18 January 2020 > > thanks > tim > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
- 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