Re: [DNSOP] Review of draft-wessels-dns-zone-digest-04.txt

Paul Wouters <paul@nohats.ca> Tue, 30 October 2018 02:42 UTC

Return-Path: <paul@nohats.ca>
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 6E8E0123FFD for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 19:42:56 -0700 (PDT)
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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 4fJ80zqqq7JM for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 19:42:54 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3DDD9124C04 for <dnsop@ietf.org>; Mon, 29 Oct 2018 19:42:54 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42kbNp64q0z1kQ; Tue, 30 Oct 2018 03:42:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1540867370; bh=nT6byvsA5liYzsQsP2ZdUZUFUw/aKYsZ334TRldAZ9I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qHkNCBLp/6AMeRMfeZxsX4cLVqfBO5z4Ao+cDf1oSnh1BqrSIgV0sgkNmu5SvG5Sl cX3rKJF/M3smYagT2SGjkYTLDRBYo5VDsKx1LuEcH5dHbW2LhRV0YtKhXPEye9G2On mG1rWP0J+KvFSxE3sTRPgycqikh2hGVLdgnzhkrU=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vMZeLgvsu1Gy; Tue, 30 Oct 2018 03:42:49 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 30 Oct 2018 03:42:49 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6242549ED72; Mon, 29 Oct 2018 22:42:48 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6242549ED72
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 564E241C3B37; Mon, 29 Oct 2018 22:42:48 -0400 (EDT)
Date: Mon, 29 Oct 2018 22:42:48 -0400
From: Paul Wouters <paul@nohats.ca>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
cc: "dnsop@ietf.org" <dnsop@ietf.org>
In-Reply-To: <B0240FFE-D4C7-49DF-8321-A3DF8F0BC794@verisign.com>
Message-ID: <alpine.LRH.2.21.1810292237520.10602@bofh.nohats.ca>
References: <20181029155524.GA13798@jurassic> <B0240FFE-D4C7-49DF-8321-A3DF8F0BC794@verisign.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tecaKHARkujb1ymmgJq5I-AIuU0>
Subject: Re: [DNSOP] Review of draft-wessels-dns-zone-digest-04.txt
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: Tue, 30 Oct 2018 02:42:57 -0000

On Mon, 29 Oct 2018, Wessels, Duane wrote:

> The feedback I have received regarding this point has been mixed.  I have
> some folks saying "make it work with stable zones now, figure out dynamic
> zones later" and others saying "have to support incremental updates now."

> This is why the authors propose proceeding with the Reserved field at this time.
> If it later turns out we can agree on a way to support incremental updates by
> using this 8-bit field, then that would be great.  If not, we can, as you say,
> consume another RR type and the wasted 8-bits stays Reserved indefinitely.

This seems fine, although rather than yet another document, I think it
would be better to handle it right the first time in this document.

> This was a point of discussion in earlier revisions:
>
>   FOR DISCUSSION: the serial number is included in order to make DNS
>   response messages of type ZONEMD meaningful.  Without the serial
>   number, a stand-alone ZONEMD digest has no association to any
>   particular zone file.  If there is agreement that ZONEMD responses
>   are not useful, this field could be removed.  See also the end of
>   Security Considerations.
>
> Based on feedback from that revision, seems like there was consensus to
> keep the Serial field and allow ZONEMD queries/responses.

Makes sense to me.

> I was thinking it would be useful to have ZONEMD digest types track DS digest
> types, so that it wouldn't require a new RFC to define a new ZONEMD digest type.
> But I'm not sensing much support for this approach.

I think I lean towards not doing this, just so that when a new DS digest
type is introduced, people don't have to update the zonemd code (or
forget to do this, and thus limiting the real zonemd digest that can be
used in practise)

> As an implementor, you would be okay with, say SHA384 having value 4 when used
> in as a DS digest type, but value 1 when used as a ZONEMD digest type?

As a non-DNS implementor, I see no problem with this.

Paul