Mixup on my part! Thanks Yaron,
(And Mark for a private reply) Roy > On 9 Jul 2023, at 19:07, Roy Arends <[email protected]> wrote: > > Thanks Mark, will have a look! > > Warmly > > Roy > >> On 9 Jul 2023, at 18:27, Yaron Sheffer <[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]>> >> 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 >> <https://urldefense.com/v3/__http://er.uk/__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVEoZdYAY$ >> [er[.]uk]>.error.com >> <https://urldefense.com/v3/__http://er.uk/>.error.com__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVbPm_6gY$ >> [er[.]uk]> >> co.uk >> <https://urldefense.com/v3/__http://co.uk/__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xV2_TaBQY$ >> [co[.]uk]>._er.uk.error.com >> <https://urldefense.com/v3/__http://co.uk/>._er.uk.error.com__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVEqBCqtc$ >> [co[.]uk]> >> <https://urldefense.com/v3/__http://er.uk.error.com/__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVyM5BoUA$ >> [er[.]uk[.]error[.]com]> >> <https://urldefense.com/v3/__http://er.uk.error.com/>__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVd2RGOqw$ >> [er[.]uk[.]error[.]com]> >> police.uk >> <https://urldefense.com/v3/__http://police.uk/__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVX4jkwj8$ >> [police[.]uk]>._er.uk.error.com >> <https://urldefense.com/v3/__http://police.uk/>._er.uk.error.com__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVr404ZQk$ >> [police[.]uk]> >> <https://urldefense.com/v3/__http://er.uk.error.com/__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVyM5BoUA$ >> [er[.]uk[.]error[.]com]> >> <https://urldefense.com/v3/__http://er.uk.error.com/>__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVd2RGOqw$ >> [er[.]uk[.]error[.]com]> >> Some_org.co.uk._er.uk.error.com >> <https://urldefense.com/v3/__http://er.uk.error.com/__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVyM5BoUA$ >> [er[.]uk[.]error[.]com]> >> <https://urldefense.com/v3/__http://er.uk.error.com/>__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVd2RGOqw$ >> [er[.]uk[.]error[.]com]> >> >> >> You’ll see that a single error for “example.co.uk >> <https://urldefense.com/v3/__http://example.co.uk/__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVaxKmXHo$ >> [example[.]co[.]uk]> >> <https://urldefense.com/v3/__http://example.co.uk/>__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xVgdgQVdE$ >> [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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xV_FbZ9Bw$ >>> [ietf[.]org] >>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!_hXftLPJWbhR7OAV8uLJsCwVhOWDeg1qZSV1hJMgzCOvZVkZJyebPLY_pk1Sq55RbMRjtCfSbmwVam5KW6xV_FbZ9Bw$ >>> [ietf[.]org]> >> >> >> >> >> _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
