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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 05 Oct 2020 19:47:44 -0700

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)

---

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

Hi Roman, thanks for the detailed review and comments.  My responses are inline.

> On Oct 5, 2020, at 7:47 PM, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 
> Please refer to https://secure-web.cisco.com/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLwmmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L-eKHO_l_zDzfiAHtMP8zHJQ_7GCF6YPn4OTvYHtKq1TL85oSNMxkc-a9TwIaBuzcEx2aRPzSqAPypDs7bIbFPs/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> https://secure-web.cisco.com/1In2W1aOUrhepme0YYTCWi_KVrjzwPz6gRHK3wqiBh8JhXsVPR-caNTg-liKbKCksx5Y35akHQwb5BB41XUadJT3by_ZmHTxwdiSU3QpC4eNTBAE42Pw2mywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsjsae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm4JcgBjaAU2ABRPZ-bfBv0LsmZR0Q/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
> 
> 
> 

You are correct that we intend the security properties to be independent of
any transport protocol.   I'm reluctant to suggest in this document that
a recipient could rely on ZONEMD for integrity because it came over a secure
transport.  Although that might be true, I have to think that the secure
transport itself provides the integrity assurance, and not the ZONEMD record.

The sentence preceding this one talks about verifying both integrity and
authenticity (given DNSSEC).  I'm not sure why you want to focus on just
integrity here in this sentence?

> channel or session exchanging it.

Yes, data security means the same thing as object security.

>  entire zone content each time the zone is updated.

Okay.

> can be accommodated” didn’t parse for me.

How about this :

 It is, however, extensible, so that future schemes may be defined to support
 efficient incremental digest updates.

> there for algorithm agility (mentioned) and scheme agility.

The document uses "rollover" in the same way that in DNSSEC we talk about
algorithm rollovers, but agreed it is unnecessary here to mention both
rollover and agility, so I will remove "and rollovers".

> Would a normative MUST be more appropriate here?

Fine with me.

> formal methods involved, I’d recommend against using those words.

The terms Secure, Insecure, and Bogus are defined in RFC 4033 (DNSSEC
Security Introduction and Requirements).  So probably those terms should
be capitalized here.  Do you think it should be "proven to be Secure" or
"provably Secure" or just "Secure" or something else?

> are used, the overall security rests with the weakest one.

How about this?

6.2.  Use of Multiple ZONEMD Hash Algorithms

  When a zone publishes multiple ZONEMD RRs, the overall security is
  only as good as the weakest hash algorithm in use.  For this reason,
  Section 2 recommends only publishing multiple ZONEMD RRs when
  transitioning to a new scheme or hash algorithm.  Once the transition
  is complete, the old scheme or hash algorithm should be removed from
  the ZONEMD RRSet.

>  (DNS) Parameters" registry as follows:

I think "registry" is correct but I defer to IANA.  In the case of DNS parameters
there are a number of different registries all on the same "page".

