Hi Matthew, Sorry for a slow response - thanks for picking up the reference issues! One comment below.
> On 22 Sep 2021, at 16:14, Quick, Matthew > <[email protected]> wrote: > > Dear Christian et al, > > Hello - I hope this finds you well. Please find an additional section > suggestion and comments for “draft-ietf-dprive-dnsoquic-04”, below. Your > feedback is greatly appreciated. > > Best, > Matthew Quick, Verisign > > ____________________________ > 9. Privacy Considerations > > Justification: > The reference to [I-D.ietf-dprive-rfc7626-bis] is obsoleted when it became > [RFC9076] in July 2021. > > Existing Text: > The general considerations of encrypted transports provided in "DNS Privacy > Considerations" [I-D.ietf-dprive-rfc7626-bis] apply to DoQ. > > Suggested Text: > The general considerations of encrypted transports provided in "DNS Privacy > Considerations" [RFC9076] apply to DoQ. > > ____________________________ > 9.1 Privacy Considerations > > Justification: > The reference to [RFC7626] is obsoleted when it became [RFC9076] in July 2021. > > Existing Text: > This risk is in fact a subset of the general problem of observing the > behavior of the recursive resolver discussed in "DNS Privacy Considerations" > [RFC7626]. > > Suggested Text: > This risk is in fact a subset of the general problem of observing the > behavior of the recursive resolver discussed in "DNS Privacy Considerations" > [RFC9076]. > > ____________________________ > 9. Privacy Considerations > > Justification: > The new text only applies to interactions with authoritative name servers, > not stub to recursive, so it fits well as an additional part of Section 9 – > Privacy Considerations. Also, RFC 9076 only mentions QNAME minimization, so > it’s helpful to have a separate place to expand the explanation of data > privacy. > > New Section Suggested Text: > > 9.5. Relationship with Minimization Techniques > QNAME minimization [RFC7816] reduces the sensitive information exchanged to > only what’s necessary to perform a requested function. This reduces the risk > of disclosure to both outside and inside parties, with no operational impact > on the receiver. Additional minimization methods include NXDOMAIN cut > processing [RFC8020], and aggressive DNSSEC caching [RFC8198]. It is a good point that we haven’t covered this kind of consideration. I’d like to suggest adding the following text at the end of the first paragraph of section 9 as a more general improvement since RFC8932 covers privacy stub-to-recursive, recursive-to-auth and data at rest. Section 5.3.1 of RFC8932 covers exactly the references you cite above. “”Similarly, "Recommendations for DNS Privacy Service Operators" [RFC8932] (which covers operational, policy, and security considerations for DNS privacy services) is also applicable to DoQ services.” Best regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
