Subject: [dns-privacy] Security Considerations: Traffic Analysis

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Aug 2021 12:14:35 +0000

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 name 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

Scott

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Aug 2021 08:38:09 -0400 (EDT)

> 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 encryp…

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 s…

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Aug 2021 13:31:11 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Paul
> Wouters
> Sent: Monday, August 16, 2021 8:38 AM
> To: Hollenbeck, Scott <shollenbeck=[email-masked]>
> Cc: [email-masked]
> 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.
> 
> > 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.
> 

[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
> 

[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.
> 
> 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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Aug 2021 14:19:13 +0000

On Aug 16, 2021, at 5:14 AM, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 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

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Aug 2021 14:51:15 +0000

> From: Paul Hoffman <[email-masked]>
> Sent: Monday, August 16, 2021 10:19 AM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [Ext] [dns-privacy] Security Considerations: Traffic
> Analysis
> 
> On Aug 16, 2021, at 5:14 AM, Hollenbeck, Scott
> <shollenbeck=[email-masked]> wrote:
> >
> > 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 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].
> >
> > 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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Aug 2021 15:27:50 +0000

On Aug 16, 2021, at 7:51 AM, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 
> [SAH] The act of encrypting may mislead someone into thinking that their confidentiality concerns have been completely addressed.

Neither of the proposed protocols have any way for an end user to know what part of the recursive-to-authoritative traffic used to answer their query (if any) was encrypted.

> 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.

We'll do that.

--Paul Hoffman

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Aug 2021 16:43:33 +0000

> Sent: Monday, August 16, 2021 11:28 AM
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Security Considerations: Traffic
> Analysis
>
> On Aug 16, 2021, at 7:51 AM, Hollenbeck, Scott
> > [SAH] The act of encrypting may mislead someone into thinking that their
> confidentiality concerns have been completely addressed.
>
> Neither of the proposed protocols have any way for an end user to know
> what part of the recursive-to-authoritative traffic used to answer their query
> (if any) was encrypted.

[SAH] It's not just about end users. Operators who implement and deploy this technology need to understand its limitations.

> > 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.
>
> We'll do that.

[SAH] Thanks!

Scott

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Aug 2021 13:04:45 -0400

On Aug 16, 2021, at 12:43, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> [SAH] It's not just about end users. Operators who implement and deploy this technology need to understand its limitations

What would a recursive DNS server do different if the encrypted connection might be reduced to plaintext ? It’s only options are “keep using it” or “fallback to clear text”

Paul

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Aug 2021 17:15:06 +0000

> From: Paul Wouters <[email-masked]>
> Sent: Monday, August 16, 2021 1:05 PM
> Cc: [email-masked]; [email-masked]
> On Aug 16, 2021, at 12:43, Hollenbeck, Scott
> >> Neither of the proposed protocols have any way for an end user to
> >> know what part of the recursive-to-authoritative traffic used to
> >> answer their query (if any) was encrypted.
> >
> > [SAH] It's not just about end users. Operators who implement and
> > deploy this technology need to understand its limitations
>
> What would a recursive DNS server do different if the encrypted connection
> might be reduced to plaintext ? It’s only options are “keep using it” or
> “fallback to clear text”

[SAH] They can employ data minimization techniques to reduce the amount of information sent to the authoritative server. They can pad the payloads.

Scott