Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

"John R Levine" <johnl@taugh.com> Sun, 05 January 2020 23:29 UTC

Return-Path: <johnl@taugh.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 C1FD2120045 for <dnsop@ietfa.amsl.com>; Sun, 5 Jan 2020 15:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=quCK/IF3; dkim=pass (1536-bit key) header.d=taugh.com header.b=BEZGwZlv
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 kvG9EfmvaYGH for <dnsop@ietfa.amsl.com>; Sun, 5 Jan 2020 15:29:12 -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 26896120026 for <dnsop@ietf.org>; Sun, 5 Jan 2020 15:29:11 -0800 (PST)
Received: (qmail 37222 invoked from network); 5 Jan 2020 23:29:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9164.5e127146.k2001; i=johnl-iecc.com@submit.iecc.com; bh=tgm1oF0IpU/vKGyaPOvu+jeQ04VjD2zc+ZjIf6YMClU=; b=quCK/IF3OXe5xtb5gCH041s/Y26kX/ksfazaQTC+cd6WhQMqupW89Hr6vfoBnDyZjD10iwiB+k5AFKOJsTsmUnb0SS6K6mXDJA3fImUIQArVjLLNr8dTqlIkL7kDjKLnb9T1g9FQ1wnuq2Rg0vRyrirFvGeqUCda4lxj0mzQwvtTpimPEC6j2gE0Mf/f2dQLYBeyLo2JL5QsEU16RyPnaB0+yGPo/Tood0rE876+j/c36Q+Keih+joNJlWoXLkao
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9164.5e127146.k2001; olt=johnl-iecc.com@submit.iecc.com; bh=tgm1oF0IpU/vKGyaPOvu+jeQ04VjD2zc+ZjIf6YMClU=; b=BEZGwZlvwWV24JkW6A89hSCowK9z//gLfwOkSIlL6/AZw6hiCqZFx6mtYy4MyMuhngb1H2TifInpyP3Zxtxcd9XFElhlG48x2u6GPaXAH/dDmI7/smWp6QvjiAt1UD6xCiI3/OiehD21Zgc8kDVoDD5ru83JzBZE2h0GWfs3oV32AzOKdVpCwcBqNP/Tx8Rw0iEzda0lnXBzXi/+yWKj387suYL+JsXtyskNJ5FZz9tUqWGDxwsCLVZzh5n7IKIo
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 05 Jan 2020 23:29:10 -0000
Date: Sun, 05 Jan 2020 18:29:09 -0500
Message-ID: <alpine.OSX.2.21.99999.374.2001051821210.71425@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: dnsop@ietf.org
In-Reply-To: <9952199f-9ea5-2d51-a5d2-6aaf805774a5@nthpermutation.com>
References: <20200105190035.753B411FCFEF@ary.qy> <9952199f-9ea5-2d51-a5d2-6aaf805774a5@nthpermutation.com>
User-Agent: Alpine 2.21.99999 (OSX 374 2019-10-27)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-581357297-1578266950=:71425"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h7QNo2hcn2slmVqaT-oyizpwB1U>
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 23:29:15 -0000

We seem to have a fairly basic disagreement here about whether we can 
expect people who implement ZONEMD to be familiar with the way that DNS 
servers work.  In pretty much all of the cases below, it seems to me that 
if the answer to the question isn't obvious, you're not the audience for 
this document.

On Sun, 5 Jan 2020, Michael StJohns wrote:

> On 1/5/2020 2:00 PM, John Levine wrote:
>> 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.
>
> To quote one of my favorite movies:  " I don't think that means what you 
> think it means"
>
> The abstract text which is usually not considered normative says:
>
>>     As specified at this time, ZONEMD is not designed for use in large,
>>     dynamic zones due to the time and resources required for digest
>>     calculation.  The ZONEMD record described in this document includes a
>>     field intended to enable future work to support large, dynamic zones.
>
> Define: "Large" and define "Dynamic"  and define "large AND dynamic".   A 
> large fairly static zone (e.g. 100K records with changes once a month) might 
> be a candidate.  A small dynamic zone (e.g 20 records changing hourly) might 
> also be a candidate.
>
>> 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.
>
> Tim represented that "the authors feel they've performed their experiments" 
> and I would assume that the experiments have given them some ideas on which 
> zone size and churn don't cause problems.  E.g. how long does it take to 
> canonicalize and hash various sizes of zones given a particular (or several 
> different) hardware implementation(s)?
>> 
>>> 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.
>
> Let's take one example:
>
>>   As the
>>     root zone spreads beyond its traditional deployment boundaries, the
>>     need for verification of the completeness of the zone contents
>>     becomes increasingly important.
>
> I read this (and the motivation section), and I still don't know why this is 
> a problem.   Nor what the receiver of the zone should do if it detects 
> "missing" data for some definition of missing.
>
> (Note that the "parent tells you whether the child has a zonemd record" thing 
> won't work here, so it's going to have to be some sort of configuration 
> option for the receiver to tell it what to do - e.g. pull it again, yell at 
> the root signers???).
>
> 1.3.4 comes the closest to specifying a real use.  The rest - not so much. 
> 1.3.3 basically seems to be saying - RPZ didn't do it right and rather than 
> fixing it by checking DNSSEC, do this instead.
>
>
>>
>>>>      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.
>
> What does a client do if it sees a non-apex ZONEMD RR because someone will 
> put it there?  E.g. it "ignores it as a verifiable item".  The rest of the 
> processing rules apply.

MUST NOT means it doesn't matter.  A zone with a non-apex ZONEMD does not 
implement this spec, so it's not useful to try and guess what the person 
who created the zone got wrong.  It's more or less the same as what do you 
do with a record that has a compressed name that points past the end pf 
the message -- it's just wrong.

>> 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.
>
> Yup.  Or the zone issuer failed to update the serial number... know any zones 
> (or more to the point zone operators) like this?

See above -- it's broken.  I don't think at this late stage that it is a 
good idea try and guess how people will screw things up and to propose 
kludges to guess what they meant.

> If a computer can't figure out what to do with a failed validation absent 
> human interaction then you might as well say:
>
> "ZONEMD RRs may be safely ignored by all but the geekiest of DNS human 
> operators as there is no guidance on what to do if you see a zone that 
> appears to be incomplete due to ZONEMD RR validation as it might not actually 
> be incomplete"

It's exactly the same thing you'd say about any other zone that has 
techincal errors.  I don't see anything new here.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly