Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

Benjamin Kaduk <> Mon, 12 October 2020 04:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D77D3A0A35; Sun, 11 Oct 2020 21:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VLdMk-oVILcA; Sun, 11 Oct 2020 21:14:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7AE73A0A3B; Sun, 11 Oct 2020 21:14:58 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 09C4Emng026533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Oct 2020 00:14:53 -0400
Date: Sun, 11 Oct 2020 21:14:48 -0700
From: Benjamin Kaduk <>
To: "Wessels, Duane" <>
Cc: Robert Wilton <>, "" <>, Tim Wicinski <>, "" <>, "" <>, The IESG <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
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: Mon, 12 Oct 2020 04:15:00 -0000

On Fri, Oct 09, 2020 at 06:36:28PM +0000, Wessels, Duane wrote:
> > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker <> wrote:
> >    2.  The ZONEMD Resource Record
> > 
> >       It is
> >       RECOMMENDED that a zone include only one ZONEMD RR, unless the zone
> >       publisher is in the process of transitioning to a new Scheme or Hash
> >       Algorithm.
> > 
> > I'm not quite sure how well this fits with sections 2.2.3 restriction that
> > SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a recipient
> > of the zone info I understand that I would need to implement both, but as a
> > sender am I allowed to only send SHA512, or both, or must I always send SHA384?
> As sender (publisher) you are allowed to publish whatever you want.
> The purpose of the recommendation above is to hopefully avoid the situation
> where multiple records are published (with both types) on an ongoing basis.
> That is something we observe with DS records quite often.  For example,
> 750 TLDs today publish both SHA1 and SHA256 digest types as DS records in
> the root zone.  This new paragraph has been added to the security
> considerations:
> 6.2.  Use of Multiple ZONEMD Hash Algorithms
>    When a zone publishes multiple ZONEMD RRs, the overall security is
>    only as good as the weakest hash algorithm in use.  For this reason,
>    Section 2 recommends only publishing multiple ZONEMD RRs when
>    transitioning to a new scheme or hash algorithm.  Once the transition
>    is complete, the old scheme or hash algorithm should be removed from
>    the ZONEMD RRSet.

While I'm happy to see this statement made, I do want to note that the
actual properties here have some complex interplay, and "only as good as
the weakest hash algorithm in use" may only be strictly true in certain
scennarios.  (So, in the general case, it is a true statement, but there
may be certain cases in which it does not hold.)  In particular, since
DNSSEC signs the whole RRset, it does not seem like it is possible (without
some other attack) to modify things so that the ZONEMD with a different
hash algorithm is not visible while retaining the RRSIG.  And if you have
a signed zone with a weak hash for ZONEMD, producing a different zone that
collides the ZONEMD will probably not retain all the RRSIGS on the other
records (though could plausibly retain most of them).  So, it's
complicated, but I'm not sure that we really need to get into the specifics
in this document.  Personally, I'm fine keeping this text as-is, but I did
want to note the subtlety involved.