On Apr 27, 2015, at 7:48 AM, Simon Josefsson <simon@xxxxxxxxxxxxx> wrote: > > Stephane Bortzmeyer <bortzmeyer@xxxxxx> writes: > >> On Thu, Apr 23, 2015 at 11:03:59AM +0200, >> Simon Josefsson <simon@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail