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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 06 Oct 2020 10:41:09 -0700

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.]

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 7 Oct 2020 19:59:54 +0000

Hi Benjamin, thanks for the extensive review and comments.  Responses are
inline.  As you've noted some of this overlaps with Roman's comments as
well.

> On Oct 6, 2020, at 10:41 AM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> Please refer to https://secure-web.cisco.com/1BhOfb00VlP-8nUKujrBf7Xdn619jDI_JYiZUqXkRxJrGzti31tg1_lvl6zhDB3k4IUREe6b8Nw3PlWFa0tN3hSEXudysqKd2OxwaaOs0SBHZvEEKVIPc1f-JzrxCn2NAZvke4gWp4K8Nu32aoVdLQKo7SS5PVgHXC9ilgSSqgG_on7pnLuTvHDjYBitnA0fUBIgsOzbVX0tkBue9G06o0C0r80D6EsaK6UoD5cuNz9mUjPZ56TJxzip1UXrfJZ28kGt4MPwe8JIqa4VLKcwz8GqlffyQuXEquiSqih46whY/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> https://secure-web.cisco.com/1xe5afi0q1U9T8XBGtR5t0vEYlrnzaadCkXqE09yMZj4z0tASslenLfkLmcnAJ7Mh9GZqXJwg_vPKpS0X4wUosrcy_CVVGV42vwFrwqpNkm-3ukWQWroGS3v0hj84_EQOKGAHQG7X87FSo9kCMC4VX43uHk4s9tUi1QT-f1gd4kngZnItz73If8TdNzt_dLWdlpOjGkd1YSMOMD9ZAitEfs_X25RrGQdC2vFNdrGXdbChufVU8h4Ex2uZCVCakgPLhbPUKXVdXDkZ5JCPHireHA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
> 
> 
> 

To be honest, I feel like the "implementation requirement" column is a
bit of a can-of-worms.  I have a hard time finding other IANA registries
that use it.  Would it be better to omit this from the registry?

If not, would it be sufficient to say something like "all specifications
requesting an allocation must have the implementation requirement set to
MAY unless being published on the standards track"?

> disclaimer about endorsement seems highly important to retain.

Is this okay?

  RFC Editor: Please retain this section upon publication.

  This section records the status of known implementations of the
  protocol defined by this specification, and is inspired by the
  concepts described in RFC7942.

  Please note that the listing of any individual implementation here
  does not imply endorsement by the IETF.  Furthermore, no effort has
  been spent to verify the information presented here that was supplied
  by IETF contributors.  This is not intended as, and must not be
  construed to be, a catalog of available implementations or their
  features.  Readers are advised to note that other implementations may
  exist.

> case in his ballot position.)

Thanks for pointing this out. Here's some diff showing changes to address
this:

-        that provides a cryptographic message digest over DNS zone data.
+        that provides a cryptographic message digest over DNS zone data at rest.

-        can verify the zone contents for accuracy and completeness.
+        can verify the zone contents for integrity and, when signed with DNSSEC, origin authenticity.

-        Currently there is no standard way to verify the integrity and authenticity
+        Currently there is no standard way to verify the integrity and origin authenticity

-          to verify the authenticity of a stand-alone zone,
+          to verify the data integrity and origin authenticity of a stand-alone zone,
          regardless of how it is transmitted.  A consumer of zone data
-          should be able to verify that the data is as-published by the
-          zone operator.
+          should be able to verify that it is as-published by the
+          zone operator.  Authenticity can only be assured when the zone
+          is signed with DNSSEC.

It was an oblique reference to draft-ietf-dprive-xfr-over-tls.  Updated the
text to read:

  The Transport Layer Security protocol suite also provides channel
  security.  The DPRIVE working group is in the process of specifying
  DNS Zone Transfer-over-TLS [I-D.ietf-dprive-xfr-over-tls].  One can
  also easily imagine the distribution of zones over HTTPS-enabled web
  servers, as well as DNS-over-HTTPS [RFC8484].

> precise term if possible, perhaps "protect the integrity of".

Okay.

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

Done.

> the problems that can arise with them.

