Re: [Doh] WG Review: DNS Over HTTPS (doh)

[Ted Hardie <[e-mail]>]

On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham <[e-mail]> wrote:

>
> > So, I don't that this is established.  One mental model for this work is
> that DNS, having started with UDP and TCP as transports, has now added a
> set of additional secure transports.  Two of those were defined in DPRIV;
> this defines another.  From that perspective, any time an application
> requires a DNS name to be resolved, the relevant local code would try the
> set of secure transports until it got an answer.  The application may not
> know which is used and does not specify it; it is simply getting the DNS
> answer back that allows it to proceed.
>
> Every time people start talking in this manner and referring to HTTP as a
> "transport", I get flashbacks to WS-* and what a glorious failure that was.
>
>
If it helps, I am happy to say "facilitating protocol".  The mental model
question for the charter is really:

Does this add a new tool for DNS systems attempting resolution to use when
previous efforts are blocked?  So any DNS resolution might use it, whether
from a browser, an app, or system call, but that those would not *specify*
it be used?

Does this add a method for Web application to directly resolve DNS resource
records 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?

Does this charter aim for the working group to do both?

As currently written, I see the charter describing 1.  There has been an
argument that it also do 2 or that 2 becomes possible when 1 is specified
and is thus automatically part of the scope.  If that is the case, I
believe the charter needs a re-write to describe it.


> > The name of the group (DNS over HTTP), the justification at the
> beginning of the charter:
> >
> > This will enable the domain name system to function over certain paths
> where existing DNS methods (UDP, TLS, and DTLS) experience problems. This
> will enable the domain name system to function over certain paths where
> existing DNS methods (UDP, TLS, and DTLS)
> > experience problems.
> >
> > and Paul's input draft all point to that interpretation.  Note
> especially that Paul's draft provides the UDP wireformat as response.  To
> me, that strongly hints that the results of this get handed to the same bit
> of code that would take the UDP wireformat from other transports (like UDP)
> and do what it would have done with data retreived from any of those.  That
> behavior makes sense for DNS transported over HTTP, where you are talking
> to an authoritative server or shared resolver over a new transport.
>
> I don't disagree that the charter lays out that the goal is to enable the
> use case of DNS using HTTP semantics -- that's hopefully uncontroversial.
>
> > That order of operations does not make sense as a new resource type
> available to web applications, in part because they can't tell from
> examining the URI whether the resulting *resource* obeys CORS or not.
>
> It's not clear why that's an important property. Why is it necessary?
>
>
If it goes into a browser or system cache, it is an important property; it
may also be important depending on the UI result.  If the
JavaScript-internal resolution process feeds other parts of the page, it
may even be a problem.


> > 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.


> > And, if there really was a handoff to the local DNS subsystem for
> parsing and processing, the JavaScript also wouldn't be able to tell
> whether the result they get from that subsystem is the one that the just
> retrieved (because a cache entry from some other system may have a
> different SOA record and be returned as a result instead).  To avoid that,
> they would have build udp wireformat parsers into the downloadable
> javascript.
> >
> > I think if you want the second, a way of making DNS resources available
> to web applications, you need a very different approach; it may be
> valuable, but I don't believe this charter covers it.  If it is meant to,
> it needs a major re-write.
>
> I agree there are significant risks when using DNS. I think the question
> is what to do about it.
>
> One thing the WG could do would be to write some Security Considerations
> about the different ways this could be sub-optimal or even dangerous.
>
> I don't see how giving the protocol a new URI scheme avoids these risks,
> given that the defined resources would be available over HTTP still.
>
>
It gives the browser something to look at.  If it rejects udp-wireformat
mime types being returned from HTTPS URIs but accepts them from dnsh URIs,
it can handle the data differently.  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.

regards,

Ted



> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>