Re: [DNSOP] [Ext] Working Group Last Call for: Message Digest for DNS Zones

Bob Harold <rharolde@umich.edu> Wed, 08 January 2020 14:18 UTC

Return-Path: <rharolde@umich.edu>
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 A8AF512004C for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 06:18:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 s4n8tTD05fS7 for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 06:18:55 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 C853D120044 for <dnsop@ietf.org>; Wed, 8 Jan 2020 06:18:54 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id v201so2543102lfa.11 for <dnsop@ietf.org>; Wed, 08 Jan 2020 06:18:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b79EINuBCs41kCDLSTYr7e7orpcfg/+R7Pt25XHovuY=; b=Cxxy26mbHMHT1DQY8yuSOR7NnVkgBqF+ruENZTvYRk23O3eg0gJynf+LNiVgUwDT9k 9z+p/xGNSNLGxTjGwXrhLcmj1bwnyQ7wFGxVl077Ov1f3lW/yM58ZPmjPQujCAjJDcKb M5YF7g5q6RZ/sSzFa5IfPU7o5KMVbkoiTz+UgZcjAmcxl6YCr+LHd3uaCpxCKpGpTXBt fmCQRdOd/k+58/bVP7fxipeRmlfHIv3Tkdjr6TwPvAYWTdLolohMhZE89eccFloemYur /K5tArp5iFwG/7AHn2OrhPXzUqS5G6iiLtbLLE8Oq3VfVReJIhC+fdm/YHGc7XHWZIDJ uGJg==
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=b79EINuBCs41kCDLSTYr7e7orpcfg/+R7Pt25XHovuY=; b=eVvolNpgwHaHpoyOvHcPFGA4SFPoC0YBpsnF4i1AjxdZlK2OsbdINBYs9OF1nKHeTo aeTs+4RismsSYqGQh3Tlz7CaS0BG6Qh9qQDMk63yPSKe906wyjIQ1pAZag5WDFehbVWI eWD452mm1HWW3C1m/T55jj789ePzwrP2MNiryjpsS1cmTlT3tD7HnHcOZEz285Mu1+fk DQ7E9VEMn4PpSXxX1gCMjwZynrcNwrnz2C8tqr3Y0Q6fT+qpnmQsKuRjCuxk6ZOG/sq6 BftM/JyzlhKvC42hPAZgG0Z3Giht3MahHz4Hi/y4KNH5ZVI6yvdgYl7gY/vVmHIZfqjP 7RnQ==
X-Gm-Message-State: APjAAAWNEUkgAcfi1W/3H/YcvONuc2MR1MmvpTbZq9GFyUKasgeak2er zdo7kifoA18G/WQ6D0waQD9Fslx3ThjT/RU8GQ3uEg==
X-Google-Smtp-Source: APXvYqzMm+8DuSDu6vOyb/ZV/8a8r5LG9WWo5nuMrj7x+RB2AUGVFK9tYsRcpD8S3AspPfd1bbeFSCGbaCiUbr5i4eo=
X-Received: by 2002:ac2:41c8:: with SMTP id d8mr2936574lfi.65.1578493133147; Wed, 08 Jan 2020 06:18:53 -0800 (PST)
MIME-Version: 1.0
References: <CADyWQ+G1w9_vcU3oO9MsKcP4hTLPXKFb+xY7LJGExbAfjzsDMw@mail.gmail.com> <F8772729-8FF5-4915-AB60-93F41216D3EB@hopcount.ca> <666B2CA4-09F5-4CC3-84F0-73ED4FE3088C@icann.org> <CAH1iCippRTsaZ-hEUQ+mwmh33MD4=+_ADoNK8Ajh9cdiGYJO9A@mail.gmail.com>
In-Reply-To: <CAH1iCippRTsaZ-hEUQ+mwmh33MD4=+_ADoNK8Ajh9cdiGYJO9A@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
Date: Wed, 08 Jan 2020 09:18:41 -0500
Message-ID: <CA+nkc8DyqnkK48-dpCVUBc0eAwo3d0pwj-w1GmUxJLNfLzFD6Q@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007b6365059ba19220"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/q7dyZg7ANhE6Apy53QwVX4IuMZM>
Subject: Re: [DNSOP] [Ext] 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 14:18:58 -0000

On Tue, Jan 7, 2020 at 10:06 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Tue, Jan 7, 2020 at 6:18 PM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
>
>> On Jan 7, 2020, at 6:03 PM, Joe Abley <jabley@hopcount.ca
>> <jabley@hopcount..ca>> wrote:
>> > I don't object to the intended status (standards track). There are
>> reports of multiple independent implementations included in the document,
>> which seems pleasing and proper.
>>
>> Definitely proper. The calls for making this RFC "experimental" go
>> against the definition for that designation in RFC 2026, Section 4.2.1.
>>
>
> While I think the WG list has been rather quiet on this draft, I think it
> is probably best to wait for more responses either way regarding
> "experimental" vs "proposed standard".
>
> (ibid) section 4.1 and 4.1.1 does make reference to the maturity level of
> standards track documents, and includes the possibility of changes or even
> subsequent withdrawal of a standard based on experience.
>
> I concur with Joe, in that the document seems pretty clear, and I support
> moving it forward in the standards track.
>
> My $0.02 on the size issue:
> I think the onus should be on whoever is publishing a zone with a ZONEMD
> to provide guidance on what to do if a failure occurs.
> Similarly, publishers should be sensible on whether to include a ZONEMD
> based on total size and rate of change.
>
> The onus is on operators to operate their infrastructure with appropriate
> levels of caution.
> Blindly turning on processing of ZONEMD on zones from random senders might
> not be wise.
>
> Brian
>

Good point.  Perhaps the RFC should recommend that there be per-zone
options for enabling ZONEMD processing, and perhaps rate limits?

-- 
Bob Harold