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

"Wessels, Duane" <dwessels@verisign.com> Wed, 31 October 2018 23:03 UTC

Return-Path: <dwessels@verisign.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 9B47C130DD6 for <dnsop@ietfa.amsl.com>; Wed, 31 Oct 2018 16:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 q0dS-t3m_KLJ for <dnsop@ietfa.amsl.com>; Wed, 31 Oct 2018 16:03:56 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 31135130DFA for <dnsop@ietf.org>; Wed, 31 Oct 2018 16:03:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=12960; q=dns/txt; s=VRSN; t=1541027034; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=0+6xGVAaIRvBFEaZigin4gq8QpZxW13zkP//D05g6PU=; b=btkmg5Bb47qVuPTsybhOe5+rCtfi4Ki4XI8fWhBSBQxtUYpRY/waogU3 FmFZ4UlTnQwvlEvVw2R9YcnPy8s551VqjsKxNZznS9pRN7kG5k9XxWP0C brKeayaKkBwLpZM7VV416TikbFbANlKqqWS7QwaS35nbAknAuKTqeVldm 8VrVtZCA4kVO1+vbFNq/GbAnU3h38H5tmLfWXHDxO3Wm5uUxFF275TEFw ICGKLo9K9njWUlBUpPyL+IuZjo8bA0iAppZASxHqL9jNQXu3UuvM/g0t/ ttYH9SVlUoFEQU1EYVCjvs2K1LwerCXQFPaO6WItNpKqZCxUSnd2ZZ2ri w==;
X-IronPort-AV: E=Sophos; i="5.54,449,1534809600"; d="p7s'?scan'208"; a="6755039"
IronPort-PHdr: =?us-ascii?q?9a23=3A7laHzR2PlNhYYmBHsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seMXIvad9pjvdHbS+e9qxAeQG9mDtLQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPYQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWpPUNhMWSxdDI2y?= =?us-ascii?q?bIUPAOgAPelEoIbwvFQOoQe7BQS2GO/j1iFEi3nr1qM6yeQhFgTG0RQuE90Orn?= =?us-ascii?q?vUt871O7kWUeCu1KXD0DvNb+5M1jf79ofEfA0qrPaRUrN+b8XR0lIvGB3BjlWL?= =?us-ascii?q?soHlIS2a1v4Ms2iA7upgWuSvh3Q7pAF2pzii38EhgZTKiIIN0l3I6Dl1zJwoKd?= =?us-ascii?q?C6RkN3e8OoHZteui2AOIZ7QdsuT3x0tCog17ELu4K3cDIXxJkoxBPTceGLfouQ?= =?us-ascii?q?7hLtSumcIit0iXdgdb2lhBu/9VOvx+jyW8WqzVlHry9IncLIu30M1RHe78aKR/?= =?us-ascii?q?V/80i83zuEyhrd5fteIU8ukKrWM5shwrktmZUNqUnDBSr2mFnujK+Ra0Uk5vCk?= =?us-ascii?q?6+T5bbXioZ+RL5J5hB3mPKgzmsOxGes2PQkSU2SG4+i8yqHs/UrjQLVSlPE5iL?= =?us-ascii?q?TWvIrEJcQBva65BRVZ3Zok6xa6Fzum0dIYkmcbLF9dZR6Lk5LlN0zMLf32F/uz?= =?us-ascii?q?nlShnTlxy/3JPbDtGpDNIWLCkLflc7Z98UlcyA8rwN9C6ZNbFKoBIOntVU/1r9?= =?us-ascii?q?zVFQE5PBKuw+bmE9V914weWWSVDqCFN6PStEeE5vgzLOmUeI8VpDH9JuAn5/H0?= =?us-ascii?q?lnA5nUESfKmy0JsXb3C4BuhpI0KEYXrqntcNC3sFsRAmRuzwlFKCSSJTZ2q1X6?= =?us-ascii?q?8k+z47DpmmDYDbRo22gbyOwju7HpNMamBBEFCMHiSgS4LRefABIAuYJsJw2mgG?= =?us-ascii?q?XLKlRp4J1Ra2vwjnzaYhJeOCqQMCspe2nud4/PbekQp2vRBpBsKQmSnZQ355hX?= =?us-ascii?q?gFQyQewq1loFd8xVHF2q991a8LXedP7u9EB19pfaXXyPZ3XpWrAlrM?=
X-IPAS-Result: =?us-ascii?q?A2EbAAByM9pb/zCZrQpkHAEBAQQBAQcEAQGBUQcBAQsBgVU?= =?us-ascii?q?FgjcKjASOIXqWLRSBZggEAYF3gnUCg1o0DQ0BAwEBAQEBAQIBAQKBEYI2JAGCY?= =?us-ascii?q?AEBAQECAXIHBQsCAQgOCi4CMCUCBA4FDoJISwGBealthTyEXA+CbYY0gl+BQj6?= =?us-ascii?q?BEScfgU5JNYRmAgKDSYImAo5whg2KIgMGAoQVgXCLG4FUiBWGZpcKAgQCBAUCF?= =?us-ascii?q?IFDgg5wFTsqAYJBgiYXjhpviU4BK4EBgR8BAQ?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Wed, 31 Oct 2018 19:03:51 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1531.003; Wed, 31 Oct 2018 19:03:51 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Joe Abley <jabley@hopcount.ca>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] review: draft-wessels-dns-zone-digest-04.txt
Thread-Index: AQHUb9DNUsmGoGx89EKmmuwEVFyHAKU6P2UA
Date: Wed, 31 Oct 2018 23:03:51 +0000
Message-ID: <509F5E08-5EDF-4A54-BB34-A76BA390F01D@verisign.com>
References: <154020795105.15126.7681204022160033203@ietfa.amsl.com> <DD4AADA8-A23A-4C2C-9F0D-401CA5A51745@hopcount.ca>
In-Reply-To: <DD4AADA8-A23A-4C2C-9F0D-401CA5A51745@hopcount.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_363FA55F-3CB5-48C1-B32E-A4763676B573"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kIch-3Qt4PQShow8B8PP03Xb7dI>
Subject: Re: [DNSOP] review: 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: Wed, 31 Oct 2018 23:04:00 -0000

