Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Ben Schwartz <bemasc@google.com> Fri, 09 October 2020 19:09 UTC
Return-Path: <bemasc@google.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 D94643A142F for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 12:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fv9FWfmNAPzS for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 12:09:22 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 3CFCC3A1433 for <dnsop@ietf.org>; Fri, 9 Oct 2020 12:09:22 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id k6so11210563ior.2 for <dnsop@ietf.org>; Fri, 09 Oct 2020 12:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LKd3+VPHpVDs6lZbUvMziq1HYtcNUYDH8Wz4hhEzWkQ=; b=qYi/JlndIN8AKwIW9++tA0etYuri7iNLGZHZcrmpd5XCycBH4O1q/xvLXSWJe/dpRn 1nKCp/f1sgFAbtPUikDVPerguOkwtD8txxllyfe6SPACWc2Wtew9Sz6vfzq3PDNLLE6b p3rWun5LOCCkt5CcrWHNsMlzlwqukx3KJ+EGEWI3CC6uhhut5u88TZc8e9jfPYnrGatm Ixxn1reqkDhrUq2E4ddUn8dvepfxtFIe1Gb0fDtWH9MRH63oocQKh9Y4HlPl/VySLk2T 8iZUseiEDdfw/ERU0Z6LBXvb0STDIZQkxc4SUeH/peAvJX9eqwRtBqUOjs4N2cdXm2hM RtBg==
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=LKd3+VPHpVDs6lZbUvMziq1HYtcNUYDH8Wz4hhEzWkQ=; b=j6uG4Q7m4LovTTA6d3aUlS3buMGBlZEq4G1DdVIB2HagUX10mB0M68CDMkqIqsIMwH 8fBESDd3RQ4QEQ96c63nl1CbaVSNuA0CrItzrkb8I5CYDmrvx8paIJbjbRgBvdBs4BEE 6dnCtYSUShXlPuBfoHJmE2K82zHmXODO1dc4UyiCMtEDhFq3F8HNWq2vei1M6LZjusUY tuIwkcrqi8uCYcVITvzHCc6M6I74GMvWB0xjCXJH72NEufbBCKKZMxCWlhh8VAwqeQBM OB4gOum+vhrUiVkaWT5nidm0pnJetjkXDCpx4pTv4qYeR+DvMtK1hD1udG2WGOJdd6yX Amog==
X-Gm-Message-State: AOAM532dARoZLq+s/cBT1S2rVfMwnqO5N3xugowWL7JkopmG2duJLkbJ zJ7zb+BaQoxA+QJKz2nnADsd2QIVAv0Jk8ArUrZJUA==
X-Google-Smtp-Source: ABdhPJwzM0xtQrTiMOU43xADeuwYzmGqTeAJkqh8vBc6FKqeEI/GrQ6m/JtpD//f9tpzv4DV133NCqawp+v3aV6dhr8=
X-Received: by 2002:a6b:9156:: with SMTP id t83mr10020996iod.91.1602270561148; Fri, 09 Oct 2020 12:09:21 -0700 (PDT)
MIME-Version: 1.0
References: <160215590178.19643.8185294724542473578@ietfa.amsl.com> <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com>
In-Reply-To: <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 09 Oct 2020 15:08:35 -0400
Message-ID: <CAHbrMsCxwM_bbu6tO97KkH5rk5DKag5_4FsY3faAbgg=M1-CoQ@mail.gmail.com>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
Cc: Robert Wilton <rwilton@cisco.com>, "draft-ietf-dnsop-dns-zone-digest@ietf.org" <draft-ietf-dnsop-dns-zone-digest@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000a7dd1c05b141afbb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fJI-5O9hyOAgqmebmjy0vpYsd0U>
Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
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: Fri, 09 Oct 2020 19:09:27 -0000
On Fri, Oct 9, 2020, 2:36 PM Wessels, Duane <dwessels= 40verisign.com@dmarc.ietf.org> wrote: > > > > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker < > noreply@ietf.org> wrote: > > > > Robert Wilton has entered the following ballot position for > > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank for you this document. I found it interesting and it looks useful. > > > > I have a few comments that may improve this document for you to please > consider: > > > > Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash > > Algorithm defined for ZONEMD records that MUST be implemented. When > > SHA384 is used, the size of the Digest field is 48 octets. The > > result of the SHA384 digest algorithm MUST NOT be truncated, and the > > entire 48 octet digest is published in the ZONEMD record. > > > > SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for > > ZONEMD records, and SHOULD be implemented. When SHA512 is used, the > > size of the Digest field is 64 octets. The result of the SHA512 > > digest algorithm MUST NOT be truncated, and the entire 64 octet > > digest is published in the ZONEMD record. > > > > For consistency, perhaps change "with value 1" to "with Hash Algorithm > value 1"? > > Done. > > > > > > 2.2.4. The Digest Field > > > > The Digest field MUST NOT be shorter than 12 octets. Digests for > the > > SHA384 and SHA512 hash algorithms specified herein are never > > truncated. Digests for future hash algorithms MAY be truncated, > but > > MUST NOT be truncated to a length that results in less than 96-bits > > (12 octets) of equivalent strength. > > > > When I read this, I wonder why the limit of 12 bytes was chosen. > Possibly a > > sentence that justifies why this value was chosen might be useful, > noting that > > the two suggested algorithms have significantly longer digests. > > > I know there has been some followup on this with Donald. In our earlier > conversations with him he wrote "96 bits seems to be a common minimum > length for disgests in the IETF although perhaps I have that impression > due to the common case of SHA-1 truncated to 96 bits." > > > > > > 2. The ZONEMD Resource Record > > > > It is > > RECOMMENDED that a zone include only one ZONEMD RR, unless the zone > > publisher is in the process of transitioning to a new Scheme or > Hash > > Algorithm. > > > > I'm not quite sure how well this fits with sections 2.2.3 restriction > that > > SHA384 MUST be implemented, and SHA512 SHOULD be implemented. As a > recipient > > of the zone info I understand that I would need to implement both, but > as a > > sender am I allowed to only send SHA512, or both, or must I always send > SHA384? > > As sender (publisher) you are allowed to publish whatever you want. > > The purpose of the recommendation above is to hopefully avoid the situation > where multiple records are published (with both types) on an ongoing basis. > That is something we observe with DS records quite often. For example, > 750 TLDs today publish both SHA1 and SHA256 digest types as DS records in > the root zone. This new paragraph has been added to the security > considerations: > > 6.2. Use of Multiple ZONEMD Hash Algorithms > > When a zone publishes multiple ZONEMD RRs, the overall security is > only as good as the weakest hash algorithm in use. Why not require recipients to verify all digests with recognized algorithms? For this reason, > Section 2 recommends only publishing multiple ZONEMD RRs when > transitioning to a new scheme or hash algorithm. Once the transition > is complete, the old scheme or hash algorithm should be removed from > the ZONEMD RRSet. > > > > > > 3.1. Add ZONEMD Placeholder > > > > In preparation for calculating the zone digest, any existing ZONEMD > > records (and covering RRSIGs) at the zone apex are first deleted. > > > > I think that this places a requirement that all zone digests must be > > constructed at the same time. I suggest at least changing "zone digest" > to > > "zone digest(s)", but it might also be worth adding a sentence to > highlight > > that. > > I've changed it to "zone digest(s)" as you suggest. > > Strictly speaking, there is not a requirement that all digests must be > created > at the same time (in parallel). > > The reason for the placeholder is explained in the next paragraph, which > is to > ensure correct NSEC/NSEC3 records when the zone is signed with DNSSEC. > > > > > > I was also left wondering whether it is strictly required that the zone > digests > > must be deleted, or just that placeholder zone digests must be used in > their > > place during the calculation. E.g. what happens if a request is > received to > > fetch the ZONEMD record at the same time that it is being reconstructed? > > It is not strictly required to delete any existing digest first. The > ZONEMD records > are not included in the digest calculation. > > To address your questions around this, I suggest adding this text to > section 3, > before section 3.1: > > 3. Calculating the Digest > > The algorithm described in this section is designed for the common > case of offline DNSSEC signing. Slight deviations may be permitted > or necessary in other situations, such as with unsigned zones or > online DNSSEC signing. Implementations that deviate from the > described algorithm are advised to ensure that identical ZONEMD RRs, > signatures, and dential-of-existence records are produced. > > > > > 4. Verifying Zone Digest > > > > 5. Loop over all apex ZONEMD RRs and perform the following steps: > > > > ... > > > > My, perhaps mistaken, interpretation of these error reporting > instructions in > > this loop is that they really assume only a single ZONEMD RR. I.e., I > wouldn't > > expect the recipient to generate/return these errors if there were two > ZONEMD > > RR's and only one scheme/algorithm was was supported. Yes, there is > some text > > at the beginning of the entire algorithm that suggests what to do here, > but > > further guidance here may also be helpful. E.g. what does the server > return if > > there are two ZONEMD records and neither of them are acceptable for > different > > reasons? I'm presuming, perhaps incorrectly, that only a single error > > can/should be returned. > > Ben raised a similar point about this section, namely that it could result > in a lot of diagnostic output. > > Do you think it would be better remove those "SHOULD report" from each > individual > step and instead have a paragraph at the end that says the verifier SHOULD > report > the result of its verification and leave it at that? > > > > > > Regards, > > Rob > > > > Thanks for the review and comments! > > DW > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- [DNSOP] Robert Wilton's No Objection on draft-iet… Robert Wilton via Datatracker
- Re: [DNSOP] Robert Wilton's No Objection on draft… Donald Eastlake
- Re: [DNSOP] Robert Wilton's No Objection on draft… Rob Wilton (rwilton)
- Re: [DNSOP] Robert Wilton's No Objection on draft… Wessels, Duane
- Re: [DNSOP] Robert Wilton's No Objection on draft… Ben Schwartz
- Re: [DNSOP] Robert Wilton's No Objection on draft… Wessels, Duane
- Re: [DNSOP] Robert Wilton's No Objection on draft… Donald Eastlake
- Re: [DNSOP] Robert Wilton's No Objection on draft… Benjamin Kaduk
- Re: [DNSOP] Robert Wilton's No Objection on draft… John Levine
- Re: [DNSOP] Robert Wilton's No Objection on draft… Benjamin Kaduk
- Re: [DNSOP] Robert Wilton's No Objection on draft… Benjamin Kaduk
- Re: [DNSOP] Robert Wilton's No Objection on draft… Rob Wilton (rwilton)
- Re: [DNSOP] Robert Wilton's No Objection on draft… Rob Wilton (rwilton)
- Re: [DNSOP] Robert Wilton's No Objection on draft… Wessels, Duane
- Re: [DNSOP] Robert Wilton's No Objection on draft… Rob Wilton (rwilton)
- Re: [DNSOP] Robert Wilton's No Objection on draft… Wessels, Duane