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

Michael StJohns <> Thu, 16 January 2020 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0157D12085E for <>; Wed, 15 Jan 2020 17:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yxZzzrAoXmk1 for <>; Wed, 15 Jan 2020 17:28:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E607120113 for <>; Wed, 15 Jan 2020 17:28:24 -0800 (PST)
Received: by with SMTP id q8so9368819pfh.7 for <>; Wed, 15 Jan 2020 17:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=M/l1Ay3fxb1HyIBIhCsDMrZ45H9/syfTt7e7yU/RvuQ=; b=aYjA6su2u7SVom+ah3rMe1ta++kw6lT7K7x6m6g+N71oCsLAiPdkmvrkLyx5SkK4mP xvKpgU5AK3rOu1AZpGoDOKDCcSzOanRvkM/fHUuDfj/OCxdTrbtmqE8IF2b7gieelDWO trE1S/e/0AExKgPyElwgmNnYJHB9H4ETBuZ1Kn6lYFeiXgu9YkIT5lakpbD6Ixob0ub0 3XAoTW3pVJxC0txWcZ31RcuL6LepAVox0RSFC1dwinKDRz7r0/niDOtzC4GSiwBvRD17 OBeGpeMokqvKtb0tTbjlkpn0VaZgS4DugQSZh15AUVbgFLlk4jzPw989DAHF1DbTWC+I WAcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=M/l1Ay3fxb1HyIBIhCsDMrZ45H9/syfTt7e7yU/RvuQ=; b=RsPPElG6N6fv1IWLXTnZ6EdutMLC7eQywAGBhWAnCgqixEgeNAYx5GzbykAFs3RZ+3 KPUS4hbjzUbjv2o9nxRXNHexWHOOfgOi89ExVAM9ZAPDJH9HF/a4ya8ElqSiR+sacF+o Fg8y6251BDg9K6ZGwPI/aAAkYjXwxaaR86wEWtVGe+skkd4+A1ek8Th/AeHpu/Wt+QK8 BZQ2r6yii0oKk3iVXRryfF66CNO91mZby0Bt3dto52NHjRsJ0t3Rg26D+IxiUj3jvbqZ kCCPNJKa3JpS1oFkZbEOxIzv1URd7EId1PNNqCrTrw9jXdcVjtPbBwxiwPe90iJcuOBh cMtA==
X-Gm-Message-State: APjAAAWxmk3jBbnjs2fY02KSfyVrl2sVmto5JTLqGOW3Rv00Q3GFJJZW TY4BtcHBrKVzSahGYwevWgkhPQ+ltZI=
X-Google-Smtp-Source: APXvYqxqiOAFMpYmQ0BV2iG9a80v2tk0uoFyA2cHdLXNyzMjc6qCYq2jfyZGjUlPxg/qJ4jLep4soQ==
X-Received: by 2002:a62:3343:: with SMTP id z64mr33386164pfz.150.1579138102975; Wed, 15 Jan 2020 17:28:22 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id u12sm22177927pfm.165.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jan 2020 17:28:22 -0800 (PST)
References: <> <> <> <28189634.PH2fhW1m7e@linux-9daj> <> <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Wed, 15 Jan 2020 20:28:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jan 2020 01:28:26 -0000

On 1/15/2020 1:25 PM, Brian Dickson wrote:
> I don't disagree with the notion of a strong differentiator between 
> ZONEMD and any other digest, either using RRTYPE or with an 
> underscore-prefix name.
> 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.)

*sigh*  I think its a co-existence issue here.  I don't think you should 
have two different (calculation-wise) ZONEMD-like RRSets in the same 
zone for the reasons you've mentioned.  I don't think that reserving RR 
types is the right way of doing things and I'm not sure how you'd write 
the IANA guidance to cover the later assignment of those type numbers.  
It's possible that we can tweak this a bit and get around the problem.

So maybe:

1 byte - Scheme - 1 == SIMPLE

Which has a body of

1 byte - digest - 1 == SHA384, a

followed by N bytes of the appropriate digest length.

And either "Only one Scheme shall be used per zone.  A receiver shall 
consider a zone containing multiple schemes as invalid for the purposes 
of this document".   or "The SIMPLE scheme shall exclude any ZONEMD RR 
of a non-SIMPLE scheme from the digest calculation for the SIMPLE 
scheme" or "ZONEMD digest calculations for any scheme shall only include 
ZONEMD RRs with matching schemes - no placeholder records for non-scheme 
ZONEMD rrs shall be added to the calculation".

I think the last of these three is probably the right approach.