[DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 06 October 2020 02:47 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BB13A0FA1; Mon, 5 Oct 2020 19:47:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-dns-zone-digest@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <160195246471.4620.11112787341926255318@ietfa.amsl.com>
Date: Mon, 05 Oct 2020 19:47:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Xjk6bGSXs2OWgZOSfh0YcHEXfP0>
Subject: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 06 Oct 2020 02:47:45 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-dns-zone-digest-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 6.1. My read of the text is that the security properties are intended to be independent of the transport protocol. With that assumption and the validation procedures in Section 4, I need help understanding the security properties the client can rely on in the absence of DNSSEC. Consider the following scenarios and attacker types; and the assurances a client could have when retrieving the zone file from the server: With an on-path attacker (and trusted server hosting the zone file) ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO ** No DNSSEC; Secure transport = integrity: YES (from the on-path attacker); authenticity = NO ** DNSSEC = integrity: YES; authenticity = YES With a rogue server hosting the zone file (but is not the operator of the zone) ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO ** No DNSSEC/Secure transport = integrity: NO; authenticity = NO ** DNSSEC = integrity: YES; authenticity = YES The text states that: The zone digest allows the recipient of a zone to verify its integrity. In conjunction with DNSSEC, the recipient can authenticate that it is as published by the zone originator. Can the means to realize integrity without DNSSEC unless there is a reliance on transport security of some form be clarified. Minimally, it seems like this section needs cautionary text (likely with normative language) to the effect of “ZONEMD information from zone files lacking DNSSEC support or that were shared over ‘unsecure transport’ cannot be relied upon for cryptographic integrity assurance.” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). ** Section 1. s/allowing verification of the zone/allowing verification of the integrity of the zone/ ** Section 1.2. In the discussion about alternatives, it seems like the two competing designs are “channel security” vs. “data security”? Is the latter the equivalent to “object security”, a term with which I’m more familiar? That is, the data itself carries a set of security properties independent of the channel or session exchanging it. ** Section 1.3. Clarifying language. OLD As specified herein, the digest is re-calculated over the entire zone content each time NEW As specified herein, the digest is re-calculated over the entire zone content each time the zone is updated. ** Section 1.3. Editorial. The sentence “It is, however, extensible so future schemes to support incremental zone digest algorithms (e.g. using Merkle trees) can be accommodated” didn’t parse for me. ** Section 2. Per the support of multiple ZONEMD RRs, what is meant by “rollovers”? There are no keys here. It seems like multiple ZONEMD would be there for algorithm agility (mentioned) and scheme agility. ** Section 2.0. When multiple ZONEMD RRs are present, each must specify a unique Scheme and Hash Algorithm tuple Would a normative MUST be more appropriate here? ** Section 4. The numbered list calls zones “provably insecure” and “provable secure”. What is the precise definition of those terms. Unless there were formal methods involved, I’d recommend against using those words. ** Section 4. If multiple ZONEMD RRs are present in the zone, e.g., during an algorithm rollover, a match using any one of the recipient's supported Schemes and Hash Algorithms is sufficient to verify the zone. It would likely be worth mentioning in Section 6 that when multiple algorithms are used, the overall security rests with the weakest one. ** Section 5.2 and 5.3 Shouldn’t there be a request for a sub-registry, not a web page? For Section 5.2: OLD IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: NEW IANA is requested to create a new sub-registry in the "Domain Name System (DNS) Parameters" registry as follows: ** Section 5.2. It would likely be helpful to clarify the purpose of the fields (e.g., it wasn’t obvious to me initially that “Implementation Requirement” means MTI)
- [DNSOP] Roman Danyliw's Discuss on draft-ietf-dns… Roman Danyliw via Datatracker
- Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf… Wessels, Duane
- Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw
- Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf… Wessels, Duane
- Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw
- Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf… Wessels, Duane
- Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw