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

[Benjamin Kaduk <[e-mail]>]

Hi Duane,

On Wed, Oct 07, 2020 at 07:59:54PM +0000, Wessels, Duane wrote:
> 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:
> > 
> > ----------------------------------------------------------------------
> > 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?

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)

> 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

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

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

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.


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

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

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

Thanks!

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

Thanks, that helps to paint a fuller picture.

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

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

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

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

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

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

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

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

> 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

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.

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

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

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

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.

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

That seems to work, thanks.

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

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

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

A good point.

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

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.

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

Okay, thanks for giving it a think.

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

Exactly!

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

+1

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

You got me -- I missed that part.

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

Thanks for the updates and education!

-Ben