Just to be clear - I support the draft in principle. My comments are intended to help refine the document. -- Glen Wiley KK4SFV
Sr. Engineer The Hive, Verisign, Inc. On 11/13/13 4:49 AM, "Stephane Bortzmeyer" <[email protected]> wrote: >On Mon, Nov 11, 2013 at 07:27:25PM +0000, > Wiley, Glen <[email protected]> wrote > a message of 67 lines which said: > >> I realize that this is obvious, but it might be worth noting that >> there is often (typically) a network connection made to the subject >> of a DNS query sent from a stub resolver. For example after sending >> a query for www.example.com I am likely to make a connection via TCP >> to the address returned. This fact reduces the value of obscuring >> DNS queries > >That's one of the reasons that I mentioned other practices such as >having a local resolver (with caching) to limit the number of actual >outgoing queries. When it comes for privacy, it is very unlikely that >*one* technical solution will plug all the leaks. We have to deploy a >consistent set of anti-surveillance measures. > >Another thing, not yet mentioned in the draft, would be to send dummy >queries from time to time, requests you're not interested in, just to >blur the patterns. > >> then they will see outbound connections to www.example.com and so it >> doesn't really matter whether they were able to see the DNS query. > >Read the draft again (section 3.2). For instance, the manager of the >TLD .example sees the DNS requests coming in his name servers but >typically cannot tap the TLS traffic to www.something.example. > >> While I agree with the sentiments in this section, is this in scope for >> this draft? > >Yes, it is. We have seen already malwares who modifies the DNS >resolvers to a server which, apparently does not lie. The only >explanation I can find is that people want to spy on DNS traffic. > >> Section 6.1 >> >> It feels as though this section dives into the solution rather than the >> problem. > >At the beginning of this draft, it was only about problem >statement. Some people feared it would not be taken seriously if it >never mentioned at least possible solutions. (After all, knowing a >problem for which there is no solution is depressing.) > >May be in the future, this draft should be split in two, problem >statement and best practices to limit DNS leakage. But, IMHO, it is >too early in the discussion to say so. > >In practice, solutions would probably require several RFC since some >are only practices (having a local caching resolver), some require >change in software but not in protocol (sending only NS queries to the >authoritative servers) and some require new protocols (encrypting DNS >traffic). > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
