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

Matthew Pounsett <matt@conundrum.com> Mon, 25 March 2019 13:53 UTC

Return-Path: <matt@conundrum.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 6BB73120381 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 06:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-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 GhvlXVIlKRLO for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 06:53:22 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 BE57E1204B0 for <dnsop@ietf.org>; Mon, 25 Mar 2019 06:53:22 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id c4so7646057ioh.9 for <dnsop@ietf.org>; Mon, 25 Mar 2019 06:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G9Bh5OOdnD/owNYZVcnjQiCDhjzicNAxNvNHgDnLUbg=; b=dWkhy3m6+xjfKhjGWzNIx1bkqdnzz/LdqEdZpIanHQITfqWb0c5dtW51yDKywyq1Jx q2h0NQ6q2boG4TD9dVXDhyQBEVB6wFzwGLOtwUij+O0yIibfTCAxzMTsmliNbNSFHjK2 iMngh31M+YpXpvG6MjYxkr0Xntq83s5xDNwQAnqcZk4zSzbCjCZhuMBWXeSWAjYIdB4N Y2GfNhZIA6vwhfMg3Qrsk6/6XLUKNVZJHbu6TjAR5ZJeTD/PJPS9URV9sfew3Me0wnww F1hOTVEbRlPhgKDH2kdZXVurU19pz5rtp3iVPyUwSm5OXkVfO7mBIptB71shrqhv/nU0 DzHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G9Bh5OOdnD/owNYZVcnjQiCDhjzicNAxNvNHgDnLUbg=; b=lZubwhl7PyY9UxcpRL1o1avn3Hb458XiErQUl/87sfQ0W9kawam2UzqAat8psKEPLl UYhOFlXF7KoaZRiX5oi0R6cyTgvY/EAAVAIHGdn0BPs1pAbIqj0yA1X+P6UQ+t3mnrwS skBjVQoNPFUl4xpMsDkN/dlXiTvSmC0CBaPTf34HHDw9KEtaRfa+8Jo9qSk7ou7vzsql Ig65VCMByWxUhRjtl6aaK2YV8oX+O/j7cQ6hJm7bea8Z3QuwklQi57S62lVDvU8FpQAM 80wIllOGDdHUebyPUxM5TN3m4OSWVHUoIiO0gVauyCO6BNjQUdLi3hwd5qpSoPAqGmZS UCjw==
X-Gm-Message-State: APjAAAXZUIf9EWW+Q8T+0Rg3ni5/prfw7koPTz/0hVxJKNVi5nheVnFr t5h81SId30I/VeP1CeF7HElSioLTXKD/TngKeOtH2A==
X-Google-Smtp-Source: APXvYqzIOZmsM9eFV/PcxhfSSEUv2eOWuEP/2c5winwE4lipp+QChgsFHzq/W9hYLSU7fW8AQNQhAhbS06d7soPWv3U=
X-Received: by 2002:a6b:691a:: with SMTP id e26mr13690277ioc.124.1553522001903; Mon, 25 Mar 2019 06:53:21 -0700 (PDT)
MIME-Version: 1.0
References: <155009468256.9559.12509906855495134896@ietfa.amsl.com> <923006F8-EB5A-4098-81A2-782BC90BF220@verisign.com>
In-Reply-To: <923006F8-EB5A-4098-81A2-782BC90BF220@verisign.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Mon, 25 Mar 2019 14:53:11 +0100
Message-ID: <CAAiTEH_GmvNVgAZzwG+oaQrtNd_b=kpDSRz7ErbmTjuXrzziWg@mail.gmail.com>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000131aeb0584eb87d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p6YmL_pxtAcM98kQseHa0cUd_ds>
Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.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: Mon, 25 Mar 2019 13:53:29 -0000

On Wed, 13 Feb 2019 at 22:56, Wessels, Duane <dwessels=
40verisign.com@dmarc.ietf.org>; wrote:

> The only change to this document since -05 is to note that ZONEMD has been
> allocated RR type code 63 by IANA following an expert review back in
> December.
>

I haven't reviewed this for a couple of revisions, so some notes here that
don't apply to the new codepoint. :) . I've tried doing some searches of
the discussion history to make sure I'm not raising points already
addressed, but my apologies if I've missed something.

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 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?

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.

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