[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)