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

Joe Abley <jabley@hopcount.ca> Thu, 08 August 2019 16:49 UTC

Return-Path: <jabley@hopcount.ca>
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 3696E12022B for <dnsop@ietfa.amsl.com>; Thu, 8 Aug 2019 09:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=hopcount.ca
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 Rln8dk3hkB7R for <dnsop@ietfa.amsl.com>; Thu, 8 Aug 2019 09:49:36 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 044E2120229 for <dnsop@ietf.org>; Thu, 8 Aug 2019 09:49:34 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id x21so27972908otq.12 for <dnsop@ietf.org>; Thu, 08 Aug 2019 09:49:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2taoWxfGV7v2wxtviDTJy3cGOZNFOAEeklnECSOLlKQ=; b=Fs7zWjqtYyZDyrxSBPG+vwerG0/f+qQU0MxttqFRG5rpBiMoBY/PT042s3rrUkjey7 8Hkb4Mu446SsCV/GvWU1yD7GP8sihj8YOYYYAa2xEUFNJrzfhhRDx9ozVBRSAz5IVtcw vWWir8Tlx09uR80WJK5yA26B/88T+nhL8W4CM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2taoWxfGV7v2wxtviDTJy3cGOZNFOAEeklnECSOLlKQ=; b=iLbH3Uzxm89vNDC9sjSHnQaVR6orAPzDcSQzCpaZ1c3dQ26txL7VAJWD+AJmzMjmhk NQ8EdcLU1hJ5ZlpyyIY/0qJ5NsuktIvhCwB2UNVy4ug2wTI77T7bIwP5Tszbth56hNCg VstbqhzUzxjDLaF5M4YesR7aMSK2hm5GgG/uKunxvB1891T+GqMZTQ8NYXydb63gmZQQ uKeVS6rfzPP5fEjuEAUmuX19MDvYctNMl5JxvfRnB1kTxIxXqCD8cWYTz5AIvgFV4Clf QCRTupoJmgDvuR1mi6sNyiwlJ4cWxgiLpUN47E9JBMVBLLDNdQ2qkA/tHzU/CyoKKBK8 Usyw==
X-Gm-Message-State: APjAAAXBrmxFHfsB4vzgsihv1wOL8mPQ9h4KJYdW4gRW1utTcRgK7IAd KGWEt2iSGDRUTuw14ZcRDIPqcg==
X-Google-Smtp-Source: APXvYqwReXGnTZFWywqhk8pDGMmrmxBTtuI2eoU3sSRqTrO9T5u8+Nv0AXpI4qEckvQpU8PaGZ0A2w==
X-Received: by 2002:a05:6602:104:: with SMTP id s4mr16226776iot.200.1565282973140; Thu, 08 Aug 2019 09:49:33 -0700 (PDT)
Received: from [192.168.1.50] (24-246-23-138.cable.teksavvy.com. [24.246.23.138]) by smtp.gmail.com with ESMTPSA id j14sm78900692ioa.78.2019.08.08.09.49.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Aug 2019 09:49:31 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <9EFB92DB-CB48-447C-BDF9-4783E9A86D4E@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_22011958-3799-4E21-8538-8703288FF01A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 8 Aug 2019 12:49:29 -0400
In-Reply-To: <BD673DE3-C27D-4BD7-8A52-2146F6D65FD7@verisign.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
References: <156135988131.17726.12457283360064863692@ietfa.amsl.com> <8EF45B1E-1F80-49CA-97E8-0E7DE497A313@verisign.com> <BD673DE3-C27D-4BD7-8A52-2146F6D65FD7@verisign.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2aczgkSBvEcw0wCIpNx5w0mHkoI>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-00.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: Thu, 08 Aug 2019 16:49:39 -0000

Hi Duane,

On 7 Aug 2019, at 19:29, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org>; wrote:

> AFAICT there was no feedback received after this most recent version of the ZONEMD draft was posted.  As I mentioned before, there was one pretty significant change in that version:
> 
>> The most significant change is that multiple ZONEMD records are allowed.  The document recommends that multiple digests be present only when transitioning to a new digest type algorithm and has this to say about verification given multiple digests:
>> 
>> 4.1.  Verifying Multiple Digests
>> 
>>  If multiple digests are present in the zone, e.g., during an
>>  algorithm rollover, at least one of the recipient's supported Digest
>>  Type algorithms MUST verify the zone.
>> 
>>  It is RECOMMENDED that implementations maintain a (possibly
>>  configurable) list of supported Digest Type algorithms ranked from
>>  most to least preferred.  It is further RECOMMENDED that recipients
>>  use only their most preferred algorithm that is present in the zone
>>  for digest verification.
>> 
>>  As a matter of local policy, the recipient MAY require that all
>>  supported and present Digest Type algorithms verify the zone.
> 
> 
> We would like to have feedback on this change before progressing to working group last call.

My suggestion is to focus on what is necessary for interop in the protocol and leave implementation decisions about the richness of local policy that can be configured to implementations. I don't think the RECOMMENDED paragraph is necessary (perhaps I'm missing something) and I think the final MAY paragraph is implicit and doesn't need to be spelled out. So my preference would be:

OLD:

4.1.  Verifying Multiple Digests

 If multiple digests are present in the zone, e.g., during an
 algorithm rollover, at least one of the recipient's supported Digest
 Type algorithms MUST verify the zone.

 It is RECOMMENDED that implementations maintain a (possibly
 configurable) list of supported Digest Type algorithms ranked from
 most to least preferred.  It is further RECOMMENDED that recipients
 use only their most preferred algorithm that is present in the zone
 for digest verification.

 As a matter of local policy, the recipient MAY require that all
 supported and present Digest Type algorithms verify the zone.

NEW:

4.1.  Verifying Multiple Digests

 If multiple digests are present in the zone, e.g., during an
 algorithm rollover, at least one of the recipient's supported Digest
 Type algorithms MUST verify the zone.

However, I don't think the two paragraphs I just casually removed do any harm, and I would not object if they were kept in.


Joe