Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

"Wessels, Duane" <dwessels@verisign.com> Tue, 07 January 2020 23:38 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 54202120020 for <dnsop@ietfa.amsl.com>; Tue, 7 Jan 2020 15:38:28 -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 1TLxft1Ei7sw for <dnsop@ietfa.amsl.com>; Tue, 7 Jan 2020 15:38:26 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.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 C99C2120018 for <dnsop@ietf.org>; Tue, 7 Jan 2020 15:38:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8963; q=dns/txt; s=VRSN; t=1578440306; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=2PETgpAMyoekuqU9IM3E4GCEdtsvgK9Teip/QuFnsdk=; b=UlkbcZVbq+/xjUgas9/zgY7rTSx635yPAYml5a9NDYprhznzWkFUou2u 4co5AVeDIBfcx+8wk43Vs0mBidN8M8IFphqeBZ4VBDc7Z3vAgBmfLuBf5 /E8FWHa/aHlvOgjUnYUYNYlyOrAUwTHp5jKqCvSCiJ8gqLCrEYtAUmsvj dOR1rhPV3XrsxUr5Ty5LA204AxCVgK3quIQjppcHKyUJsXE2/HBvQtyEc 5iUpIO/p/e1mqOWIBLpkTpyJNxLqdvlWMPtpK0JFsvrAu+xQZ5RLhPkAh wMTlhlztxMXTcaq4IPIVsoloNFVYHtrzejzQwvxFaElHX0jztgtrRe7EN w==;
IronPort-SDR: PMbCBmMF1zDfzyaqRk3r3TfLcTxHqJjmFEDSY9R41ALH8sxojdikoW5GL5RIIxe7Yz+nRK+wGn 6AlJEte+lYW1RPmuMho4+DdL/+QVGwh4NpUXF4kJh9IXnesC8dYTqo68NL0f6chdzv5Lrp0nWv GxTXgxrTs5ozmxZExKZYPDz+qYWScDgdzLMtkhqSt1dD+f78xjEbsJtgbbu15f8kkZZS5FmAYi Y/S1CjFNOB0zCrUQJJgm989af7X9Of8kIjoMLKMgBO9ISmDE+DmhenLv4Ypa3HirEzdngFOng0 RTs=
X-IronPort-AV: E=Sophos;i="5.69,407,1571702400"; d="p7s'?scan'208";a="29119"
IronPort-PHdr: =?us-ascii?q?9a23=3A6awyFRMfWCpCKm187NEl6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0I/zyrarrMEGX3/hxlliBBdydt6sfzbCL7Ou5ASQp2tWoiDg6aptCVh?= =?us-ascii?q?sI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFR?= =?us-ascii?q?rhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTagb75+Ngu6oAXTu8UZnIduNrs6xw?= =?us-ascii?q?fUrHdPZ+lY335jK0iJnxb76Mew/Zpj/DpVtvk86cNOUrj0crohQ7BAAzsoL2?= =?us-ascii?q?465MvwtRneVgSP/WcTUn8XkhVTHQfI6gzxU4rrvSv7sup93zSaPdHzQLspVz?= =?us-ascii?q?mu87tnRRn1gyoBKjU38nzYitZogaxbvhyvugB/zYDXboGbNvVweaLdcs8VSm?= =?us-ascii?q?daUcZdSylBD5m8b4cTEeYMO/tToYnnp1sJqBuzHQegC+PxxT9TnX/5w6k60/?= =?us-ascii?q?85HQrb0gIgAsgBsHLKo9n7KawfVv26zafWwjXYdPNZxzP96JPTfxA/v/6MR7?= =?us-ascii?q?NwcdHQyUkgEQPJlEmfqYvgPz6M0OkGrmuV7/J4WO6yl2IrsRx9rzqhy8s2l4?= =?us-ascii?q?XEhowYxkrL+Ch92Io5OMG0RFRmbdOmDJdcrTyWOoR1T884Xm1luz42yrMYtp?= =?us-ascii?q?O4YCQHzZEqyATcZvGDaIeF5xzuWPiMLjp5gX9qY7ayihew/EWlxODxWMu530?= =?us-ascii?q?tMoyFYiNfDrGoN2AbW6sWfT/t9+Vqu1iiX2gDI7+FEPVg0la3GK5492rIwlo?= =?us-ascii?q?QcsUDEHiLuhUj4kLeYelgk9eaw5OroY6nqqoGGO49qlg7+Nb4umtSlDesiLw?= =?us-ascii?q?cCRXab+f6n1L3l50H2XLJKjvgunqnYtpDVO9gbq7akDwNJyIov9hSyAjm83N?= =?us-ascii?q?gFnXQKIkhJdR2DgoTxPlHBOvH4DfOxg1S2lzdrwujLMaDvA5rTNXjDi6nufb?= =?us-ascii?q?Jm60NH1go808pf55NPCrEAL/LzXFX9u8DfDh88KwC02froCM1h1oMCXmKCGq?= =?us-ascii?q?qZMLjQsVKT4OIvP+mMZJcLtzbnLvgl+uLugmUlmV8ceqmp24EbZ2y/HvRjO0?= =?us-ascii?q?+Ze2bjgs8dEWcWuQozVPHliFuZUT5Uf3a/RKM86S8nCIKoF4vDQZqtgLPSlB?= =?us-ascii?q?u8S7hXbWBPB1TEKmvKcIWCQL9YbTmQCsl9kiQJT728V4Y91Bao8gT9zuw0AP?= =?us-ascii?q?DT/3hSip/4z9Vx/KmbuQw78zE+R5CRzGyWVGxwhUsWSiU3x6Fwpwp2zVLVgv?= =?us-ascii?q?swuOBRCdEGv6ABaQw9L5OJl+E=3D?=
X-IPAS-Result: =?us-ascii?q?A2FkAgACFhVe/zGZrQpmGwQDBRYDA4F/AoM+gQYKlQglg?= =?us-ascii?q?26XSAkBAQEBAQEBAQEDBAEvAQGEQAKCDjkFDQIDAQELAQEBBAEBAQEBBQMBA?= =?us-ascii?q?QEChiyCOyKDVgEBAQECAR1cBQsCAQgYLgIwJQIEDgUOgxQBglcRrCCCJ4VPh?= =?us-ascii?q?F8QgTaBU4pggUI+gREnDBSCTD6ESINDgiwEjXKKZJZJAweCNoNhgjiQHppfp?= =?us-ascii?q?gqDKgIEAgQFAhWBaoF6cBVlAYJBPhIYDY0dARcVjg50jjstgQSBEAEB?=
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; Tue, 7 Jan 2020 18:38:16 -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; Tue, 7 Jan 2020 18:38:16 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Michael StJohns <msj@nthpermutation.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] Working Group Last Call for: Message Digest for DNS Zones
Thread-Index: AQHVxbOIcil7SYf0b0KF3T9N6q33cg==
Date: Tue, 7 Jan 2020 23:38:16 +0000
Message-ID: <9894F18F-85A5-42D4-9608-AEDF9BED9265@verisign.com>
References: <CADyWQ+G1w9_vcU3oO9MsKcP4hTLPXKFb+xY7LJGExbAfjzsDMw@mail.gmail.com> <84650844-1d13-9377-c913-23dcbc76dc37@nthpermutation.com> <C4EB59C4-EA83-4DBE-84D0-D8D43735B63D@verisign.com> <7f298591-09b5-dd7c-0dab-afc60def874b@nthpermutation.com>
In-Reply-To: <7f298591-09b5-dd7c-0dab-afc60def874b@nthpermutation.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=_A9D4903E-BEC4-4544-9DCC-1079B4ED6B67"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/t3MavmvhQ68FnWL6ddBkXtahnE8>
Subject: Re: [DNSOP] 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: Tue, 07 Jan 2020 23:38:28 -0000


