Subject: Re: [dns-privacy] Last Call: <draft-ietf-dprive-problem-statement-04.txt> (DNS privacy considerations) to Informational RFC

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Apr 2015 11:03:59 +0200

This is a good document, that I recommend people to read:
https://tools.ietf.org/html/draft-ietf-dprive-problem-statement

One risk concerning DNS privacy that I couldn't see discussed is one
that may be too obvious so that it was forgotten.  That is the risk of
someone on the Internet actively intercepts my DNS traffic, responding
with correct data while gathering privacy-sensitive information.  This
appears to be included in the threat model of RFC 7258, quoting "Active
or passive wiretaps ... can also be used as part of pervasive
monitoring."

Active attacks are discussed in 2.5.3 "Rogue servers" but in the
context of rogue DHCP servers providing me with the wrong IP of a DNS
server.  I believe a more simpler (and more worrying) case is that my
DNS stub resolver is attempting to talk to a remote DNS server but
someone on the way stops the packet and responds to it pretending to be
the source.

Section 2.4 "On the wire" talks about DNS traffic being unencrypted and
can be seen by an eavesdropper, but this is somewhat different from an
active attacker.

Did I miss where privacy-unfriendly active attacks on the DNS
infrastructure is discussed in the document?

I would suggest to add the following paragraph to 2.4 "On the wire",
2.5.3 "Rogue servers", or a new section "Active attackers".  Feel free
to reword or rewrite this completely.

  Another risk is that traffic from a DNS client to a DNS server
  is intercepted along its way from originator to intended source.
  This rogue server can masquerade as the intended server and respond
  with data to the client.  Rogue servers that inject malicious data
  are possible, but is a separate problem not relevant to privacy.
  A rogue server may respond correctly for a long period of time,
  therby foregoing detection.  This may be done for what could be
  claimed to be good reasons, such as optimization or caching, but it
  leads to a reduction of privacy compared to if there were no attacker
  present.

Whether this is a risk worth adressing is another discussion, but I
feel the risk should be mentioned in a document like this.

Thanks,
/Simon

> 
> The IESG has received a request from the DNS PRIVate Exchange WG
> (dprive) to consider the following document:
> - 'DNS privacy considerations'
>   <draft-ietf-dprive-problem-statement-04.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-05-01. Exceptionally, comments
> may be sent to [email-masked] instead. In either case, please retain
> the beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document describes the privacy issues associated with the use
> of the DNS by Internet users.  It is intended to be an analysis of the
>    present situation and does not prescribe solutions.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 24 Apr 2015 17:16:41 +0200

On Thu, Apr 23, 2015 at 11:03:59AM +0200,
 Simon Josefsson <[email-masked]> wrote 
 a message of 124 lines which said:

> That is the risk of someone on the Internet actively intercepts my
> DNS traffic, responding with correct data while gathering
> privacy-sensitive information.

>From the point of view of privacy, I do not see the difference with a
purely passive attacker, reading the flow of requests and responses.

Or the case mentioned in 2.5.1, "Recursive Resolvers see all the
traffic since there is typically no caching before them.  To
summarize: your recursive resolver knows a lot about you."

In all these cases, the bad guy has the same info, and is as difficult
to detect because the responses are authentic.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Apr 2015 16:48:37 +0200

> purely passive attacker, reading the flow of requests and responses.

That is exactly the point of my concern.  Perhaps we are talking past
each other somewhat.  I'll try to explain differently.

From a privacy point of view, one privacy issue is introduced by the
presence of a malicious network entity.  There are different kinds of
malicious network entities.  Eavesdroppers (network listeners) is one
kind.  Active attackers (network listeners plus ability to modify
traffic) is another kind.  (The former is a sub-class of the latter, if
you wan't to be strict about it.)  Both RFC 6973 and RFC 7258 (normative
references to this document) mention active attacks, and both refer to
RFC 3552 on how confidentiality can be achieved.  RFC 3552 talks about
passive and active attackers separately, and that the Internet threat
model includes active attackers.

The document would be fine if it said "malicious network entity" but it
consistently says "eavesdropper".  It never mentions active attackers of
DNS traffic as far as I could tell.  Thus it never considers the risk of
having an active attacker in the network.  One might get the impression
that if there would be protection against eavesdroppers, the privacy
concerns would be resolved.  I argue that this is not the case.

Instead of modifying the document a lot, generalizing "eavesdropper"
into "malicious network entity", I suggest to talk about active
attackers separately.  I believe this is easier for readers, and is
consistent with RFC 3552.

Please consider adding the following paragraph to make the risk
assessment more complete by talking about active attackers too.

Thanks,
/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Apr 2015 07:57:11 -0700

>  leads to a reduction of privacy compared to if there were no attacker

Adding something like this (or this) just before Section 2.1 seems helpful.

--Paul Hoffman