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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx mailing lists by 2015-05-01. Exceptionally, comments
> may be sent to iesg@xxxxxxxx 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/dns-privacy

Attachment: pgprfVdJotQiQ.pgp
Description: OpenPGP digital signatur


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]