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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Paul Hoffman <[e-mail]>
> Sent: Monday, August 16, 2021 10:19 AM
> To: Hollenbeck, Scott <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: [Ext] [dns-privacy] Security Considerations: Traffic
> Analysis
> 
> 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://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