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

Michael StJohns <msj@nthpermutation.com> Wed, 08 January 2020 23:55 UTC

Return-Path: <msj@nthpermutation.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 D3D7B1200A3 for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 15:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_NONE=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=nthpermutation-com.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 tssZrSYK9XTM for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 15:55:47 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 41AEA120124 for <dnsop@ietf.org>; Wed, 8 Jan 2020 15:55:47 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id n15so4380928qtp.5 for <dnsop@ietf.org>; Wed, 08 Jan 2020 15:55:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=UJ2YNn1iNwzBfGzS+bp9ntbrnmjFuV622sp5HlC8fKQ=; b=rFHCc6Pd6oYLyEyuyLnUC2IhjzPo9X3hdtRKn/nioMQzGoalvz5ly5xi3U8MpyVNu6 H4JycnBMQwQ6D1haBOk66coUnCJiRVumqaojNKuHNFnVba6HqPQEniocJW36NkUICPxi x4jMXpIwr8B4WymA8xHWja3VTalxnG88z0NWNncOuO4ACjieEVZPfWslIk1nE2ewteLh SaVV/suSgRsTFFBBVOTOv8Wb9ERRBuPLwl+d7p2pRChAy6JYdiRFaaZiHDGGsGCauEDN jNZ+KRVunOEUk2KJnLMaxsoqZtwnXhAmXTWSmDlejJeMqA2QEV25F2kADS7UuNFedNm0 KePw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=UJ2YNn1iNwzBfGzS+bp9ntbrnmjFuV622sp5HlC8fKQ=; b=EjTPnqavJ3qFJrLEdxoXWDQNbOjyLH/zZKIUz4foGodiq98p4dKGunee/blJEIuWwo ceOGFb+xfQBghWiYEkh7sFI0cSSAn8TKNo0xdfgshMCcWgFsxlRikF50V6S7+oeCYPDe 8RFSP83trPngfrgDT8hipfmDZFiXhGmfPPnOVSPRbq77VpLy8/mgci3Cknlz9s0Q2TgU IHKYixVHXoz8A8H+LA6L+LsfqYHYb5UutVjNNdL34YoZbZ51oYZncrZKZgQfyejEo6am y2OTNLeghYqzKf4fVIxIfiz9G0rXpVuP3NwUMp0TEc9Cj2GYZP3vdGCavhaUDuC/kt/l 8xpQ==
X-Gm-Message-State: APjAAAWQbDzQY9HqSh2VlGJh9Tu0G9OeuhJ9aEIVXvPpagmZFl0Ho1yz hbkrOpie145Pkn64BH/jWsTIiV229Xg=
X-Google-Smtp-Source: APXvYqwhnxJf6FI7nh3imEj94tT/8M/zi7vR6AUXblLafnouKMLxoUOZaLgRH4gaO+4BX4fkwWAbjg==
X-Received: by 2002:aed:3f77:: with SMTP id q52mr5966801qtf.248.1578527746074; Wed, 08 Jan 2020 15:55:46 -0800 (PST)
Received: from ?IPv6:2601:152:4400:437c:dd4:4ade:7d8:f573? ([2601:152:4400:437c:dd4:4ade:7d8:f573]) by smtp.gmail.com with ESMTPSA id z12sm1655872qts.97.2020.01.08.15.55.45 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 15:55:45 -0800 (PST)
To: dnsop@ietf.org
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>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <4c9cee8f-c05f-1cb4-6a2d-4e61371bf045@nthpermutation.com>
Date: Wed, 08 Jan 2020 18:55:44 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <57C19AE6-CE64-42F4-BFF1-7FD5C442CD4A@verisign.com>
Content-Type: multipart/alternative; boundary="------------25E40138DE75272769CAE16F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ikio25F12lPrhDzZqQyxaTKo6Iw>
Subject: Re: [DNSOP] 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, 08 Jan 2020 23:55:51 -0000

On 1/8/2020 4:22 PM, Wessels, Duane wrote:
>
>> On Jan 8, 2020, at 12:20 PM, Paul Vixie <paul@redbarn.org> wrote:
>>
>> can we please not put the ZONEMD RR at the apex, or else, can we please add an
>> ALG-ID to its rdata. because some day we're going to ship different kinds of
>> MD's, one of which is today's full-zone traversal-required version that
>> optimizes for AXFR, and another will be tomorrow's block hash that optimizes
>> for IXFR.
> Paul,
>
> The current draft already does this future proofing, although earlier revisions did not. So maybe you missed the change and maybe we haven't done a good job of making this clear.
>
> The ZONEMD Digest Type field encodes both the hash algorithm (SHA384) and the traversal algorithm (SIMPLE).
>
> A future update can define a new Digest Type such as SHA384-MUMBLE in which the zone is traversed differently but the end result is still a SHA384 hash value.
>
> The Parameter field lets you encode some Digest Type specific parameter information.  Perhaps something like Merkle tree depth, or whatever would be needed for some other traversal algorithm.

Hi Duane -

If the above is what you intended, then sections 3 and 4 should be 
labeled "Calculating/Verifying the DIGEST for the SIMPLE scheme", and 
there should be some description elsewhere indicating that later schemes 
will provide replacements for section 3 and 4 at a minimum.

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.

So instead maybe change Digest Type -> Scheme type and Parameter & 
Digest -> Scheme data (which is for this scheme just the digest data).

Later, Mike

>
> DW
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop