Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dns-error-reporting-04

[Yaron Sheffer <[e-mail]>]

Looks good. Thank you Roy!

	Yaron

On 10/07/2023, 19:45, "Roy Arends" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Yaron,


> On 9 Jul 2023, at 18:27, Yaron Sheffer <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Roy,
> 
> Please see some responses below, prefixed with YS.
> 
> Thanks,
> Yaron
> 
> On 05/07/2023, 14:31, "Roy Arends" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> 
> 
> Yaron, many thanks for your review. Comments inline:
> 
> 
>> On 26 Jun 2023, at 13:24, Yaron Sheffer via Datatracker <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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