Hi Matt, Comments in-line.
On Mon, Mar 18, 2019 at 5:50 PM Matthew Pounsett <m...@conundrum.com> wrote: > > > On Fri, 15 Mar 2019 at 14:37, Ted Hardie <ted.i...@gmail.com> wrote: > >> >>> The past five years have not been the IETF seeking to become a king or >> king-maker. They have been spent responding to an attack while still >> building out the facilities of the network. I am glad to find you a ready >> participant now, as there is still work to be done. But I do not believe >> we have said that you may not have these facilities; the new methods simply >> mean you must have a relationship with the users and devices on your >> network sufficient to effect configuration to use them. An on-path >> adversary does not, but you do. Yes, that adds a step and some complexity, >> but dealing with a new class of attack was never likely to be free. >> > > This, again, conflates users with attackers. > > I'm going to take a stab at restating the positions of several people in > this thread, Paul included, because it really seems like the argument is > not understood. > > I have a relationship with my users and I can control the configuration of > their *known* applications. I do not have a relationship with the malware > author that is trying to steal their data, and cannot control the > configuration of that (unknown) application. By running DoT on my borders > and blocking all other DNS and DoT traffic, I can provide privacy for my > users while still preventing malware from doing its thing. > As I said to Paul, I don't think you can if your only defense is blocking DNS access. Coding a system to use a non-standard resolution protocol over TLS is relatively easy; all the malware needs is a specific target to start at. That target can be hard coded, derived from the output of a web search, or produced by the output of an algorithm resident in the malware and some system-available data (commonly the time). My apologies if I have misunderstood your point here, but unless you also block all traffic for which you have seen no resolution event, I believe that it is entirely possible to circumvent the defense you describe. > With DoH available at endpoints that my users want to reach using some > other application, > And this is the critique that is not of DoH as a protocol, but of a specific deployment possibility. You've seen the Quad9 folks point and the Chrome statement of their current deployment plans. The first said they will not deploy DNS resources and other web resources on commingled hosts. The second said that they will only use DoH after a probe reveals that it is available *at the already configured DNS service*. This is entirely in line with Section 3 of RFC 8484: A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration (such as through HTTP/2 server push) or because a server offers an unsolicited response that appears to be a valid answer to a DNS query. This specification does not extend DNS resolution privileges to URIs that are not recognized by the DoH client as configured URIs. Browsers do not have an incentive to permit random websites to poison their caches, so I strongly suspect that there will be no ability to pass a resolution done in JavaScript down into the browser cache; my experience during RTCWeb was that the browsers treated all downloaded JavaScript applications as potentially malign. > it is orders of magnitude more complex for me to block the malware while > still allowing my users to reach those endpoints. Phrased another way, a > DoH endpoint at the same IP address as a popular website gives malware the > ability to resolve names I was previously able to prevent. > In the RFC 8484 terms, this is a DoH server. For this threat to be real, there is an additional requirement: the DoH server at the popular website must also be trusted by the application as a source of DNS data. For the ones you configure, this remains in your control. For JavaScript applications within browsers, see above. So this is probably the case only for pure malware, which already has other circumventions available. > The only recourse I know of, if DoH is adopted, is to proxy all traffic > toward that example site (including requiring me to engage in a MitM > decryption attack on my users' web traffic) in order to continue to prevent > that malware from circumventing network security. And because I can't > predict which web sites will launch their own DoH endpoints, that means I > need to proxy (and decrypt) all web traffic in order to maintain the same > level of security I can today. > > Note that popular Web servers commingling DoH services should answer a DNS query probe, so you will be able to tell readily if any of them choose to do it. And, of course, you could respond by blocking the service rather than with MitM; I suspect some would. regards, Ted > Somewhere up-thread it was suggested that there are other reasonable steps > that a network/security operator can take to maintain the controls over > resolution that we have today, but so far I haven't seen them enumerated > anywhere. > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop