Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt

Brian Dickson <> Thu, 01 November 2018 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1752128A6E for <>; Thu, 1 Nov 2018 11:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Ux858yRxs1H4 for <>; Thu, 1 Nov 2018 11:49:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44111124BAA for <>; Thu, 1 Nov 2018 11:49:40 -0700 (PDT)
Received: by with SMTP id v24so233211uap.13 for <>; Thu, 01 Nov 2018 11:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QuLVLlYrF6Vi7Q8T2EQsddTqAEm+9hnV5mMhgF0qeLs=; b=q62/AvDUMZWOQNYbgSDz6o5zkotdXs12taq0TATnq3jJSyvdgXnn0ihiZ8B+770gkm 94h8nT0jWoolZhGuk4XBfkVsqZ5JHLLX2yH/6yn29z3MwPqvK4EVHni+UNw6YwdTDsSc 1zG2Lnzo0kwI49zuJAXcnQlp5PHbfIQrmwwr07geogL7pQhiI0vWY50BvKbAOcUf8+x1 bz1HAO9Go/LrFKUUfE/mimN1GeDTroHbmPTPLcoaPGxTLF3g/y2unz9DvHlMbVABeVmy EFeQHnTpFQAbGUynpp8vX7Yg5slbx0DWeuNx1+eJuV3YHP8KikNTW29ALyA3pJzyrmtN uHTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QuLVLlYrF6Vi7Q8T2EQsddTqAEm+9hnV5mMhgF0qeLs=; b=USl24Y/DVsFDpza81446eWrsCUWqhoWHY9E0bu6gH9gMynt4qsOPYZclSXXot6KJCP NTDRK+SUMnQhQKJTDCIpx2BTPAnzNphe0UW0uk4GUcYzFy7GLw7ID18ToG2hcWR6fT8T eadbqfUZDKYTrkYAffK0wsvsxzTMafZ1TM4wwxrHz+IPQBRNdMQ/1ydb5d89dd21QXJp aiClFk62C0fmgOYwZg+OqQvTMKCNtc67uaAQChNhE6XzBi5JcHEx6otCzdrKWMDw8kvA eYtDPOuOkpf8YB2BPca44IIhJN7qHffqoMQLlowOXFy9R0VHdQSXyXFHY8m65tPjPRiJ cuiQ==
X-Gm-Message-State: AGRZ1gIre+HMkxwmv1lc0owUl3UgQbdkYMwWf892U0tV4qeXd0bOa1jW y6FoEStOaAnA//fC5s1VVlwCrSjwtDoCBgeOjp5FtAay
X-Google-Smtp-Source: AJdET5cfzKq+81JoHISa1W9J4yvPUEinjTggyx4jYKsveVSmLG3VoAOcsyeC8dIOB36MJyQxD94+VOLNBQ20xgPWgiY=
X-Received: by 2002:ab0:4128:: with SMTP id j37mr3830604uad.58.1541098179006; Thu, 01 Nov 2018 11:49:39 -0700 (PDT)
MIME-Version: 1.0
From: Brian Dickson <>
Date: Thu, 01 Nov 2018 11:49:27 -0700
Message-ID: <>
To: " WG" <>
Content-Type: multipart/alternative; boundary="00000000000086177905799ee104"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt
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, 01 Nov 2018 18:49:43 -0000

Joe wrote:

> On Nov 1, 2018, at 16:27, Paul Hoffman <paul.hoffman at> wrote:
> > The current ZONEMD draft fully supports algorithm agility. What it
> doesn't support is multiple hashes *within a single message*. Having seen
> how easy it is to screw up OpenPGP and S/MIME message processing to handle
> multiple hashes, I think having one hash per zone is much more likely to
> work.
> Suppose everybody supports digest algorithm A (e.g. it's the digest type
> that was mandatory to implement in the original specification). We use that
> in our ZONEMD RR because we have high confidence that clients will support
> it.
> At some later time digest algorithm B emerges which has some advantages
> over algorithm A. B is newer and not all software supports it. We would
> like to use B because its advantages are attractive to us, but we also want
> all of our clients to be able to use the ZONEMD RRs we publish.
> Since B is new we have lower confidence that it is supported by our
> current clients.
> We cannot use both A and B simultaneously on the publication side, since
> the specification requires us to choose just one.
> There is no signalling mechanism that will give us insight into our client
> population's support of algorithm B, even if we have non-empirical
> expectations that support will increase over time.
> Since we don't want to break things, we cannot use B.
> Joe

So, giving this some tiny bit of thought:
When is zonemd added to a response, is that when doing an AXFR?
Maybe signaling the algorithm(s) for which signature(s) are
desired/understood would do the trick?
I.e. in an EDNS option?

Do it as a list of signature combos, as an ordered list. Go through the
list, and return the answer for the first entry whose requirements are met.

E.g. I understand A and B, but can only handle a single signature. I want
to receive B if it is available, with fallback to A if it is not available.
I specify "B", "A".
E.g. I understand A and B, and want both and will accept either. I specify
"A AND B", "B", "A".
E.g. I understand A, B, and C. I can handle multiple signatures. I want C
if it is available, or both A and B if C is not available but A and B are,
and if not, any of A or B. I specify "C", "A AND B", "B", "A".

This has the side-effect of providing information about known signature
types, at least those I'm willing to advertise. (E.g. I understand the
programming language COBOL, but I won't advertise that fact on my resume.)