> -----Original Message----- > From: Paul Hoffman <[email protected]> > Sent: Monday, August 16, 2021 10:19 AM > To: Hollenbeck, Scott <[email protected]> > Cc: [email protected] > Subject: [EXTERNAL] Re: [Ext] [dns-privacy] Security Considerations: Traffic > Analysis > > On Aug 16, 2021, at 5:14 AM, Hollenbeck, Scott > <[email protected]> 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://secure- > web.cisco.com/1BnLOTztjAEEKsTmNTQ12s7CJTbafBHe2ULMhaC1Z > > pPluwYnbvLJZjTfUJiuCogPIu- > CmzqUwtazRCiChJfxqCkIQJjG9KIcwFnFC89CHAAB-7w > > KRGczojrlT43PRxGTtxnmneycEX6VYcQ4afNDxMmSl0aVh- > a30oKKtS3pXXyKT_NlmS5Ul > > S483kVZJq_cAUtePhPFHfy8fGP7NZun64UE- > yAI8E1BcuhX7O89L28xy1jIB0eRBTv-1e1 > > yIsZgo/https%3A%2F%2Fwww.ndss-symposium.org%2Fwp- > content%2Fuploads%2F2 > > 020%2F02%2F24301-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?
[SAH] The act of encrypting may mislead someone into thinking that their confidentiality concerns have been completely addressed. In lieu of the text I proposed, yes, references to RFCs such as 8932 and 9076 could help make it clear that privacy considerations remain even if encryption is used. Scott _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
