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

[Roman Danyliw <[e-mail]>]

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

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Wessels, Duane
> Sent: Friday, October 9, 2020 2:40 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]; Tim Wicinski
> <[e-mail]>; [e-mail]; [e-mail]; Wessels, Duane
> <dwessels=[e-mail]>; The IESG <[e-mail]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12:
> (with DISCUSS and COMMENT)
> 
> 
> 
> > On Oct 7, 2020, at 1:52 PM, Roman Danyliw <[e-mail]> wrote:
> >
> >
> > 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.
> 
> 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