Re: [dns-privacy] [dprive] Specification of DNS over Dedicated QUIC Connections (draft-ietf-dprive-dnsoquic-04) - feedback

["Quick, Matthew" <[e-mail]>]

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
 
[e-mail]
571.732.6173

12061 Bluemont Way, Reston, VA 20190

On 10/5/21, 6:23 AM, "Sara Dickinson" <[e-mail]> 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 <mquick=[e-mail]> 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.