Skip to main content

Early Review of draft-ietf-dnsop-dns-error-reporting-04
review-ietf-dnsop-dns-error-reporting-04-secdir-early-sheffer-2023-06-26-00

Request Review of draft-ietf-dnsop-dns-error-reporting
Requested revision No specific revision (document currently at 08)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2023-06-30
Requested 2023-06-07
Requested by Benno Overeinder
Authors Roy Arends , Matt Larson
I-D last updated 2023-06-26
Completed reviews Dnsdir Telechat review of -07 by James Gannon (diff)
Intdir Telechat review of -07 by Carlos Pignataro (diff)
Tsvart Telechat review of -07 by Gorry Fairhurst (diff)
Dnsdir Early review of -04 by James Gannon (diff)
Secdir Early review of -04 by Yaron Sheffer (diff)
Tsvart Last Call review of -06 by Gorry Fairhurst (diff)
Dnsdir Last Call review of -06 by David C Lawrence (diff)
Secdir Last Call review of -06 by Yaron Sheffer (diff)
Genart Last Call review of -06 by Peter E. Yee (diff)
Comments
The WG Chairs would like an early review of the draft, which will run parallel to the WGLC.
Assignment Reviewer Yaron Sheffer
State Completed
Request Early review on draft-ietf-dnsop-dns-error-reporting by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/0i-vu4g4GMj4Wa852QRCoyj-Hcg
Reviewed revision 04 (document currently at 08)
Result Has nits
Completed 2023-06-26
review-ietf-dnsop-dns-error-reporting-04-secdir-early-sheffer-2023-06-26-00
I am not a DNS expert so these may or may not be real issues. But I would
appreciate the authors' clarifications.

- The error reports are unauthenticated. Some possible implications include:
(1) Operators may choose to implement automated responses to error reports, and
will not consider that the source of the reports is untrusted. (2) An adversary
may create massive error report flooding to camouflage an attack. At minimum, I
suggest to mention these risks in the security considerations.

- "Authentication significantly increases the burden on the reporting resolver
without any benefit to the monitoring agent, authoritative server or reporting
resolver." I'm not sure I agree there's no benefit: a known, trusted set of
reporting resolvers can provide a higher level of confidence in the error
reports, and potentially enable more automated processing of these reports.
CDNs may become such trusted resolvers, for example.

- In general, is there value to error reporting in the absence of (aggregated)
reporting on success? In other words, when evaluating a stream of errors, isn't
it important to measure the percentage of errors as part of the overall number
of requests for a particular domain?

- This is yet another DNS covert channel. Should we mention it in the Security
Considerations?

- What is the broader effect of avoiding DNSSEC for the agent domain? Does it
interfere with policies (and their automated enforcement) such as "sign
everything under .tld"?

- More formally, there is no normative language around avoiding DNSSEC. Is it a
SHOULD?

- DNS query name minimization - shouldn't there be some guidance on this?
Clearly minimization does not apply to the actual error portion of the report
QNAME.