Re: [dns-privacy] [Ext] Security Considerations: Traffic Analysis

[Paul Hoffman <[e-mail]>]

On Aug 16, 2021, at 5:14 AM, Hollenbeck, Scott <shollenbeck=[e-mail]> wrote:
> 
> The iterative nature of recursive resolution gives an on-path monitor multiple opportunities to observe query traffic between a recursive resolver and an authoritative name server. Even with encryption, the name server IP addresses can be used to draw accurate conclusions about qnames by matching IP addresses to name servers identified in publicly available zones. This is something that needs to be addressed in the Security Considerations section of any draft that describes a recursive-to-authoritative encryption solution.
> 
> draft-ietf-dprive-dnsoquic addresses traffic analysis, but draft-ietf-dprive-unauth-to-authoritative does not. draft-rescorla-dprive-adox-latest addresses it somewhat. I'd like to suggest that text like this (or something similar) be added to draft-ietf-dprive-unauth-to-authoritative and draft-rescorla-dprive-adox-latest:
> 
> 
> BEGIN
> Encryption is one of several controls that can reduce the risk of disclosure of sensitive information. Resolver-to-authoritative DNS encryption will protect the DNS traffic exchanged between the resolver and the authoritative name server from being directly observed and/or modified by an adversary. However, as in other systems where encryption is deployed, implementers should also consider other ways in which the same or related information may also be exposed, and how to mitigate those risks. For example, encryption provides confidentiality protection for DNS query and response payloads between recursive resolvers and authoritative name servers, but iterative resolution makes it possible to perform traffic analysis using other, non-encrypted information that can be observed in subsequent iteration steps. The names and IP addresses of the name servers for most DNS zones are publicly available, so an attacker that can monitor traffic exchanged between a resolver and an authoritative n
> ame server will often be able to identify the zone of interest based on the IP address of the authoritative name server. Iterative resolution using destination IP addresses that were encrypted in a previous query makes it possible to identify the set of domains that might be associated with a query by observing the destination IP address and comparing that to the addresses and names found in publicly-available zone files. This risk can be reduced by limiting the number of queries sent to authoritative name servers using techniques such as hyperlocal root processing [RFC7706], NXDOMAIN cut processing [RFC8020], and aggressive DNSSEC caching [RFC8198].
> 
> The size of encrypted query and response packets can also be used to detect query patterns. The set of name servers and IP addresses returned in a response to a query changes infrequently, so the size of the DNS response for a specific set of name servers tends to stay the same during a given time period. The size of responses can be monitored to observe patterns associated with responses from specific name servers, and this information can be used to identify queries for specific domain names. This risk can be reduced by padding the record payload of TLS-protected responses to eliminate response size variability.
> 
> Additional traffic analysis considerations are described in a paper titled "Encrypted DNS =⇒ Privacy? A Traffic Analysis Perspective" [1].
> 
> [1] https://www.ndss-symposium.org/wp-content/uploads/2020/02/24301-paper.pdf
> END

This seems misplaced. The act of encrypting recursive to authoritative does not add any more considerations for "other ways in which the same or related information may also be exposed, and how to mitigate those risks". Instead of listing just a few privacy considerations, wouldn't it be better to have the reader go to the more complete list in RFC 8932 and RFC 9076?

--Paul Hoffman