Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-00.txt

"Wessels, Duane" <dwessels@verisign.com> Mon, 24 June 2019 07:22 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 4F44712011C for <dnsop@ietfa.amsl.com>; Mon, 24 Jun 2019 00:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.311
X-Spam-Level:
X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 QhOiVaBcgyD5 for <dnsop@ietfa.amsl.com>; Mon, 24 Jun 2019 00:22:34 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 DAF951200DE for <dnsop@ietf.org>; Mon, 24 Jun 2019 00:22:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=155560; q=dns/txt; s=VRSN; t=1561360956; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3LtKzPqNqgycnvqJhR20L4Svi3vpe9JGtPLPBymB+6o=; b=O9qsfXQaAMsQySTkR2JFYB4j+bC1fVxfHfCOmSzAftphefnDyT8pzOIs +ak/F6uNf9QBQlQLOxPC/a9hhkv+zSBnFReJK9BWYoP+vHJypiEZnlTDD q3cK27LM5Ybch2KuDaVfur11rC4BRltoUkT7oc3py1hRooEfmtjFJhcgU yTT+cI5h2WrwwskS/4ffRET/NdL+n7CV35Paow2Ite0bMvW+LLc+DGarP wFLDLDfG+BAoL4/ntAGCX9+Kc1XVkOtHsiN4Ydmz9jXwfcLX2w1LHvrqF lJn50+0ryGSSbXtCoDAqX3QtmNJsvkSON9TT2cz/Foap+69RLadtRp8R+ A==;
X-IronPort-AV: E=Sophos;i="5.63,411,1557201600"; d="p7s'?scan'208,217";a="7774327"
IronPort-PHdr: 9a23:XebiyR+urs4hDf9uRHKM819IXTAuvvDOBiVQ1KB31OMcTK2v8tzYMVDF4r011RmVBN+dsqsP0rOH++C4ACpcuM/H6ChDOLV3FDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3OgV6PPn6FZDPhMqrye+y54fTYwJVjzahfL9+Nhq7oRjPusUMnIduN6k9xgbUrnZMZu9awX9kKU+Jkxvz+8u84YRv/zhMt/4k6sVNTbj0c6MkQLJCET8oKXo15MrltRnCSQuA+H4RWXgInxRLHgbI8gj0Uo/+vSXmuOV93jKaPdDtQrAvRTui9aZrRwT2hyoBKjU07XvYis10jKJcvRKhuxlyyJPabY2JKPZzeL7WcNUHTmRDQ8lRTTRMDIOiYYUSE+oPM+VWr4f/qFsPsRSxChKhBOzzxj9NnHL6wbE23/onHArb3AIgBdUOsHHModn7NKgdT/u1zLLWwjXHdPNawSr25obVch87p/GDQ7x8etfWxEYyGQLKkE6QqZf7MDORzeQAqHab4PR6VeKukG4nqg5xoj61ysgwjYnJg5sYx1bZ/it62IY4PcC0RFJhbdK5EpZduTuWO5Z2T84sWW1ltyI3xqUbtZKnZiQG1ZYqywLFZ/CafIWF4QjvWPuSLDtginJqZrGyiwq3/EWl0OLxVc25301PoydLjNXDq3EA2hnI5cWDS/Zw/EKs1DiB2g3R9+5JJ10/m7DBJJ472LEwk4IesUHEHiDrhkr7lLSWdkA4+uiw7OTnf6nmqoecN4BqjgH+Nbwjl9GjD+ogLwQBX3CV9+u927H/40H1WqtKgeExkqnDqJDWP94UqbOjDw9LyIYj8BC/Ay2639QfmHkLNFNFeBSZgIj1I1zCPez0Ae2ij1munjpn3e3KM73vD5nXIXXOlK/tfbNn5E5dzAozw8pf55VRCrwZPf3yVFH+tMfDDhAnNwy02P3qCMtj2YMEWGKPGa6ZMKzUsVOS+u0vJOyMaJcPuDnhM/gl++LujXghlFAAe6mpxpwXaGijE/RnPUqZfXTsjs0GEWcQsQptBNDt3ReOVyVUf16zUr4yoDYhB8qZIs2LEoyrm7uZ9Ca2ApMQYXpJXAOiC3DtIs+7VuwXZSaJZodNjzUCWPLpH4M+2Aq1uQvh46RqNOvP+yIe85nk0Y4mtKXoiRgu+GksXIym2GaXQjQskw==
X-IPAS-Result: A2HEAQDHeBBd/zGZrQphAxwBAQEEAQEHBAEBgWeBaIEZgSwKh1aRPINghDGQaYErFyEECQEBAQEBAQEBAQMEARgBDAYEAQECgQKCBYE3AoMKOBMBAwEBAQQBAQEBBAEBAQKLIAyCOiIYBE04AwMBAQEBAQEBAQEjAQEBAQEBAQEBAQEBAQEBAQEBAQEWAg0mDQQSAQEYAQEBAQIBAQEYARJBEAkCAgEIGCABDQIZDAslAgQKCQ4Ggw4BgXseo3mDdUECDkFAhFUQBYEvgVGDf4YlgUE+gREBJh+CTD6CVQwBAQIBAYEiCAESAQgBHBEKJoJ1giYEi3wHh2NbhgGBVo1xAwYCghSDJ4IcgQqEYoN3hFeCKC88hiKECog7gU2NJoEvhgCFIIZPdIJxAgQCBAUCFYFnWTBxcBUaISoBgkEJghQtGoF9gVCEWTuFP3IBATCNLgINGwOBBIEhAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 24 Jun 2019 03:22:29 -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.1713.004; Mon, 24 Jun 2019 03:22:29 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-00.txt
Thread-Index: AQHVKl2U0sZbKXpT7E6qYKPiLL8dzA==
Date: Mon, 24 Jun 2019 07:22:29 +0000
Message-ID: <8EF45B1E-1F80-49CA-97E8-0E7DE497A313@verisign.com>
References: <156135988131.17726.12457283360064863692@ietfa.amsl.com>
In-Reply-To: <156135988131.17726.12457283360064863692@ietfa.amsl.com>
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=_FFEDF0B4-4CAB-4C01-8956-2B60AC214421"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_AEf3uYYJxiDxNkZV0314Av66s4>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-00.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, 24 Jun 2019 07:22:40 -0000

