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

["Wessels, Duane" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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://secure-web.cisco.com/1BhOfb00VlP-8nUKujrBf7Xdn619jDI_JYiZUqXkRxJrGzti31tg1_lvl6zhDB3k4IUREe6b8Nw3PlWFa0tN3hSEXudysqKd2OxwaaOs0SBHZvEEKVIPc1f-JzrxCn2NAZvke4gWp4K8Nu32aoVdLQKo7SS5PVgHXC9ilgSSqgG_on7pnLuTvHDjYBitnA0fUBIgsOzbVX0tkBue9G06o0C0r80D6EsaK6UoD5cuNz9mUjPZ56TJxzip1UXrfJZ28kGt4MPwe8JIqa4VLKcwz8GqlffyQuXEquiSqih46whY/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> 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
> 
> 
> 
> ----------------------------------------------------------------------
> 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...

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"?



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


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.


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

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.


> 
> 
> ----------------------------------------------------------------------
> 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?

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



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

Okay.


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

Done.

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

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



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

Shall we cite its wikipedia article instead?


> 
> 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?

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.



> 
> Section 2
> 
> 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?

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


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.


> 
> Section 3.3.1
> 
> "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.


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

Okay.


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

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.  


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

How about:

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



> 
>      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?

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.






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

I struggled with this as well.  Open to suggestions.


> 
> Section 6
> 
> 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.


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

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.

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

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.



> 
> 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?

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


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

Fixed.

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

Agreed.

> 
> 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 will make a point to verify them with one of the other implementations.

> 
> (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.)

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.

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

Thanks for the review and comments.

DW