> fields (e.g., it wasn’t obvious to me initially that “Implementation

The column labeled "Implementation Requirement" seems to be causing a lot
of confusion and I'm having a hard time finding examples of other protocol
registries that have something like that.  Maybe we should just remove it?

DW

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 7 Oct 2020 20:52:06 +0000

Hi Duane,

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Wessels, Duane
> Sent: Wednesday, October 7, 2020 3:55 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; Tim Wicinski
> <[email-masked]>; [email-masked]; [email-masked]; The IESG
> <[email-masked]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12:
> (with DISCUSS and COMMENT)
> 
> > Please refer to https://secure-
> web.cisco.com/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLw
> mmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84
> DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ
> 9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L-
> eKHO_l_zDzfiAHtMP8zHJQ_7GCF6YPn4OTvYHtKq1TL85oSNMxkc-
> a9TwIaBuzcEx2aRPzSqAPypDs7bIbFPs/https%3A%2F%2Fwww.ietf.org%2Fiesg%
> 2Fstatement%2Fdiscuss-criteria.html
> > https://secure-
> web.cisco.com/1In2W1aOUrhepme0YYTCWi_KVrjzwPz6gRHK3wqiBh8JhXsVPR-
> caNTg-
> liKbKCksx5Y35akHQwb5BB41XUadJT3by_ZmHTxwdiSU3QpC4eNTBAE42Pw2m
> ywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsj
> sae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm
> 4JcgBjaAU2ABRPZ-
> bfBv0LsmZR0Q/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-
> dnsop-dns-zone-digest%2F
> >
> >
> >

In that case (where no assumptions are made about the transport), it seems that only these scenarios from the list above apply:

** No DNSSEC  = integrity: NO; authenticity = NO
** DNSSEC = integrity: YES; authenticity = YES

** No DNSSEC = integrity: NO; authenticity = NO
** DNSSEC = integrity: YES; authenticity = YES

Or more succinctly, without DNSSEC, the two stated security properties aren't provided.  

I'm not sure of what the best way is to resolve this mismatch based on the use cases.  I can see (at least) two paths to resolution:

(1) Specify that ZONEMD records MUST only be used with DNSSEC -- this will preserve the authenticity and integrity properties described in Section 1.1. and 6.  An additional step or two might be needed to the verification process in Section 4.  Does this impact the planned use cases or workflows?

(2) Provide appropriate caveats that ZONEMD information may not mean what you think it means depending on whether DNSSEC is used.  This likely means: the motivational goal in Section 1.1 may need to be weakened; the analysis of alternatives in Section 1.2 won't make sense (for the non-DNSSEC case); and an appropriate applicability-like statement might also be necessary to describe how to use an insecure checksum.  Section 6 would needs additional language to capture the difference between the DNSSEC vs. non-DNSSEC deployment.  Editorially, clearer words like checksum might also help.

[trimmed all of the COMMENT discussion for now]

Regards,
Roman

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 9 Oct 2020 18:40:01 +0000

> On Oct 7, 2020, at 1:52 PM, Roman Danyliw <[email-masked]> wrote:
> 
> 

Thanks Roman, I see your point.  With the help of my coauthors we have made some edits that I think will address your concerns. 
Rather than try to include them all here, it will probably be easier to read the diff of the next revision that we hope to
submit later today.  Alternatively I can give you a github pull request link showing the changes if that would be helpful.

DW

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 12 Oct 2020 16:24:41 +0000

Hi Duane!

Thanks for the extensive changes in -13.  They address my concerns.  I have left one remaining comment about clarifying "provably secure" with a reference.  Otherwise, I've cleared my ballot.

Regards,
Roman

> Sent: Friday, October 9, 2020 2:40 PM
> <[email-masked]>; [email-masked]; [email-masked]; Wessels, Duane
> <dwessels=[email-masked]>; The IESG <[email-masked]>
> > In that case (where no assumptions are made about the transport), it seems
> that only these scenarios from the list above apply:
> >
> > I'm not sure of what the best way is to resolve this mismatch based on the
> use cases.  I can see (at least) two paths to resolution:
> >
> > (1) Specify that ZONEMD records MUST only be used with DNSSEC -- this will
> preserve the authenticity and integrity properties described in Section 1.1. and
> 6.  An additional step or two might be needed to the verification process in
> Section 4.  Does this impact the planned use cases or workflows?
> >
> > (2) Provide appropriate caveats that ZONEMD information may not mean
> what you think it means depending on whether DNSSEC is used.  This likely
> means: the motivational goal in Section 1.1 may need to be weakened; the
> analysis of alternatives in Section 1.2 won't make sense (for the non-DNSSEC
> case); and an appropriate applicability-like statement might also be necessary
> to describe how to use an insecure checksum.  Section 6 would needs
> additional language to capture the difference between the DNSSEC vs. non-
> DNSSEC deployment.  Editorially, clearer words like checksum might also help.
> 
> Thanks Roman, I see your point.  With the help of my coauthors we have made
> some edits that I think will address your concerns.
> Rather than try to include them all here, it will probably be easier to read the
> diff of the next revision that we hope to
> submit later today.  Alternatively I can give you a github pull request link
> showing the changes if that would be helpful.
> 
> DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 14 Oct 2020 12:28:13 +0000

> On Oct 12, 2020, at 9:24 AM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi Duane!
> 

Thanks Roman,

Instead of "provably secure," how does this look to you:

   1.  The verifier MUST first determine whether or not to expect DNSSEC
       records in the zone.  By examining locally configured trust
       anchors, and, if necessary, querying for and validating DS RRs in
       the parent zone, the verifier knows whether or not the zone to be
       verified should include DNSSEC keys and signatures.  For zones
       where signatures are not expected, or if DNSSEC validation is not
       performed, digest verification continues at step 4 below.

   2.  For zones where signatures are expected, the existence of the
       apex ZONEMD record MUST be validated.  If the DNSSEC data proves
       the ZONEMD RRSet does not exist, digest verification cannot
       occur.  If the DNSSEC data proves the ZONEMD does exist, but is
       not found in the zone, digest verification MUST NOT be considered
       successful.

   3.  For zones where signatures are expected, the SOA and ZONEMD
       RRSets MUST have valid signatures, chaining up to a trust anchor.
       If DNSSEC validation of the SOA or ZONEMD RRSets fails, digest
       verification MUST NOT be considered successful.

DW

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 14 Oct 2020 13:01:09 +0000

Hi Duane!

> Sent: Wednesday, October 14, 2020 8:28 AM
> > Thanks for the extensive changes in -13.  They address my concerns.  I have
> left one remaining comment about clarifying "provably secure" with a
> reference.  Otherwise, I've cleared my ballot.
> 
> Thanks Roman,
> 

This language looks good to me and is even better than a reference.  Thanks for clarifying the text further.

Roman