Hi Joe, 

Thanks for the detailed review.


> On Oct 29, 2018, at 2:45 PM, Joe Abley <jabley@hopcount.ca>; wrote:
> 
> Hi all,
> 
> I have read draft-wessels-dns-zone-digest-04.
> 
> General Summary
> 
> I find this document to be generally well-written, clear and unambiguous.
> 
> ...
> 
> Nits
> 
> The document contains a normative reference to RFC 3658 which I think is fine in the context in which it used.
> 
> The document makes frequent reference to "zone file" which I find anachronistic. Maybe it's just me, but I think we're talking about a zone object or a zone structure, and the phrase "zone file" to me suggests that we've all tripped down a time vortex, it's 1993 and Vixie hasn't even bought his first tractor yet.

Yes, Mukund pointed this out as well and it is fixed.

> 
> This document uses "RRset" and "RRsets" rather than "RRSet" and "RSets". The RFC editor seems to have no style guide for this, but my impression is that RRSet is slightly preferable (not to me, but I'm happy to sheep with the consensus). Just thought I'd mention it.

Changed to RRSet and RRSets

> 
> Commentary
> 
> Section 1.2
> 
> I don't understand the benefits of suggesting that verification of a zone digest "would be implemented in name server software". The inference is that software that normally concerns itself with responding to queries should be extended to check zone digests, which seems unnecessary and contentious; in general it's not the libraries or executables in which the software live that is important but rather that there be a trusted relationship between the verification process and the software that consumes the validated zone data. I think the final paragraph could just be removed.

The thinking here is that its best to have the verification part as close to the serving part as possible.  If there is agreement that this text is an unnecessary distraction, then it would be okay
to remove it.  It doesn't affect the protocol itself. 

The trusted relationship is key, I think.  I have heard people suggest, in the context of "hyperlocal root," that the perhaps all these millions of Internet access routers and access points should serve the root zone.  These devices have notoriously bad security, and I think it would be a mistake to assume that zone data read from its flash storage does not need to be verified before it is served.


> 
> I think supporting multiple ZONEMD records per zone using different digest types might be useful if it was specified in such a way that it ensured that consumers of the ZONEMD RRSet should not fall back to other digest types if their preferred type did not work. I understand the concern about downgrade attacks in general, but in this case if the ZONEMD RRSet is signed, a downgrade attack would require the ability to replace the covering RRSIG, and if you can do that you don't need to force a downgrade, you can just replace the ZONEMD RRs' RDATA with your own and re-sign illicitly.

I think you might be the first person to argue for supporting multiple ZONEMD algorithms per zone. I actually expected more.

What you're saying is that a recipient would have a list of supported algorithms, ordered by its own preference.  It finds the most-preferred ZONEMD RR, and uses only that one for verification, ignoring all others.  Correct?


> 
> I think it would be handy to specify a short name for each of the four fields used in the ZONEMD RDATA, e.g. as was done in 1035 with SOA.

I'm open to it.

> 
> Section 2.1.3
> 
> You might specify what action a consumer of a ZONEMD RRSet is required to take (following this specification) in the event that it finds an RR with reserved field != 0.

To me this belongs in the Verifying Zone Message Digest section:

        The Reserved field MUST be checked.  If the Reserved field value
        is not zero, verification MUST NOT be considered successful.



> 
> Section 2.2
> 
> You don't specify the representation of unsigned decimal integers clearly enough for me to know whether leading zeros are tolerated or preferred.

I emulated RFC 4034 here.  I guess I'm not aware of any decimal presentation fields that prefer leading zeroes.  How would you like to see it specified?

> The example in section 2.3 makes it clear that the venerable tradition of using round brackets to encapsulate multi-line presentation formats is expected; I can't remember just now whether that's written down anywhere, but if it isn't perhaps it's worth a mention.

RFC 1034 sayeth:

3.6.1. Textual expression of RRs

  ...
  In this format, most RRs are shown on a single line, although continuation
  lines are possible using parentheses.


> Section 3.1.2
> 
> I think that in the specific case mentioned the two SOA RRs are expected to be identical. I wonder whether it's worth generalising the advice to confirm that where there are multiple identical instances of RRs within a single RRSet (same owner name, RRType, RDATA, class, TTL) only one is included in the calculation of the zone digest?

It sounds wrong to me to say that identical instances of RRs would not be allowed in a zone.


> Perhaps SOA is the only example of this. For the precise reasons given, calling SOA out as a well-known example would make sense even if the specification was generalised as suggested above.

Mukund informed me that repeated SOAs are likely less common than I believed, and probably due to
thinking in terms of "zone files" rather than zones.  Perhaps the bullet about multiple SOAs should
just be removed.

> 
> Section 3.3
> 
> I don't see the point of ZONEMD in the absence of DNSSEC. This section to me suggests that there might be a point to it. I don't know what that might be.

The only point would be so that you could discover accidental zone corruption, rather than intentional fiddling.


> 
> Section 3.4.1
> 
> See commentary on Section 3.1.2.
> 
> I think the situation suggested by the question for discussion in this section only arises if you are querying piecemeal for ZONEMD RRSets and not starting with the job of verifying the digest over a whole zone. But I haven't thought very hard about that, as should be obvious from the frequency of hand oscillation in the commentary above on section 3.2.

(this is in reference to occluded data).  Per discussions with others I am convinced that occluded data is still considered part of the zone, and should be included in the digest.

> 
> Section 4
> 
> As above, I don't think it's useful to specify verification of zone digests in the absence of DNSSEC. If there's no chain of trust to the apex DNSKEY RRSet, I think consumers SHOULD NOT infer anything about zone integrity.

I'd like to hear from others on this point.

> 
> Section 5
> 
> I am mainly ambivalent about the RESERVED field. I generally it would be better to burn another type code for a new mechanism, but I understand the consequent trade-off of having to specify carefully what behaviour should be intended in zones that contain both, perhaps where one verifies and one does not. Given that the authors already have some code and experimental results of using Merkle trees that seem promising, however, if pressed to have an opinion I would suggest keeping it.
> 
> Section 6.1
> 
> I think you should specify precisely what row you want to insert into that table as a kindness to the IANA (e.g. specify the TYPE, Value, Meaning and Reference). If you get an early assignment then the appropriate documentation will be in the corresponding template and this section can just be removed.
> 
> Section 6.2
> 
> If you want the IANA to create a new registry they need more information than is supplied here. RFC 8126 contains guidance. I'm not convinced, incidentally, that a new registry is required; seems to me that it would be cleaner to reuse the DS RR Digest Type table, but perhaps this has already been discussed and the implementation status thing is real.


Good ideas, thanks.

DW