On 20 Sep 2017, at 2:59 am, Ted Hardie <ted.ietf@xxxxxxxxx> wrote: > > Howdy, > > I'll try to snip pieces not salient without hindering attribution; hope that helps. Thanks, doing likewise below. I've tried to manually reconstruct the quoting; apologies if there are errors. >> > using a resolver self-identified in the Javascript? So DNS resolutions are instantiated and consumed by Javascript without any intermediation by the local DNS resolver or the browser's DNS rules? >> >> What does "a resolver self-identified in the Javascript" mean, exactly? >> >> Are you supposing some sort of rendezvous system where I can "install" a DOH resolver from one origin and have it affect requests sent to another? > > Can I have JavaScript retrieve a resource like https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example then use the result in place of the browser's DNS routines or the system DNS routines for retrieving https://www.major-search-engine.example/ within that JavaScrit application? No. The most you could do -- assuming when you say "JavaScript application" you mean Web page (because JS can be run elsewhere, e.g., NodeJS; what's important is the constraints that the environment put upon it) -- is reuse that result within that page (and thanks to Service Worker, the origin as well, unless other pages opt out of SW), yes you can, today. Mind you, there's nothing special about the proposal on the table that makes it easier. Also, doing so is pretty tortured for very limited gain; off the top of my head (handwave warning) you'd need to install a SW (or without it, create a bunch of event handlers in the page itself) to intercept requests, do your faux DNS, and then handle the response. This would work for embedded assets (e.g., JS, CSS, images) reasonably well on modern browsers, I think, but once you follow a link to another origin (or page, if SW isn't used and you don't control that page), the "real" DNS used would show up in the location bar, and you'd lose the ability to interfere. This has been done before, e.g., people doing "live" load balancing / etc. from JS. > If that is possible, then I need to know where the DNS data retrieved can be reused and I need to know whether the rendering distinguishes in any way between data so retrieved and data retrieved by a more trusted element. Outside the context in which it was loaded? Nowhere. > Does the data end up in the browser's DNS cache? >From random JS (SW or otherwise) on the Internet? It doesn't. The only way that JS can affect the DNS cache is to request lookups, which uses the configured resolution mechanism, not what the JS asks it to use. I.e., there is no proposal on the table to have a new JS interface 'setDnsResolver()', AFAICT. If the user configures the browser to use the DOH service, it might indeed cache the results (in the DNS or HTTP caches; probably the former, because perf on the latter is a problem in most browser implementations). Security considerations might be needed for the case when a user transitions from DOH to anther resolution mechanism -- but really that's not much different than changing your system DNS resolver. > Does a hover over an element show that this URI would be using a JavaScript supplied resolver to retrieve the location should I click? That's not actually specified behaviour anywhere, last I looked. >> Doing so isn't possible on the current Web, so enabling it would require some fairly heavy lifting at the W3C and/or WHATWG (which on the face of it, they're not likely to think is sane). I can only hope that defining such a thing is out of scope for this WG, as we truly don't have the expertise here. > > Interestingly, that's not what I understood others' answer to be. Their view was that since https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example was within the initial-origin, resources from it would be treated as same origin. If I understood correctly the code that would limit those resources to same origin isn't present and would have to run after the UDP wireformat was parsed (otherwise there are trivial attacks in returning additional data that cache poisons whatever the scope of use turns out to be). Same origin for the purposes of what? The use case here is really, really ill-defined. >> > > There are serious attacks here that even DNSSEC won't catch, because a malicious server and cooperating JavaScript app could give correct answers that are non performant (like the search engine instance on the most distant continent). >> > >> > Who would be consuming these answers? How is this different from configuring your system to use a malicious DNS resolver (either in an application or the OS)? >> > >> > Because the JavaScript you download could pick the resolver. The OS and browser are largely trusted; the JavaScript is largely not. >> >> OK, this seems to indicate you *do* think that somehow arbitrary JS can take over DNS resolution for the system or browser. What led you to that conclusion? > > The goal to use this as a swappable facilitating protocol for DNS resolution led me to that conclusion; in that usage, the resulting DNS data would populate the relevant DNS cache. Re-using the same system within JavaScript naively would have very bad properties; some segregation to handle the different levels of trust is required. OK. If I read you correctly, you seem to be assuming that browsers (and other systems?) will somehow automatically handle responses that use a particular media type (or a specific URI scheme, or whatever) with elevated privileges (e.g., inserting them into the browser/OS DNS cache). I don't think this is part of the proposal. If someone has proposed that, please to point to the message so we can engage that idea. >>> > I don't know that browsers want to do that, mind you, I'm simple saying that the working group could decide that this was a reasonable facility to consider. Ruling out ways for the ecosystem to distinguish this from other web resources seems to be the wrong way to go, at least to me. >> >> Again, I don't think this WG should be attempting to allow any sort of automated control of browser or system DNS resolution from the Web (e.g., JS, triggered by arbitrary URI schemes, mime types, whatever); I've seen zero desire from any implementer to allow that, it's fraught with security, privacy and other issues, and has dubious benefit. > > Should I take it that you disagree with the assertion that if we build for goal 1 (a swappable facilitating protocol) that we have automatically built a mechanism that is callable within a JavaScript application (which, as I understand it, Adam and others believe)? I think Adam and others believe that you *could* use this protocol from JavaScript (in a Web browser or otherwise) in a limited fashion (as outlined above), in that you would be bound by the security model of the environment you're working within. I don't think that is a major use case for this work, but it is a possible one. I don't think that anyone wants to establish new Web APIs to allow JavaScript to manipulate the browser/OS DNS resolution process or state. I certainly do not. Adam et al - If these statements aren't accurate, please say so. More to the point, the IETF is *not* the appropriate venue to be making core changes to the browser security model; at the very least, if we were doing that, we'd need to be coordinating *very* closely with the Web Application Security WG in the W3C. >> The use case that I believe most have in mind is "as a user, I want to configure my [browser, OS] to use *this* DOH service for DNS resolution" -- where that configuration is manual; e.g., a configuration textbox or dropdown in the browser, or a file in /etc. It might be made more user-friendly; e.g., it could be automatic when the user goes into the ill-defined "private mode." > > Would you consider a system in which the local browser or OS tested for the availability of a DOH server at a supplied address within scope (that would be one way to re-use the current DHCP-supplied servers, for example)? Possibly. "Manual" is probably the wrong word above -- the important part is that it's not under the control of a Web API for browsers. I doubt we'll consider it in-scope to specify other mechanisms (e.g., we don't control POSIX), but a protocol augmentation along those lines *might* be in-scope (although I'd prefer to leave it out; the more we put into this WG, the more chances of getting distracted by shiny things). >> The current charter allows that. I *think* the issues you're concerned about are in a very different area -- roughly, "automated control of DNS resolution." I'm not sure where you got the sense that this was on the table, but if it will help, write it out of the charter. > > My concern isn't just that it be out of scope of the charter, its that it either be not in the capability set of the resulting work or well-handled in that context. As above, defining this protocol won't change the capability of Web scripting by even the smallest amount. People do what they can today, and those capabilities will be the same after this is defined. > Folks asserting that it could not be eliminated from the capability set for JavaScript applications caused me to focus on the latter. If the work can be constrained such that this does not arise, so much the better. It's not a matter of constraining the work; the work isn't proposing to operate even remotely in the way that you describe. I think we're just having a misunderstanding, because people have multiple use cases in mind for this protocol, and properties thereof have been mixed up. AIUI those use cases are, roughly: 1. Configure your browser/OS to use a DOH service for DNS resolution (as above) -- this will affect browser/OS state, because it's being used for DNS; however, it's not being done from JS. 2. Call a DOH service from Javascript (for some reason) -- note this is just like any other HTTP request; it doesn't affect browser/OS state outside of the same origin model. Yes, you can still build a browser-in-a-browser and mess with things inside that context, but that's already true today. 3. Future handwavy things like making DNS updates over HTTP -- very ill-defined and not important for this discussion -- Mark Nottingham https://www.mnot.net/