Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

"Wessels, Duane" <dwessels@verisign.com> Thu, 16 January 2020 01:15 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 D5648120A99 for <dnsop@ietfa.amsl.com>; Wed, 15 Jan 2020 17:15:45 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-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 PFq7VnkXUPBy for <dnsop@ietfa.amsl.com>; Wed, 15 Jan 2020 17:15:42 -0800 (PST)
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 8514F120AAD for <dnsop@ietf.org>; Wed, 15 Jan 2020 17:15:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8981; q=dns/txt; s=VRSN; t=1579137340; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=8UzxDsL951hPvmqCXlRtbUvtRZEQKuClo9x6JhOKAPc=; b=nNK0MSVh7rfUvIHNEA+Td7+yYEMw6l+R09qwtOv+pzeiCh2mJZrdZQ3t RTjPq0Nmi5s4uuQ16Wz3ezmKqrxcIRoyksBbgGCL1j+WodLNjE5wQG9+g lMptXkj7zjIPApkDb9CIhWPOhNS5SQAuhNd0bft/skEbeiYGYYoFniEs8 yQ/0mu1Dptjbb/g8+9/iJ+FIhe1Ca7rpQA23V+pzuX6eD89BBojPP/4EI /UEBFtRJleXTX4ZwCi+eVY28wqYWvMLKqhceAk3XrFPn17HUQZzkKaNYs F9Odt8P6p6LFDxv/GimF+jGKMJFWHIi+rLmF+vALMSl8L7Q66aLzidRz7 w==;
IronPort-SDR: Ztrwiy8F7E5tKS6lI4OE09hRyaxhmoBGVmBolFiiog1zl2NwJfeTzLmAbcCM4Hh3qXHtTRQ5OU 32uO1jldZufiJutc7URHp7tTPUj49bT3Qo8sOKYHTe8lASCk//WBI2Az++3D4tNaHIArhSwIoV +ousVeVgdwCGKiP9+wGMl0zdjPefeOK1qXAjIEIJjk7+4qBINin8GS2CdliT/RO9F/iQV2aNog KNZ0tIdH3U2klPnUT+aI0wLjZwP6pbfTb4R1BJOxC6DoSJzjd1mDriz9Km4fGudCWFWc7jIa56 UUk=
X-IronPort-AV: E=Sophos;i="5.70,323,1574121600"; d="p7s'?scan'208";a="505014"
IronPort-PHdr: 9a23:WeX44Bzt1s/5NJ3XCy+O+j09IxM/srCxBDY+r6Qd0usUIvad9pjvdHbS+e9qxAeQG9mCt7Qc16GM4+igATVGvc/a9ihaMdRlbFwssY0uhQsuAcqIWwXQDcXBSGgEJvlET0Jv5HqhMEJYS47UblzWpWCuv3ZJQk2sfQV6Kf7oFYHMks+5y/69+4HJYwVPmTGxfa5+IA+5oAnMucQam5duJ6k+xhfXoXZDZuBayX91KV6JkBvw+8m98IR//yhMvv4q6tJNX7j9c6kkV7JTES4oM3oy5M3ltBnDSRWA634BWWgIkRRGHhbI4gjiUpj+riX1uOx92DKHPcLtVrA7RS6i76ZwRxD2jioMKiM0/3vWisx0i6JbvQ6hqhliyIPafI2ZKPxzdb7GcNgEWWROQNpeVy1ZAoO9cYQPCfYBPf1FpIX5vlcCsAeyCRWpCO7p1zRGhGL53bci3uohDw/IwRAgEdwNvnTartr7M6YSXvy6w6TTwjXPc/ZW1C396ITUbBwsp+yHU7JqccrWzEkiDw3JgVWOpoz+JDOayOANs3OD4+F9W+yvlnQoqwdvrTSh28whjZTGh4wLxVDf7iV23oI1JcajRU5lf9GkCppQtzqbN4t5RMMuWX1nuCE/yrAfv5OwYSsEyIw/yhLCd/CLaZWE7xDtWeqLPDt1hHxodKiwihu26USs1/HwWtOp3FtIsiZJiMTAu38O2hDJ98SKSeNx/km/1juMywze7+RJLlo3mKffMJEsx7A9moQOvknCGyL5g0H7ga6Ue0gh9OWl5ebqbajgq5SBLYF7kBv+Pb4rmsGnBOQ4NRUBUHaD9OSn0b3j4VX5QLJXjv0qiqXZsI7VJcAcpqOhHgJbzp4t5wu/ADm+39oXnGULIExfdBKZk4fpPEvOIOjiAfilnlugiilrx+rdPr3nGJnCMn/DkLL5cbZ87U5T1hYzwMhC655IEL0NPfD+V0HruNDFDhI0PRa4zunjBdll04MRQ2OPAquXMKPItl+I4/oiLPSCZYALozb9MOYq5/r1jXIih18SY7Op3ZoMaHC5EfRmJV+VbmbrgtcECWsKpBYxTPT2iF2eVj5ef229X7g95j4hDoKqF5/DSZ6xgLOfxie3BIBZZmFaBVCPCnfocIOEVuwDaCKXOMBhkzgEWaK9RI8m0BGkrBX6xKZ/LurI5i0Ysoru1MBv6O3OkRE+7zx0D8OT02GDSmF7hGUISiQ33K9ju0N9zFGD3bJ/g/xCGtxZ/+lJXRsiNZ7A0+x6DMj/WhnBftiTTlapXM6rAS0wTtI03dACelp9G8+4gRDdwSWqB7sVmKKRBJwv6K7c2GLxJ8llwXbcyKYhl0UmQtdINWC+m6F/8RPTB4nRk0iClqala7gc3CDX+GeE12qOsxIQbAkle7/EVHZXSkrdrs/+4AuWRaWvALJhKgZdxNTEJqpBacbui31JQf7iPJLVZGfnyEmqAhPdjIyBd5Hnf35ZlAnAAU4J2UhH8WmLLhMzAjyJvW/EDSdvGlSpaETpp7ot4EinR1M5mlnZJ3Zq0KC4r1tM3aSR
X-IPAS-Result: A2ErAAC0uB9e/zGZrQplGwEBAQEBAQEFAQEBEQEBAwMBAQGBagMBAQELAYM/gQYKlH4lg26FcpFXCQEBAQEBAQEBAQMEAS8BAYRAAoIkNwYOAgMBAQsBAQEEAQEBAQEFAwEBAQKGLII7KQGDTgEBAQECAR1cBQsCAQgYIwsCHxElAgQOBQ6DGAGCSgMOEasMgieIIw2CERCBNgGBUopfgUI+gREnDBSCTD6CG4Itg0OCLASuTjJEAweCOINlgjiGY4UIhEOCR5gnkCWJNYxWgywCBAIEBQIVgWiBfHAVZQGCQT4SGA2IOY4OdAKMTIEQAQE
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.1779.2; Wed, 15 Jan 2020 20:15:38 -0500
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.1779.002; Wed, 15 Jan 2020 20:15:38 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
CC: Paul Hoffman <paul.hoffman@icann.org>, Shane Kerr <shane@time-travellers.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)
Thread-Index: AQHVy7VfxxgKBn/5rkOuCX9kmMtQOafsXqWAgAByqwA=
Date: Thu, 16 Jan 2020 01:15:37 +0000
Message-ID: <F88357C5-3C76-4991-9AC0-49BC7C808940@verisign.com>
References: <CADyWQ+G1w9_vcU3oO9MsKcP4hTLPXKFb+xY7LJGExbAfjzsDMw@mail.gmail.com> <D9E20677-B76F-4028-A283-6FA5DEEC22AE@verisign.com> <b3132d4a-8b91-27ff-83af-0204a47ec2c3@nthpermutation.com> <28189634.PH2fhW1m7e@linux-9daj> <57C19AE6-CE64-42F4-BFF1-7FD5C442CD4A@verisign.com> <4c9cee8f-c05f-1cb4-6a2d-4e61371bf045@nthpermutation.com> <C34B2364-13D8-461A-B15C-090C1C2F6200@verisign.com> <94fc8dac-0735-67af-f413-004e6f84c349@time-travellers.org> <956DFE58-587E-47FA-8D60-C279351697ED@icann.org> <CAH1iCirrLDfrVxUNx4eYdpv5Gfw2X=k_byOprDN9CZDkyLDoiQ@mail.gmail.com>
In-Reply-To: <CAH1iCirrLDfrVxUNx4eYdpv5Gfw2X=k_byOprDN9CZDkyLDoiQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.11)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_4968CCD3-1575-4E7A-949D-1F5AC857E7FB"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NHHVbXNKV78t9A6s5HPpcQDUNrI>
Subject: Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)
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: Thu, 16 Jan 2020 01:15:48 -0000


