Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt

Olli Vanhoja <> Mon, 25 March 2019 14:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56D741204A4 for <>; Mon, 25 Mar 2019 07:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.236
X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1-5z2zFfvDZG for <>; Mon, 25 Mar 2019 07:47:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3877812041D for <>; Mon, 25 Mar 2019 07:47:32 -0700 (PDT)
Received: by with SMTP id t13so8065647lji.2 for <>; Mon, 25 Mar 2019 07:47:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i8dni0ip61Se34OYxg4EkEl3Am/eF3ZHYplcXPy5MuU=; b=nbAW5MX28n9TItQuD1cS9iK5MaFUgedTXj40lO5CxBuIpz+OlU8A93Fy/JmevYMhOM HzKvvf6R5hKUDzHTg1+1SVIy0PzcQJ0pgpLCPNCEN5az9/pDvubl5UhDK7QFT7zkbEoZ weG8RR46Mdc9OoOWbFhTuhXGCw6pG6vWBirgf+TCqVGW3tYfbzTPdFPuVTe1s9BE4VqR M0yf+N3ot2ts4INCwZdIGSAYBcVtxoBOtREKjMUUXbqoYHF6RmiS33K8p5m96GS+nLTS nvRib75QwvXoq11VW3unDMfoW/EbL9rIC2NemZ2TVEYBvlyUUC+G9naN8mvkx/YHuNEC dqsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i8dni0ip61Se34OYxg4EkEl3Am/eF3ZHYplcXPy5MuU=; b=M7mGJghOMiK/+netjOHGdFjm/GBhOHsX6Odp6aU0yj5h6mySOF+sGfit7Va0bjKOW1 v8vK2OSXXc/hY0Um1S1fOyYLqqcPW3Fy+eNK+gP6wl+2UoR3gFNBXtl+NP7MaGib22iD JXgkIzCaN0Xv5SPfxxJ+br6qQTLlWjFLM2x1S18jnH5LjYECp9SEiLq9MrOi2wuz5nHk 8PYc3aQpB1wJhSrNKPQZ/ZEC5EQ6tzYAp172cSvVhrDJL6SS/Q7cZcXMGbdC0RT1Mb7S DtZFvR4QPlVCC320flIwbDBP35tkYwuGOt57jaPsuf5QGHX0wNaK5djPMadi1saGBSkN j2ZQ==
X-Gm-Message-State: APjAAAUXNiDAYMsThYnOEglzUv0kAQ+M7djmRSWLDH5Ff3dc1IGcT5Qt hXZJgXxDldhejkuTa5eVLHvvnChBiSo3YrGuxQhogtunBHu9vA==
X-Google-Smtp-Source: APXvYqyM2LIuQym7Dm5irzMecV0MKdFCUR45C1uMZNlbPlcG6sXFR6urw81euKSJThB4ZvdJsXrU8wPXvFXuAWNzPWo=
X-Received: by 2002:a2e:81da:: with SMTP id s26mr1667014ljg.86.1553525250298; Mon, 25 Mar 2019 07:47:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Olli Vanhoja <>
Date: Mon, 25 Mar 2019 15:47:19 +0100
Message-ID: <>
To: Matthew Pounsett <>
Cc: "Wessels, Duane" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Mar 2019 14:47:39 -0000

On Mon, Mar 25, 2019 at 2:54 PM Matthew Pounsett <> wrote:

> Section 3.2. discussion:  Unless there's a potential benefit to non-apex ZONEMD records that I'm not seeing, I think it makes sense to forbid them.  Was there a particular thing that could be enabled by that, which prompted the suggestion?

I agree with this. I believe it would create unnecessary complexity.
For example, which records would such a digest cover? Would the apex
record cover also the records covered by this subdigest?

> In 3.4.1 would it make sense to include a sentence explaining the catch-22 that would result if the RRSIG covering the ZONEMD record were included in the digest?
> In section 4, I suggest replacing all of the instances of "provably [un]signed" with "provably [in]secure".   To me, a zone is provably signed if it has DNSKEYs and RRSIGs that validate from those DNSKEYs.  What the draft is interested in is whether those signatures link up to a trust anchor somewhere, and the term for that is "secure"..  But maybe there are definitions somewhere that I haven't read that make "signed" and "secure" equivalent, which would make this a silly suggestion.

Does it matter for this feature that the trust chain verifies? If so,
does it mean that it's provably secure? Maybe the private key was
leaked but not yet revoked, thus it's provably properly signed and
verifies, but it's not provably secure. Perhaps we could add some
wording to define what we mean by that (either).

> Section 2 discussion:  I was initially ambivalent about whether multiple ZONEMD records should be allowed with different digest types.  Having gone back and re-read some of the discussion, I'm persuaded that it would be beneficial to allow multiple digest types to be used on the same zone instance.  I think we'd want to have a bunch of discussion about the details in order to keep code complexity under control, though.

> Section 5 discussion: I can't remember if I commented on this bit before or not, but just in case.. I support keeping the reserved field.  It seems to me that if we have to get a new type for an incremental-friendly version of ZONEMD that we're going to have implementation fragmentation and a migration issue.  Especially if we don't allow multiple ZONEMD records, I can imagine it being difficult to have both in the zone at once, and that it could be hard to specify what should happen if an operator wants to migrate from ZONEMD v1 to ZONEMD v2 without knowing which one the consumers of their zone support

It think it would make sense to allow multiple ZONEMD records at the
*apex* level. That would allow one to support multiple different hash
functions as well as to migrate to a new hash function without
breaking the existing clients. I'm not sure if there would be any
benefit of supporting multiple functions initially. Would someone
possibly say they need function x to be supported for perf reasons? Or
perhaps just that some other function x is natively available in some
system but the SHA384 isn't.

Like I said before, I'm already operating a system that is internally
doing something very close to this. The major difference is just that
I'm using a different hash function but that's only because this draft
didn't exist when I made that decision and I think SHA384 would be
better fit. I think, I will try to compare the differences soon(ish)
and hopefully make my implementation compatible with this draft.