On 21 Sep 2017, at 3:17 am, Ted Hardie <ted.ietf@xxxxxxxxx> wrote: > >> 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. In the case you're concerned about -- hostile JS -- the server that hosts the malicious JS is the same party that produces the poisoned DNS response. Even if it's cross-origin, the attack implies that they're coordinating. Defining the wire format for those messages is trivial; I suppose we're doing a small amount of work for them, but that work isn't any barrier to the attack. > 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. No. The scope of the problem is that once someone malicious has Javascript executing within a context, it's effectively game over for that context. Much of the focus of Web Application Security over the last few years has been on reducing that attack surface, especially where it's not intentional (e.g., CSP). Again, there is no magical way for JavaScript to plug itself into the system DNS library. There *is* a magical way for JavaScript to monkey patch pretty much anything within the page load -- that's what we're talking about here. What this WG does doesn't affect that ability, even on the margins; it's already there. > 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. This is a pre-existing risk, and browser vendors, the WHATWG and W3C have spend significant time considering and mitigating it (in a nutshell, only trust the browser chrome, which is *not* under the control of JS). We do not own this problem. > 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. It's already handled. > 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? It's not in-scope here, and since it's already handled, we don't need to pass it anywhere else. > 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. Yes, provided it was from the same source. > 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). Where 'context' is defined by the Web security model (which, like DNS, is specified a bit all-over-the-place, but still works somehow) -- yes. > 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 strongly disagree that there's work to do -- this is already within the existing security model of the Web platform. > Should we be passing the charter by the Web Application Security WG in the W3C now for comments? If that would help us move along, sure. >> 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. Right, but this is already possible today, and easy for someone to implement, because the Web allows you to create little protocols between JS and the server on-the-fly. >> 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. That indeed wasn't intentional; the Web still works pretty well, although I wouldn't bet on the long-term stability of the hair colour of any given Web security professional. > 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. Imagine we're charting a working group for a financial data format -- it's important that it has integrity and authority, and it's a target for attackers, as are DNS records. The position you're taking seems to be (roughly) that we need to make sure that people don't use the standard financial data format to misrepresent other people's finances in the case that there's a malicious piece of JS on a Web page. Without trivialising that attack, having a defined format for the data doesn't change its nature (and remember, we're not even really defining a format; the current proposal is to reuse an existing format in HTTP messages), and (again) we lack the expertise and authority in this area. I'm fine if we feel we need to confirm this with WebAppSec or other parties before chartering. Beyond that, IMO adding any tasks to the WG's plate to address it is a poor use of the IETF's resources. -- Mark Nottingham https://www.mnot.net/