> -----Original Message----- > From: dns-privacy <[email protected]> On Behalf Of Paul > Wouters > Sent: Monday, August 16, 2021 8:38 AM > To: Hollenbeck, Scott <[email protected]> > Cc: [email protected] > Subject: [EXTERNAL] Re: [dns-privacy] Security Considerations: Traffic > Analysis > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > 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".
[SAH] Perhaps, but that's why I included potential mitigations. There are things that can be done to reduce the risk. > > 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. [SAH] Agreed. > > 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. [SAH] Somewhat hide, yes. > > 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". [SAH] Thanks for confirming the need for the discussion. I mentioned the research paper fully expecting that it won't be included, but I hope people read it and accept that traffic analysis is a real risk that needs to be described in the Security Considerations section. Scott _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
