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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 15 January 2020 18:25 UTC

Return-Path: <brian.peter.dickson@gmail.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 CFAD81208FB for <dnsop@ietfa.amsl.com>; Wed, 15 Jan 2020 10:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_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=gmail.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 OGwCiZG5zoh3 for <dnsop@ietfa.amsl.com>; Wed, 15 Jan 2020 10:25:24 -0800 (PST)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF9F1208D4 for <dnsop@ietf.org>; Wed, 15 Jan 2020 10:25:23 -0800 (PST)
Received: by mail-vk1-xa2b.google.com with SMTP id d17so4976313vke.5 for <dnsop@ietf.org>; Wed, 15 Jan 2020 10:25:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bbBhrLoKwAphAH1xx7jIX5SUhr8x3HoSBr5DEjBszLc=; b=Md3j4D1X8UIqF08je0mxTYGFBZ5ahUiizxCGq7eYhVl79iNSdwHYFaWiZ0MkS7LdPF t0OiNlk8io3FVXaAQzR5MV9Ku2S8reWKnGjY9sf2lFNwUf7eqY+uqokkLeUTouTokIol Qe9X0MKfB7+Wus9XhLVFiUo+lfihP1DmmQYfMvOXQGphfZ7c4vXS/m0T96hNPnWAUexq ou1PR4vS7Qv74XpL8NOv4Kr8RjIiVE+bnGx2GvfT/PevCMMxY/9jbJy9N6Uhs3Ogbp8J 8Xo4/kqu8qsrWRzal6A2aFw9zvYHrSbYElKsQ2E2/I6HYTZLRVoKFC4HfZ5qbTbSsBaq XEfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bbBhrLoKwAphAH1xx7jIX5SUhr8x3HoSBr5DEjBszLc=; b=cEyHYNG7Es7tLQ4I5+go+rHgkAlWAd/cQzr3me/4PttKoX5WvqhgMj6EDifKW59ack qK+2XzfdjsoZhVDvuFYQKfEmjt3ksiUgaXF0kEqxBwelhHtpvXPQGbgdE+MG6g9/fhSz fBQ1UeStsK9A9myQXwetG7/oOnzaN+wvefIiykPjz9y0mzZg2cjkrnnyv29idIY0BDaY cbUgECBsTGGHRSU0Lk9V6tKH1A2P889WY7O7W1yvfMnjZGqgBocAhl4PIuRJKnd0Mj85 mGVjzJKoDvTByWpqzy2V7c7t+LCKcC4RT7HLes+pASOwvQLEfMVX/gtfH31yKNbHZTVp wNUg==
X-Gm-Message-State: APjAAAVFKfHTgRVYs+H01W1LRxEO/uwz0xrGfsTzuYLVQC6M0ln/PO5i 5ZHEZc02PUc+goTdy9RBRts2JMVP/knti0WA3oE=
X-Google-Smtp-Source: APXvYqxpaEvfC0izIbQpscK8vv8wvngbz2RRWArucUscbSAWCgW7HxPG7ze7AuS+Wjovx+Y65mnd3YtcPvbHtuJH3Hw=
X-Received: by 2002:a1f:dc42:: with SMTP id t63mr15251371vkg.5.1579112722917; Wed, 15 Jan 2020 10:25:22 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <956DFE58-587E-47FA-8D60-C279351697ED@icann.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 15 Jan 2020 10:25:11 -0800
Message-ID: <CAH1iCirrLDfrVxUNx4eYdpv5Gfw2X=k_byOprDN9CZDkyLDoiQ@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Shane Kerr <shane@time-travellers.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e8eead059c31d4b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FYeuXGqztFP56cl5NM0vBrrfiWY>
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: Wed, 15 Jan 2020 18:25:29 -0000

On Wed, Jan 15, 2020 at 7:06 AM Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Jan 15, 2020, at 12:14 AM, Shane Kerr <shane@time-travellers.org>
> wrote:
> >
> > Duane,
> >
> > On 13/01/2020 19.26, Wessels, Duane wrote:
> >>> On Jan 8, 2020, at 3:55 PM, Michael StJohns <msj@nthpermutation.com>
> wrote:
> >>> There's also the case that future ZONEMD schemes may need a different
> format for the digest field.   E.g. one approach to dealing with
> incremental changes is to have a NSEC like ZONEMD record which covers
> hashes only across a range of names.
> >> We think that the currently documented RR format will solve most use
> cases - since the digest field is variable length, it already provides a
> lot of flexibility for future uses, by defining additional Digest Types.
> Anything which cannot be solved with this format seems like it would be a
> sufficiently different protocol that it would deserve a new RRtype and
> document.
> >
> > Honestly thinking about it more, I'm not even sure we should consider
> supporting an incremental version of zone digests in ZONEMD at all. There's
> no harm in introducing a new type with its own syntax and semantics if we
> tackle that problem in the future.
> >
> > Some agility is needed to add new hashing algorithms, but beyond that I
> think maybe we should consider ZONEMD perfect in every way and not ever
> needing to be revised. 😉
>
> Thank you for voicing this, Shane. Given that any incremental digest
> mechanism will have at least a few significantly different processing
> rules, I strongly suspect that it would be easier for implementors if there
> were two different RRtypes. The requests to have both sets of processing
> rules under one RRtype seems actively dangerous from a security perspective.
>

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.)

Brian