Howdy,
Comments in-line, with some snippage to help keep it readable.On Wed, Sep 20, 2017 at 12:15 AM, Mark Nottingham <mnot@xxxxxxxx> wrote:
>> 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. then use the result in place of the browser's DNS routines or the system DNS routines for retrieving https://www.major-search-major-search-engine.example engine.example/ within that JavaScrit application?
No.
The most you could do -- assuming when you say "_javascript_ application" you mean Web page
Yes, I mean _javascript_ application downloaded into a browser.
(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.
I have to disagree with this. Standardizing this method should make this easier by having a common format produced by servers and consumed by clients.
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,
So the scope of the problem is: a malicious piece of _javascript_ can embed a DNS service into a web page such that some resources can be retrieved using its resolution rather than the browser or system library. It's not clear how the user would determine that this was the case, so there is a risk of mis-attribution within the web page.
That there is no intent to allow that information to be further propagated is certainly useful to know, but if I understand you (and Adam) correctly, this problem must be handled somewhere because of the intersection of this proposal and _javascript_ capabilities in a modern browser.
As a charter question, is the description of the problem and/or proposals around it in scope for this proposed working group, or do we need to pass th problem to someone else. If someone else, who?
>
> 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 think you and I agree that if an OS or browser configuration frob specifies a recursive resolver that uses DOH, that the results go where ever they would have gone had the same information come in via UDP, TCP, TLS, or DTLS. From the information in this email, we agree that taking DNS responses from a DOH recursive resolver specified in a download _javascript_ application would currently be limited to that application and those from the same origin (and that building anything to take it further would be unwise). There's some work to do on how to handle misattribution within that context, but it is not the same scope as the OS/browser configured data.
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.
Should we be passing the charter by the Web Application Security WG in the W3C now for comments?
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.
It will change the relationship of that Web scripting capability with the DNS (or at least make that relationship much easier). Given where the DNS is in our stack, that's an important change. If an attacker can take information from an origin and have it treated as DNS data, it become the foundation of retrievals from other origins.
To hideously over-simplify, the same origin security model presumes that resources from an origin share a scope. But if the origin is a recursive resolver among other capabilities, the resources retrieved may provide data about where to get other resources from outside that scope.
As long as there no APIs which push that data past the same origin boundary, the problem with that is limited to misattribution within the same origin. But it is still a problem because of the role DNS info plays.
As long as there no APIs which push that data past the same origin boundary, the problem with that is limited to misattribution within the same origin. But it is still a problem because of the role DNS info plays.
> 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.
Agreed, and I think this a very valuable piece of work to get done, especially for the multiplexing properties of H2 or QUIC.
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.
While this is no doubt unintended, this tends to give a "everything is already ruined" flavor to your response. If we're standardizing this, I think we need to take how this data is integrated and presented as part of the overall deployment problem. If we're not the right folks to do that part of the work, I think we need to get the right folks involved as soon as possible and to put coordination with that community into the charter along with DNSOP and the others already listed.
3. Future handwavy things like making DNS updates over HTTP -- very ill-defined and not important for this discussion
Yeah, I can't even tell from this whether you mean clients updating their info a la DNS dynamic update a la RFC 3007 or you mean push style updates of fresh responses from a recursive resolver. You can certainly leave the first out. Whether you can leave the second out or not depends on an interaction between the HTTP caching model and the DNS caching model (That is, if a configured DOH server pushes a new response to a query that hasn't been asked yet, it would go into the HTTP cache in anticipation of the question being asked. When, though, that would get parsed and turned into DNS data isn't clear to me.)
regards,
Ted