> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