How about RFC 3258 (anycast) and RFC 8901 (multi-signer DNSSEC)?

  However,
  modern DNS service has complex provisioning which includes multiple
  third-party providers ([RFC8901]) and hundreds of anycast instances
  ([RFC3258]).  

> likely to have archival value?

Shall we cite its wikipedia article instead?

> occur in-band with the production service even though it is managed by

The thought here is that some zones in CZDS might have properties, such
as their size and update frequency, that make SIMPLE ZONEMD impractical
for use on production name servers. 

However, the zone operator could still do a one-time "offline" ZONEMD
digest calculation for the one time per day that they transmit a zone
file to CZDS.

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

Maybe we can do this in the RFC editing step?  I'm using xml2rfc  
but it doesn't seem to support BCP references / entities?

> deployed and thus gratuitous wire-visible changes are ill-advised.)

Earlier versions of the draft did include those fields in the digest, but
with working group consensus we changed it.  I can say that it really
simplified the implementation, which I think is a good thing.

Perhaps too much detail, but the original design was to include the
non-digest fields of all ZONEMD RRs into all digests.  The current design
is to exclude all ZONEMD RRs from all digests.  There is a middle ground
option that was never really considered, which would be for each digest
to include its own RR non-digest fields, but entirely omit other ZONEMD
RRs.  I'm not sure if that middle ground option addresses the attack you
are referring to, but I'm guessing not.

I wouldn't say ZONEMD is already deployed in a way that would make it a
problem to revert.  But I still wouldn't advocate for including the
non-digest fields in the digest calculation.

> "REQUIRES" is not a BCP 14 keyword.

Yet it still seems to sneak in to recent RFCs?  If this is a strict rule
we can reword it.

> directive is not in conflict with all the subsequent exclusion rules.

Okay.

> "all records in the zone ... MUST be included".

IMO it is better to be very explicit here and it makes sense to have this
rule given the following rule to exclude the ZONEMD signature.  

> "or" would imply) but rather, the latter is dependent on the former.

How about:

  ... examining locally configured trust anchors, and, if necessary,
  querying for ...

> verification to have failed?

The scenario is that we have a zone, signed with DNSSEC and at least one
ZONEMD RR.  If we get to this step 5A and the ZONEMD and SOA serial numbers
don't match, then the question is do we fail verification right there or
do we continue looping through any remaining ZONEMDs and possibly have a
successful verification?

If there is just one ZONEMD RR then its equivalent to failing entirely.
So we're really interested in the case when there are multiple ZONEMDs.
Note they would also need unique hash,scheme tuples or else they would be
rejected at step 4.

If we have two ZONEMDs and the first has a wrong serial number but the
second has the correct serial, then do we still trust the second digest?
I'd agree its a bug or misconfiguration with the signer/publisher, but
I'm not sure it means the second digest is invalid.

As a practical matter, failing entirely for a wrong serial would probably
require changing the algorithm to do 5A for all ZONEMD RRs before proceeding
to 5B, otherwise the behavior depends on the order in which ZONEMD RRs are
processed.

> just using a different scheme/hash-algorithm.)

I struggled with this as well.  Open to suggestions.

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

I don't believe so.  Split DNS or views generally operates on a 
per-query basis.  I'd say in such a situation the two (or more)
views are really separate zones (with the same origin).  I don't
think that ZONEMD creates any additional problems that don't already
exist with split DNS.

> appear to be valid (in the absence of DNSSEC validation).

How about this:

 For zones not signed with DNSSEC, an attacker can make any zone modifications
 appear to be valid by recomputing the Digest field of a ZONEMD RR.

> also be appropriate here (I do see that we referenced RFC 7696 earlier

How about this:

  As stated in [RFC7696], cryptographic algorithms age and become
  weaker as cryptanalysis techniques and computing resources improve
  with time.  Implementors and publishers of zone digests should
  anticipate the need for algorithm agility on long timescales.

> "Time-Related Considerations" work?

Well, the title of RFC 7583 is "DNSSEC Key Rollover Timing Considerations".

> "DNS" seems to be a concluded working group (but "DNSOP" is currently

Fixed.

> move this reference to the normative section.

Agreed.

> digested just once", etc.)!

I will make a point to verify them with one of the other implementations.

> though I suppose it could be truncated.)

Its possible, but that detail has been lost to time.  There was a time where
my implementation did support SHA1, so I may have taken it from there.

> seem to stand just fine as-is.]

