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 <[email protected]> On Behalf Of Wessels, Duane > Sent: Friday, October 9, 2020 2:40 PM > To: Roman Danyliw <[email protected]> > Cc: [email protected]; Tim Wicinski > <[email protected]>; [email protected]; [email protected]; Wessels, Duane > <[email protected]>; The IESG <[email protected]> > 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 <[email protected]> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
