In message <ca+9kkmceshvfaytsnzt2ueyskqq0c+nyfzvkpocyymjsraw...@mail.gmail.com> , Ted Hardie writes: > > On Mon, Oct 20, 2014 at 6:10 PM, Paul Vixie <[email protected]> wrote: > > > > > query minimization i see no benefit or need for secrecy since dns is a > > publication system -- if you don't want people to see your information, > > don't put it into the dns. cache miss transactions (#2 above) expose only > > server IP addresses, not end-user IP addresses, and no re-use events. as > > such it has always been my position that there is no PII and no privacy > > impact from having these recorded and analyzed. i would not like to see the > > IETF work in that area.ld be classified into: > > > > At the STRINT workshop, we discussed the extent to which combining queries > at a proxy provides protection against analysis by a monitor. It is > certainly the case that it provides some benefit, but we there are limits, > especially when the resolver serves a relatively small number of users. > > To take an example: Joe belongs a club, example.org, and is using their > network to look up a sensitiveblog.journal.example. example.org hosts it > own DNS resolver, but few users connect to journal.example (having mostly > moved to face-example.org), so when Joe makes his look up, it's a cache > miss. A surveillance entity will therefore see > sensitiveblog.journal.example as a target of the DNS query if it has a tap > on path between example.org and journal.example, and it now knows that the > traffic between example.org and journal.example is for the senstiveblog. > > Note that it would not necessarily have known that otherwise. Because > journal.example uses the HOST header to disambiguate traffic to different > hosted journals, thus consuming a very small number of IP addresses, the > connection itself would not have identified which blog was at issue. [There > are other potential sources of leaks, here, such as the unencrypted SNI in > TLS, but that has to be worked elsewhere. I do not personally accept the > idea that we can't fix information leakage piece by piece, just because > other leaks are possible]. > > Clearly, had Joe used OpenDNS, Google's DNS, or a large ISP DNS service > which aggregates many more users, the chance of a cache miss would be lower > and the correlation would be much, much harder even in the case of a cache > miss. But the DNS protocol cannot presume that sort of deployment, and > they have other consequences in terms of trust between users and large > services. > > As long as the DNS continues to support deployment of recursive resolvers > in topologies that cannot effectively provide aggregation as a mitigation, > I believe that the recursive to authoritative problem should stay on the > table. It is a lower priority, but it is a valuable piece of work. I > personally also think that it is a substantially different problem from the > stub to recursive resolver problem, so we should treat them independently. > > My two cents, in any case. > > Ted Hardie
And it is actually a solvable problem. Lookup KEY, potentially in the clear, for the server using DNSSEC to secure the response. If it has the correct flag bits set (TBD) issue encrypted DNS queries using that KEY and a session key for the response. The presence of the KEY with the correct flag bits indicates that encryption is supported so there is no downgrade to plain text possible. Send the encrypted message using a new OPTCODE. The format of the body of the message is left as a exercise. If we need to encode a list of offered cyphers then choose a new type to use instead of KEY. The client will choose from this list. The only question is the KEY looked up by name or address? I would say address is better as you can't hide that you are talking to a server. As a additional benefit this also works for public recursive servers. 8.8.8.8.in-addr.arpa KEY ..... This can be looked up by validating stub resolvers in the clear using 8.8.8.8. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
