Re: [Doh] [Ext] panel discussion on DoH/DoC

[Eliot Lear <[e-mail]>]

Hi Paul,

I agree with those who say that we are really in the realm of a policy and research discussion.  I want to focus on the latter below, just a bit.

> On 7 Feb 2019, at 16:36, Paul Hoffman <[e-mail]> wrote:
> 
> On Feb 7, 2019, at 5:08 AM, Ted Lemon <[e-mail]> wrote:
>> 
>> On Feb 7, 2019, at 8:03 AM, Stephane Bortzmeyer <[e-mail]> wrote:
>>> The protocols are not innocent (they enable, they encourage, they
>>> discourage) but they are not everything either. The dominance of Gmail
>>> is not written in RFC 5321. DoH helps DoC ("helps", not "enables", DNS
>>> over HTTPS was possible before), it does not decide DoC.
>> 
>> Of course, but in fact it appears that one of the primary use cases for DoH is DoC.
> 
> That became a use case after the document was mostly finished.


What I am struggling with is what we think DoC is.  Is Google a could provider in this context or not?  If so, I think many of us were expecting that Google would offer DoH alongside 8.8.8.8 precisely to address the issue directly below.  And what I find interesting is that this seems to move the problem from one control/observation point to another.  And so this brings up a key research question that would be useful to answer, and perhaps those at FF and Chromium could answer it:

Is there a suitable user interface that will keep users from harming themselves with DoH?

That question itself begs the question, “How could a user harm him or herself with DoH”?   That is in itself a research question, but at least let me give one analogy to show how that might happen: consider the fly-by-night-shady-VPN-for-free providers that spy on all of your traffic, advertising at users who say, “we’ll get you around all DNS blockers.  Just click here to change your settings, and it will all Just Work.”

I think that’s what Joe and CDT are out to stop with the code of conduct (maybe I misunderstand), and it argues against a user knob.  It might be possible to provide users some sort of intelligent choice, and I would imagine that some of the players have put some serious thought into it.


> 
>> I would have thought that the primary use case for DoH was to bypass network censorship, but when I suggested as much during the discussion on the draft, the response I got suggested that the authors really hadn’t had that in mind, and that indeed the use case they had had in mind was DNS resolution in HTTP sessions by Javascript clients.
> 
> You are probably misattributing, or misremembering, this discussion. It certainly wasn't me, and I'd be quite surprised if it was Patrick. Both of us were motivated to bypass network censorship. We *also* had a secondary use case, which was real DNS resolution by JavaScript applications (not "clients”).

This matches my (perhaps faulty) recollection.

> 
>> Which is, pretty much, DoC,
> 
> Centralizing resolution on chosen providers has nothing to do with "cloud" unless the user choose a cloud provider.

I think one of us (perhaps me) is being pedantic about the definition of cloud.

> 
>> although not the use case that subsequently emerged, where browsers do it instead of using the local resolver.
> 
> A browser vendor (Mozilla) does use a cloud provider as their default DoH server. That browser vendor has not explained why.

And what I would suggest is that we need a crisp problem statement, but I do not see a protocol issue here either (at least not yet).

I do see a potential protocol issue for enterprises, in as much as split-horizon is a thing, but I don’t know if that should be addressed inside DoH or through some other means such as an MDM, where configuration is tweaked to address it.  We’ve discussed that here before (long ago).  The protocol part I could see would be some nifty signal that indicates that split horizon is in effect in some way.  And it’s not strictly doh, but perhaps just a reserved RR of some form (being very speculative here).  But even that would be subject to abuse.

Eliot