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