On Apr 27, 2015, at 7:48 AM, Simon Josefsson <simon(_at_)josefsson(_dot_)org>
wrote:
Stephane Bortzmeyer <bortzmeyer(_at_)nic(_dot_)fr> writes:
On Thu, Apr 23, 2015 at 11:03:59AM +0200,
Simon Josefsson <simon(_at_)josefsson(_dot_)org> 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.
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.
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.
Adding something like this (or this) just before Section 2.1 seems helpful.
--Paul Hoffman
signature.asc
Description: Message signed with OpenPGP using GPGMail