[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 06 October 2020 17:41 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 9C1813A0E75; Tue, 6 Oct 2020 10:41:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk 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: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160200606961.32445.15470555113695796820@ietfa.amsl.com>
Date: Tue, 06 Oct 2020 10:41:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DGD4bbdtXJgVnjQbt9OPrf4Uz30>
Subject: [DNSOP] Benjamin Kaduk'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 17:41:10 -0000

Benjamin Kaduk 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:
----------------------------------------------------------------------

Inclusion of an "implementation requirement" column in the IANA
registries implies a need for a defined procedure to make changes to
existing registrations.  With only a "specification required" procedure,
it seems there would need to be a "change controller" column as well.
Furthermore, is it expected that anyone with any specification could
set, e.g., an implementation requirement of "MUST"?  It seems like this
attribute might be better left for the RFCs defining the protocol, to be
modified by an updating RFC...

If we are to retain the Implementation Status appendix in the final RFC,
the boilerplate will need some changes, and I think those changes should
get review prior to AUTH48.  For example, "at the time of posting of
this Internet-Draft" will make no sense in an RFC, and the relationship
to RFC 7942 is not quite as clear given that we diverge from its
recommendations.  "[A]ssist the IETF in its decision process" does not
seem to apply after the IETF has made its decision, though the
disclaimer about endorsement seems highly important to retain.

This seems to be related to Roman's Discuss point, but the document
seems to be inconsistent as to the primary purpose of the mechanism --
Section 1.1 says that it is to verify "authenticity" of a stand-alone
zone, whereas the Introduction implies that "integrity" is primary (with
authenticity as an add-on "when used in combination with DNSSEC), and
the Abstract refers to "accuracy and completeness".  In particular, it
is easy to read references to "integrity" (and, indeed, the Abstract
itself) as referring to something akin to a transport checksum instead
of a cryptographic message integrity code.  I think the document needs
to be much more clear, and consistent, about what properties it aims to
provide.  (I do not believe that the "authenticity" property can be
provided without DNSSEC, and Roman covers the cryptographic integrity
case in his ballot position.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.2

   The Transport Layer Security protocol suite also provides channel
   security.  One can easily imagine the distribution of zones over
   HTTPS-enabled web servers, as well as DNS-over-HTTPS [RFC8484], and
   perhaps even a future version of DNS-over-TLS ([RFC7858]).

I'm not sure I understand why a "future version" of DoT is needed --
while 7858 disclaims applicability outside of stub-to-recursive, is it
know whether/what protocol changes would be needed, if any, to
effectuate zone transfer?

Section 1.2

   been modified.  Such modification could be the result of an
   accidental corruption of the file, or perhaps an incompletely saved
   file [disk-full-failure].  For these reasons, it is preferable to
   secure the data itself.

"secure" is kind-of a catchall word; it would be better to use a more
precise term if possible, perhaps "protect the integrity of".

   DNSSEC.  Furthermore, zones that employ NSEC3 with opt-out are
   susceptible to the removal or addition of names between the signed
   nodes.  Whereas DNSSEC is primarily protects consumers of DNS

(nit) an RFC 5155 reference might be helpful here.

Section 1.4.2

While I'm sure this is all true, I do wonder if there are any references
available that go into more detail about the various possible setups and
the problems that can arise with them.

Section 1.4.3

RPZ is an individual draft that expired in 2018.  Is the reference
likely to have archival value?

Secion 1.4.4

   ICANN operates the Centralized Zone Data Service [CZDS], which is a
   repository of top-level domain zone files.  Users that have been
   granted access are then able to download zone data.  Adding a zone
   digest to these would provide CZDS users with assurances that the
   data has not been modified between origination and retrieval.  ZONEMD
   could be added to CZDS zone data independently of the zone served by
   production name servers.

I'm not entirely sure that I understand the relationship between the
last two sentences.  Giving (cryptographic) assurance of integrity
between origination and retrieval requires that the ZONEMD be generated
by the same entity doing the origination.  Yet "added to the CZDS zone
data independently of the zone served by the production name servers"
seems to imply that there is a different entity adding ZONEMD than
originating the data, which seems to contradict the previous statement.
Is the intent just to say that the ZONEMD generation does not need to
occur in-band with the production service even though it is managed by
the same entity?

Section 2

It may be better to reference RFC 7696 as BCP 201 directly.

Section 3.1

If the ZONEMD contents other than digest (i.e., serial, scheme and hash
algorithm) were included in the digest calculation, there are some
classes of cross-algorithm attacks that would be made harder.  That
said, it is not entirely clear whether there will be cases where more
than one digest with the same output size is defined, which is a
prerequisite for this sort of cross-algorithm attack, so the risk from
leaving things as-is is probably tolerable, and furthermore so since
DNSSEC does protect these fields, and we seem to be strongly encouraging
use of DNSSEC (see Roman's ballot position).  (I assume that, given that
the codepoint was allocated almost two years ago, this is already
deployed and thus gratuitous wire-visible changes are ill-advised.)

Section 3.3.1

"REQUIRES" is not a BCP 14 keyword.

Section 3.3.1.1

   o  All records in the zone, including glue records, MUST be included.

I suggest adding "unless excluded by a subsequent rule", so that this
directive is not in conflict with all the subsequent exclusion rules.

   o  If the zone is signed, DNSSEC RRs MUST be included, except:

If the zone is not signed, there would not be any DNSSEC RRs to worry
about, would there?  It is not entirely clear to me how much value is
added by this statement, that seems to just be repeating a subset of
"all records in the zone ... MUST be included".

Section 4

   1.  The verifier MUST first determine whether or not to expect DNSSEC
       records in the zone.  This is done by examining locally
       configured trust anchors, or querying for (and validating) DS RRs
       in the parent zone.  [...]

This procedure is a bit puzzling to me.
Finding valid DS RRs in the parent zone, of course, makes sense, but
"examining locally configured trust anchors" I am less sure about.  When
would one trust anchor but not another imply that DNSSEC records should
be expected?  It seems to only be possible when there is additional
metadata associated with locally configured trust anchors (not just the
key material themself, but what zone it is associated with).  Only if
there is a configured trust anchor for the zone in question or a
(possibly indirect) parent does querying for and validating the DS
records make sense.  So these two checks are not independent (as the
"or" would imply) but rather, the latter is dependent on the former.

       A.  The SOA Serial field MUST exactly match the ZONEMD Serial
           field.  If the fields do not match, digest verification MUST
           NOT be considered successful with this ZONEMD RR.

This step is occurring after ZONEMD RRSIG verification, so such a
mismatch would seem to indicate misconfiguration on the signer.  Is it
wise to proceed at all (by just skipping this RR) vs considering
verification to have failed?

       B.  The Scheme field MUST be checked.  If the verifier does not
           support the given scheme, verification MUST NOT be considered
           successful with this ZONEMD RR and it SHOULD report that the
           RR's digest could not be verified due to an unsupported
           scheme.

This seems to be setting us up for lots of diagnostic spew whenever
anyone starts publishing with a new scheme (or hash algorithm).  Is the
best condition for reporting that an unknown codepoint exists, or that
verification failed overall and there was an unknown codepoint?  (It
would also feel a bit odd to report that the RR's digest could not be
verified for a particular reason if/when the diget was actually verified
just using a different scheme/hash-algorithm.)

Section 6

Is there anything interesting to say about split-horizon DNS?

Section 6.1

I suggest calling out more explicitly that "modifying the Digest field
of the ZONEMD record" allows the attacker to make any zone contents
appear to be valid (in the absence of DNSSEC validation).

Some discussion of "cryptographic attacks only get better" and the
expected need to implement algorithm agility on long timescales might
also be appropriate here (I do see that we referenced RFC 7696 earlier
already).

Section 6.2

In security considerations, I'm used to "timing considerations"
referring to time-based side-channel attacks, so it was slightly
surprising to read on and discover that this is just the blunt
progression of wall-clock time and signature expiration.  Would
"Time-Related Considerations" work?

I think it might be worth adding a note that a consumer of ZONEMD might
have some way of locally indicating that DNSSEC validation of a given
ZONEMD record was performed successfully, so that the zone digest might
still be used even if the signature is no longer validatable at some
later point in time.  On the other hand, this local indication would
also potentially be subject to attacks, so perhaps the extra complexity
of discussing those risks is not worth it.

Section 6.4

I like that this was explicitly framed as a tradeoff.

Section 9

   Wouters, and other members of the DNS working group for their input.

"DNS" seems to be a concluded working group (but "DNSOP" is currently
active).

Section 11.2

We seem to use RFC 5936 as the reference for "occluded data", which
appears as part of "occluded data MUST be included" (§3.3.1.1).  It's
not really clear to me that the MUST implies you have to read the
reference to know what occluded data is, so I don't see a huge need to
move this reference to the normative section.

Appendix A

I trust that the digests in the ZONEMD records have been validated for
all the examples (it's a bit more complicated than I want to set up from
scratch, myself).  I do appreciate the variety of examples and their
utility as unit tests ("I'm occluded but must be digested", "I must be
digested just once", etc.)!

(I am a bit curious if the private-use hash algorithm 241 in A.3 is
SHA-1, though ... not too many choices for native 20-octet output,
though I suppose it could be truncated.)

Appendix A.4, A.5

[Sometimes I ask people to update the examples to use times closer to the
time of publication.  This is not one of those times; these examples
seem to stand just fine as-is.]