DNSOP,

Here's a summary of the changes since the previous version:

   From -06 to -07:

   o  Fixed mistakes in ZONEMD examples.

   o  Added private use Digest Type values 240-254.

   o  Clarified that Digest field must not be empty.

   From -07 to draft-ietf-dnsop-dns-zone-digest-00:

   o  Adopted by dnsop.

   o  Clarified further that non-apex ZONEMD RRs have no meaning.

   o  Changed "provably [un]signed" to "provably [in]secure".

   o  Allow multiple ZONEMD RRs to support algorithm agility/rollovers.

   o  Describe verification when there are multiple ZONEMD RRs.

I'm also attaching an rfcdiff since this version isn't linked to the pre-adoption version.

The most significant change is that multiple ZONEMD records are allowed.  The document recommends that multiple digests be present only when transitioning to a new digest type algorithm and has this to say about verification given multiple digests:

4.1.  Verifying Multiple Digests

   If multiple digests are present in the zone, e.g., during an
   algorithm rollover, at least one of the recipient's supported Digest
   Type algorithms MUST verify the zone.

   It is RECOMMENDED that implementations maintain a (possibly
   configurable) list of supported Digest Type algorithms ranked from
   most to least preferred.  It is further RECOMMENDED that recipients
   use only their most preferred algorithm that is present in the zone
   for digest verification.

   As a matter of local policy, the recipient MAY require that all
   supported and present Digest Type algorithms verify the zone.


DW




> On Jun 24, 2019, at 8:04 AM, internet-drafts@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>        Title           : Message Digest for DNS Zones
>        Authors         : Duane Wessels
>                          Piet Barber
>                          Matt Weinberg
>                          Warren Kumari
>                          Wes Hardaker
> 	Filename        : draft-ietf-dnsop-dns-zone-digest-00.txt
> 	Pages           : 29
> 	Date            : 2019-06-23
> 
> Abstract:
>   This document describes an experimental protocol and new DNS Resource
>   Record that can be used to provide a message digest over DNS zone
>   data.  The ZONEMD Resource Record conveys the message digest data in
>   the zone itself.  When a zone publisher includes an ZONEMD record,
>   recipients can verify the zone contents for accuracy and
>   completeness.  This provides assurance that received zone data
>   matches published data, regardless of how the zone data has been
>   transmitted and received.
> 
>   ZONEMD is not designed to replace DNSSEC.  Whereas DNSSEC protects
>   individual RRSets (DNS data with fine granularity), ZONEMD protects
>   protects a zone's data as a whole, whether consumed by authoritative
>   name servers, recursive name servers, or any other applications.
> 
>   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
>   fields reserved for future work to support large, dynamic zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop