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

[Roman Danyliw <[e-mail]>]

Hi Duane,

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Wessels, Duane
> Sent: Wednesday, October 7, 2020 3:55 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]; Tim Wicinski
> <[e-mail]>; [e-mail]; [e-mail]; The IESG
> <[e-mail]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12:
> (with DISCUSS and COMMENT)
> 
> 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/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLw
> mmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84
> DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ
> 9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L-
> 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_ZmHTxwdiSU3QpC4eNTBAE42Pw2m
> ywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsj
> sae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm
> 4JcgBjaAU2ABRPZ-
> 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.

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

 With an on-path attacker (and trusted server hosting the zone file)

** No DNSSEC  = integrity: NO; 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 = 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