Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

George Michaelson <ggm@algebras.org> Mon, 09 September 2019 09:14 UTC

Return-Path: <ggm@algebras.org>
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 4FBED120133 for <dnsop@ietfa.amsl.com>; Mon, 9 Sep 2019 02:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 Gm9CcWVYN8CW for <dnsop@ietfa.amsl.com>; Mon, 9 Sep 2019 02:14:07 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 E41F1120119 for <dnsop@ietf.org>; Mon, 9 Sep 2019 02:14:06 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id r26so26911778ioh.8 for <dnsop@ietf.org>; Mon, 09 Sep 2019 02:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P5fmvenQPLLDYGJ6PxYmIasT+Q8GwOq4hDZKqMEkAuY=; b=1Jhp7TiHYbhtw6eny4Kb+hgqN/dGlUIF2tsweCcoQ0kd37JuEVW2AiuLigF0S/ZkYH MwxnOVQkTSAHr1l6X7gFTQKsQhJma+vUvrVk5WhV49OQcYQv/vLI6XfmKfwT6ed4ADxr pq1zesS3VTRebtrrPTkyPEOf5DQ5h0+NpqthCOYOJG1BkVXbzLQTlulMxTFjjn4JQa0B jt+I8TOxVR9tdOK43h3DkwvmzrmNnQSI4aJIZ4KEHyeOvNaLDQnAIVB8QiYfwEqlNFpx 0Pih7DG9Jr2q/3sq5mGFkmJKPlHBBsXLkqwLMCnfh3SKxKpRICxdtzI++ua4qxZNtMiL GvpQ==
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=P5fmvenQPLLDYGJ6PxYmIasT+Q8GwOq4hDZKqMEkAuY=; b=mMv6/6xOrrXdJnNrJ9gs8fZhm6cXen6XQEDlPKXKduzvVbObsw/tdEdd2Bx20kNSdy 0jsNJzlK+NVBNhzD+Q24+Vs+996zD4CRjtWSuKnZZKybVeElypsKMfg/Lxrzc9PBCxU7 FojV6769/mBY6jiA1jnHkh1ciWQSWVfs6yXyRgmGljbZkPz6CxsZ3Q5BI/Z+P+t088cT +CX7dMorYZD3r+dt1e2KzQXLxNZCBEKw2RDENTGCxlAfEh5tPkaXKyPqD3BbW2MjAwYO PUUcQhWLzfk/b3gTCZf1Zgfj3iWahY8416EDy+ZYwr8hLM6wVehBjiAM0g+AX3UVP6gt zAPg==
X-Gm-Message-State: APjAAAU733P5EXmDWdSHXhztlHnFnrARVbIXanDS9RdUhAvopvry3BLk yXFmfXx61TKQhyM4NrMuvxK2wZvYsL0MysxTyVBWLggCDJo=
X-Google-Smtp-Source: APXvYqxiOx21Wd0w0ApZpi9qGexAycf0pMl0nLJxibj4FEPJblBKT60EjF4zfyvLRoBN/ZSxljWU+pR9DttFE3ENzDU=
X-Received: by 2002:a02:ccb3:: with SMTP id t19mr24688152jap.13.1568020445993; Mon, 09 Sep 2019 02:14:05 -0700 (PDT)
MIME-Version: 1.0
References: <156772626756.24320.17129416326124710273@ietfa.amsl.com> <F32CBA84-2D35-4AA6-AB37-BA24D6F023E2@verisign.com> <40f9c8ae-d7bf-225f-665d-878733b482b4@time-travellers.org>
In-Reply-To: <40f9c8ae-d7bf-225f-665d-878733b482b4@time-travellers.org>
From: George Michaelson <ggm@algebras.org>
Date: Mon, 9 Sep 2019 16:13:53 +0700
Message-ID: <CAKr6gn2ym7JauyJBaxjKACJPQ64+5gK5yzMgY7qZggqjsJdbgg@mail.gmail.com>
To: Shane Kerr <shane@time-travellers.org>
Cc: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af352305921b359e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UKV6t_nzFhp1C_iUHs-9KG4W1Qw>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt
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: Mon, 09 Sep 2019 09:14:11 -0000

This is a not uncommon problem in 'make this protocol work in future' spec.
It could say "for version ZERO of this protocol" and then say "future
versions of this protocol should stipulate what other values mean, and how
this affects handling of all-zeros state, and other states"

Saying "must not validate" baldly basically says "will always be zero" to
me -Which I think is what you're saying!

_G

On Mon, Sep 9, 2019 at 3:04 PM Shane Kerr <shane@time-travellers.org> wrote:

> Duane,
>
> On 2019-09-06 02:01, Wessels, Duane wrote:
> >
> > With this version the authors feel that it is ready for working group
> last call.
>
> Sorry for a late comment, but I decided to give this one thorough last
> read-through.
>
> I'm a little concerned that the way the Reserved field is described may
> make adoption of later versions of ZONEMD difficult. The relevant text:
>
> 2.1.3.  The Reserved Field
>
>     The Reserved field is an 8-bit unsigned integer, which is always set
>     to zero.  This field is reserved for future work to support efficient
>     incremental updates.
>      .
>      .
>      .
> 4.  Verifying Zone Message Digest
>      .
>      .
>      .
>     7.   The Reserved field MUST be checked.  If the Reserved field value
>          is not zero, verification MUST NOT be considered successful.
>
>
> The question is, what can a zone producer do to support both this
> version of ZONEMD as well as a new version? Adding a non-zero Reserved
> ZONEMD value will break any implementation using this specification.
>
> I think what would be ideal is for non-zero Reserved values to be ignored.
>
> If we treat non-zero Reserved the same as unknown algorithms (that is,
> using placeholders) will that be okay? It may complicate generating
> compatible ZONEMD in future ZONEMD implementations. With the envisioned
> incremental version I think it will be fine; if you want both a
> full-zone and incremental ZONEMD then it will indeed be complicated, but
> I think probably few zones will need that. I have no idea whether using
> the placeholder technique will work for more weird and wonderful later
> versions.
>
> I suppose it is okay to reject the use case and not worry about
> compatibility, since we expect the incremental version to be used mostly
> for large zones where the current ZONEMD simply won't work... šŸ¤”
>
> Cheers,
>
> --
> Shane
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>