On Mon, 16 Aug 2021, Hollenbeck, Scott 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.
It can be pointed out, would I would not say it can be "addressed".
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 DNS padding (RFC 7830) could be mentioned to hide the exact packet size of DNS queries/responses.
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].
I'm not sure I agree with "often" and "make it possible". That really depends on the number of zones hosted by the particular nameserver and the particular service contacted after the lookup. If the nameserver hosts 1M domains, and the target webserver hosts 1K domains, it might still be possible to somewhat hide what you were talking to.
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.
As I said, DNS padding can be used for that. But in general, a little bit of this discussion is suitable in the Security Considerations. But clearly, we can't add a multitude of research papers in this section. Perhaps the goals can be stated more realistically, eg "use encryption to not make it trivially easy for any on-path attaker to see your DNS" and ensure there is no expectation of "total anonymity". Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