Thanks for the review and comments.

DW

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Oct 2020 20:27:32 -0700

Hi Duane,

> that use it.  Would it be better to omit this from the registry?

In my opinion, yes!

There's a pretty strong argument that changing implementation requirements
is placing requirements on implementations with a similar level of
authority to actual protocol changes, and thus that just having the
implementation requirements in an RFC that gets updated as needed makes
more sense.  See, e.g., RFC 8247 (which obsoletes 4307)

>   protocol defined by this specification, and is inspired by the

We probably do want to keep something about "time of publication" (just not
talk about Internet-Drafts).

>   features.  Readers are advised to note that other implementations may

But it seems otherwise unobjectionable to me.  (Hopefully we can get some
voices from the WG to chime in as well.)
There is perhaps some question about whether it should get another IETF LC,
but Barry and probably the rest of the IESG should be part of that
conversation.

> +          zone operator.  Authenticity can only be assured when the zone

Those all look promising, but I'll want to make another look over the text
as a whole with context.  I do like the direction you picked, though :)

>   servers, as well as DNS-over-HTTPS [RFC8484].

Thanks!

>   third-party providers ([RFC8901]) and hundreds of anycast instances

Thanks, that helps to paint a fuller picture.

> Shall we cite its wikipedia article instead?

It might age better, though either reference is fine, really -- I honestly
wasn't sure whether it was still in use.  (I know, I know, people do use
things not made by the IETF...)

> digest calculation for the one time per day that they transmit a zone

Ah, I see, and that makes perfect sense.

Perhaps the last sentence as something like "Note that ZONEMD can be
supplied to the CZDS system without requiring it to always be present in
the zone served by the production name servers, since the ZONEMD is
inherently attached to the specific copy of the zone in question" is
better?  (The last clause optional, but may serve to reinforce the "data at
rest" protection that is the goal.)

> but it doesn't seem to support BCP references / entities?

Definitely.  I am about 60% sure that the production staff will offer to do
this by default, anyway :)

> simplified the implementation, which I think is a good thing.

Simpler implementations do tend to be more secure in practice (provided
that they function at all), so I heartily sympathize.

> RRs.  I'm not sure if that middle ground option addresses the attack you

I dunno, that sounds like it would be even more complicated to implement...

> are referring to, but I'm guessing not.

I think it would prevent the attack I had in mind, actually.

> non-digest fields in the digest calculation.

Okay.  Thanks for talking it through (again, since I missed the first time).

> Yet it still seems to sneak in to recent RFCs?  If this is a strict rule

I am not going to be a stickler about it, at least today, though on second
look it seems that this is just a statement of fact, so the lowercase form
would be fine here.

>   ... examining locally configured trust anchors, and, if necessary,

That seems to work, thanks.

> I'm not sure it means the second digest is invalid.

There's not a clear answer, sure.  Though given that B/C/D talk about
reporting failing checks, that might be the right thing to do here (e.g.,
report if one serial mismatches but you are able to proceed -- an overall
failure would of course be reported in its own right).

> to 5B, otherwise the behavior depends on the order in which ZONEMD RRs are

A good point.

> I struggled with this as well.  Open to suggestions.

It seems that the interesting part is that a new scheme was seen at all,
and not necessarily the specific zone on which it was seen -- if it's
"real" then the operator will have to upgrade to software that support it
(or decide they don't care).  Perhaps "SHOULD report the unsupported scheme
that was encountered, subject to appropriate rate limits"?
But it's certainly fine to leave this unchanged as well.

> think that ZONEMD creates any additional problems that don't already

Okay, thanks for giving it a think.

>  appear to be valid by recomputing the Digest field of a ZONEMD RR.

Exactly!

>   anticipate the need for algorithm agility on long timescales.

+1

> Well, the title of RFC 7583 is "DNSSEC Key Rollover Timing Considerations".

You got me -- I missed that part.

> Thanks for the review and comments.

Thanks for the updates and education!

-Ben