> On Jan 6, 2020, at 6:15 PM, Michael StJohns <msj@nthpermutation.com> wrote:
> 
>>>>    This specification utilizes ZONEMD RRs located at the zone apex.
>>>>    Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
>>>>    specification.
>>>> 
>>> Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client".
>> The current text was agreed to during earlier working group discussion.  The problem with "ignore" (as John points out) is that it could mean the non-apex RR should be omitted from the zone.
>> 
>> At one point the document said that non-apex ZONEMD was forbidden, with the implication that if found the whole zone should be rejected.  Similar to what you might do with a non-apex SOA.  But that seemed pretty harsh and in the end we settled on the current text.
> 
> Your text "have no meaning in this specification" doesn't actually tell me what to do when I receive a non-apex ZONEMD RR. Maybe instead "Receivers SHALL NOT attempt to validate non-apex ZONEMD RRs.  All other validation rules apply (e.g. inclusion in the HASH using the actual value)"....
> 

How about this:

2.1.  Non-apex ZONEMD Records

   This specification utilizes ZONEMD RRs located at the zone apex.
   Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
   specification.  Non-apex ZONEMD RRs MUST NOT be used for
   verification.  Non-apex ZONEMD RRsets are treated like any other
   RRset (which is to say they are included) during digest calculation.

   Unless explicitly stated otherwise, "ZONEMD" always refers to apex
   records throughout this document.


> Assume that someone will screw up and place a ZONEMD RR where it shouldn't be.  Figure out what that does to the validation process.   Is it included in the hash?  If so, does it get included with the actual value of its fields or using the placeholder format?  Or do you check it both ways?

Yes, in fact I myself made this mistake when testing my implementation.  It's why there is a non-apex ZONEMD record in example A.2.

DW