Looks good. Thank you Roy!
Yaron
On 10/07/2023, 19:45, "Roy Arends" <[email protected] <mailto:[email protected]>> wrote:
Hi Yaron,
> On 9 Jul 2023, at 18:27, Yaron Sheffer <[email protected]
> <mailto:[email protected]>> wrote:
>
> 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]>
> <mailto:[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]> <mailto:[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, resolvers do not cryptographically authenticate themselves to
authoritative servers. What remains is to make sure that the source address is
not spoofed. One method to make spoofing harder is for the auth-server to reply
with a response containing a TC bit and challenge the resolver to re-query
(re-send the error report) over TCP. In addition, some of these source
addresses may be well known to the monitoring agent.
I’ll add some text around this.
>
>> - 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.
I’m not convinced this feature is a good idea.
>
>> - 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.
Will add.
Thanks Yaron!
Roy
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
