Thanks Mark, will have a look! Warmly
Roy > On 9 Jul 2023, at 18:27, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > > Hi Roy, > > Please see some responses below, prefixed with YS. > > Thanks, > Yaron > > On 05/07/2023, 14:31, "Roy Arends" <r...@dnss.ec <mailto:r...@dnss.ec>> > wrote: > > > Yaron, many thanks for your review. Comments inline: > > >> On 26 Jun 2023, at 13:24, Yaron Sheffer via Datatracker <nore...@ietf.org >> <mailto:nore...@ietf.org>> 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 >> DNSOP@ietf.org <mailto:DNSOP@ietf.org> >> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
