Hi Roy,
Please see some responses below, prefixed with YS.
Thanks,
Yaron
On 05/07/2023, 14:31, "Roy Arends" <[email protected] <mailto:[email protected]>> wrote:
Yaron, many thanks for your review. Comments inline:
> On 26 Jun 2023, at 13:24, Yaron Sheffer via Datatracker <[email protected]
> <mailto:[email protected]>> wrote:
>
> Reviewer: Yaron Sheffer
> Review result: Has Nits
>
> 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.
Will do.
>
> - "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.
I will tone down the dismissive language and just use the following:
"Authentication significantly increases the burden on the reporting resolver,
however, 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.”
(I’ve used your text as guidance)
YS: I'm not sure I understand the proposed text, because the draft does not
provide a way (namely, authentication) to establish a "known, trusted set of
resolvers". Unless there's a way to authenticate these reports that I'm not
familiar with.
> - 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?
Absolutely. However, I wanted to avoid predicting how the reporting agent is
going to implement its analysis and reporting functions.
YS: understood. It just seems to me that we're not providing the agent with
enough input for this analysis. And I guess I was suggesting to add a feature:
aggregated (or random, sample based) reporting on *successful* name resolution.
> - This is yet another DNS covert channel. Should we mention it in the Security
> Considerations?
Is it though? If it is, isn’t all DNS susceptible to being a covert channel?
Isn’t any traffic, not just DNS, susceptible of being another covert channel?
YS: fair enough.
> - 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"?
This should be dealt with in the relevant policy area.
> - More formally, there is no normative language around avoiding DNSSEC. Is it
> a
> SHOULD?
YS: even if you deem DNSSEC policy to be out of scope, the question about
normative language still stands. Or at least guidance on when this mitigation
is recommended.
>
> - 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.
Clearly?
An agent domain can setup its servers in various ways, say, a single agent
domain “uk.error.com”, and subsequently delegate:
uk._er.uk <http://er.uk/>.error.com <http://er.uk/>.error.com>
co.uk <http://co.uk/>._er.uk.error.com <http://co.uk/>._er.uk.error.com>
<http://er.uk.error.com/> <http://er.uk.error.com/>>
police.uk <http://police.uk/>._er.uk.error.com
<http://police.uk/>._er.uk.error.com> <http://er.uk.error.com/>
<http://er.uk.error.com/>>
Some_org.co.uk._er.uk.error.com <http://er.uk.error.com/>
<http://er.uk.error.com/>>
You’ll see that a single error for “example.co.uk <http://example.co.uk/>
<http://example.co.uk/>>” may be delegated a few times before it reaches the
target server.
Hope this helps,
Thanks for the review Yaron!
Warmly,
Roy
>
>
> _______________________________________________
> DNSOP mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dnsop
> <https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
