ietf
[Top] [All Lists]

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

2015-04-23 04:04:50
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
ietf(_at_)ietf(_dot_)org mailing lists by 2015-05-01. Exceptionally, comments
may be sent to iesg(_at_)ietf(_dot_)org 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
dns-privacy(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dns-privacy

Attachment: pgphFbuFDdWa9.pgp
Description: OpenPGP digital signatur