> On Jan 15, 2020, at 10:25 AM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> 
> However, there is a Heisenberg problem, which is that any other digest type needs to be excluded from the ZONEMD calculation (and vice versa).
> 
> So, from the future-proofing standpoint, I think one of the two methods needs to be picked (I think RRTYPE is fine), and a range of types needs to be reserved for future zone digests.
> 
> I'd suggest small range (i.e. more than 1, maybe 4), and include the reservation in this document with IANA instructions to that effect.
> 
> The exclusion of that reserved future-use digest range should be baked into the ZONEMD calculation itself, so future digests don't require an update to ZONEMD, and don't result in incompatible deployed digest implementations.
> (In other words, future-proof ZONEMD itself.)
> 


Brian,

That could work, but I'm not sure it's required.  You're saying that N types could be defined now (ZONEMD1, ZONEMD2, ...) and that the inclusion/exclusion rules say to just exclude any of these ZONMEDn types when calculating the digests.  

[Note that in the current draft ZONMED excludes only part of itself -- the digest value.  It includes the other fields such as serial.  In other words the exclusion is RR-format-aware.  For the not-yet-defined types you'd probably have to say to exclude the whole RDATA.]

But I think it could be made to work if you define the order of digest calculation.  The newest digest type would always be calculated first.  For example ZONEMD3 would be defined to digest the whole zone except for ZONEMD2 and ZONEMD1 (and their signatures).  ZONEMD2 would include ZONEMD3 in its digest, but not ZONEMD1.  And ZONEMD1 would include all the later types because it didn't know about them when it was written.  I think that would work, but sounds kinda complicated.

Lastly, another, simpler option would be to say that only one digest RR type is allowed in the zone at a time.  Including both ZONEMD1 and ZONEMD2 is an error and cannot be verified.

DW