Re: [Add] fixing coffee shop brokenness with DoH

[Rob Sayre <[e-mail]>]

Hi Brian,

I'm not sure what you're trying to say.

thanks,
Rob


On Wed, Jul 24, 2019 at 7:19 PM Brian Dickson <[e-mail]>
wrote:

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