Re: [Add] fixing coffee shop brokenness with DoH

[Brian Dickson <[e-mail]>]

On Wed, Jul 24, 2019 at 7:40 PM Rob Sayre <[e-mail]> wrote:

> On Wed, Jul 24, 2019 at 4:53 AM <[e-mail]> wrote:
>
>> This is a good point; there are valid reasons why 1.1.1.1 can be the
>> right provider for some users. Please allow me to clarify some possible
>> misunderstandings.
>>
>>
>>
>> I’m not against DoH.
>>
>> I’m not against privacy and security.
>>
>> I’m not against user choice.
>>
>>
>>
>> These are all valuable things we should strive for. Let’s do it in a way
>> that works for everyone, by identifying and documenting best practice.
>>
>
> I think the issue is that this request for collaboration can be viewed as
> a request to undermine DoH with follow-up RFCs.
>
> I understand that people come to the IETF with many different viewpoints,
> so I don't see this disconnect as a problem. But it is worth pointing out,
> and trying to understand.
>

I'll jump in ...

There are some generally positive benefits to having some (but certainly
not all) applications speak DNS natively.
(The precedent of mail transport software doing its own DNS is a good
example, including understanding why: mail software needs direct access to
e.g. MX, SPF, DMARC, and DKIM records, and to a lesser degree, PTR.)

In particular, having some applications be able to request record types
other than A/AAAA/PTR via POSIX interface (getaddrinfo/gethostby* calls) is
an important benefit; doing DNS more directly avoids having to address the
whole POSIX API thing. (That can be done at a later date, or not at all.)

Speaking "DNS" facilitates lots of very useful use cases to applications,
in particular to browsers, that are not otherwise feasible today. (E.g.
DNSSEC validation, DANE records, HTTPSVC, etc.)

However, there is no specific requirement that these applications "doing"
DNS need to bypass the ENTIRE host OS' DNS stack or avoid using other
host-local DNS services/mechanisms.
E.g. it would be reasonable to have a local forwarding-only caching server
(which forwards to a full-feature resolver, using an unspecified
transport), which better scaling attributes including cache hits, and
avoids divergent application-specific resolution including different
choices of full-feature resolver.

Also, privacy can be implemented on that caching server, by either of DoT
or DoH. There is approximately zero trade-off between the two (DoH vs DoT),
other than the larger issues (monitoring/filtering DNS resolver
destinations at a network level).

NB: the new DNS RFC for DNS stateful operations (DSO, DNS Stateful
Operations) covers a lot of the details on how clients and servers can
optimize their interactions, including (IIRC) some DoT guidance.

Some of the concerns regarding how to resolve the natural tension between
user choice, and client (host) administration, is probably better handled
by having the "user" choice be restricted (by design) to admin-priv
operations.

I would definitely prefer that DoT be the solution of choice for privacy,
primarily because it avoids almost all of the pitfalls of DoH when it comes
to any environment that relies on DNS-based security and monitoring.

There is a place for DoH, but I don't believe it should see wide deployment
in general-purpose browsers.

I have yet to see any use case other than the very specific "dissidents"
used to justify DoH.

All of the testing (which I've basically just glanced at as summary info)
suggests that DoH and DoT perform very similarly.

And, finally, from what I understand, all of the major public resolver
operators offer their services on both DoT and DoH (and v4 and v6, and in
many cases with or without filtered results).

So, in my version of a perfect world, the integrated browser DNS stack
would be:
browser <-> (local/internal loopback-type interface) <-> caching DNS
forwarder <-> (DoT) <-> {enterprise | home | public} full recursive resolver
And the browser would speak native DNS, with DNSSEC validation, DANE
support (natively, not plug-in), HTTPSSVC, CNAME/DNAME following, etc.
The caching DNS forwarder would have all the same stuff plus DNS cookies,
not do fragmentation, and potentially have multiple full resolvers
configured in a structured priority flow (not just round robin).

IMHO, this is what ADD is supposed to be about, discussion the what and the
how.

And, also IMHO, it does not preclude comparison of DoT and DoH on the
respective merits and risks/costs.

Brian
P.S. Any animosity towards DoH has very little to do with the process by
which it was developed, and everything to do with the incompatibility with
existing practices and ecosystems, especially unintended impacts. It isn't
the encapsulation of DoH that is the problem (it's slightly annoying), but
rather the re-use of port 443 instead using a dedicated port the way DoT
uses 853.

P.P.S. The responsible approach to adopting a flawed protocol, would be to
acknowledge the flaws, find a better solution, and kill it off, rather than
defend it or justify it based on sunk cost or other rationales. I would
advocate this approach even if it was my sacred cow that was being gored.