Hi Sara, Thank you for your kind response. Agree that your reference to [RFC8932] covers the scope of my suggestions!
Best, Matt Matthew Quick Senior Engineer Industry Standards & Technical Engagement [email protected] 571.732.6173 12061 Bluemont Way, Reston, VA 20190 On 10/5/21, 6:23 AM, "Sara Dickinson" <[email protected]> wrote: 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
