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

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

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 <[e-mail]> wrote:
> 
> 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://secure-web.cisco.com/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLwmmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L-eKHO_l_zDzfiAHtMP8zHJQ_7GCF6YPn4OTvYHtKq1TL85oSNMxkc-a9TwIaBuzcEx2aRPzSqAPypDs7bIbFPs/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/1In2W1aOUrhepme0YYTCWi_KVrjzwPz6gRHK3wqiBh8JhXsVPR-caNTg-liKbKCksx5Y35akHQwb5BB41XUadJT3by_ZmHTxwdiSU3QpC4eNTBAE42Pw2mywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsjsae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm4JcgBjaAU2ABRPZ-bfBv0LsmZR0Q/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
> 
> 
> 
> ----------------------------------------------------------------------
> 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.”

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.


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

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?


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

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


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

Okay.


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

How about this :

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


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

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


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

Fine with me.


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


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?


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

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.




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

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


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


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