Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues

[Stephen Farrell <[e-mail]>]

Hiya,

On 10/04/2019 23:29, Michael Sinatra wrote:
> 
> 
> On 2019-04-10 13:50, Stephen Farrell wrote:
> 
>>> This whole mess started, IMHO, because some parties are treating the DNS
>>> as an application service, and not as part of the infrastructure and
>>> network services.
>>
>> I don't think that's accurate. My take is that DNS privacy work
>> started for perfectly valid privacy reasons and that DoT (while
>> a fine thing) wasn't the right tool for some who need that better
>> privacy... hence DoH.
> 
> I realize you realize that begs the following question... :-)
> 
> What's "better" about the privacy afforded by DoH? 

Eh.. that was in the paragraph from which you quoted above... in
the bit you didn't quote;-)

Basically, if the application wants to know that DNS privacy
is being applied, it has to do it itself. (There are other
arguments, and I'm not a browser-maker so they may have other
reasons they think more important.)

> If applications
> choose which DNS server to use without the informed consent of the user

I've already disputed the possibility of informed consent here.
(And will do again below:-)

> or in ways that obfuscate the DNS transaction and undermine the user's
> control, that potentially _erodes_ privacy.  If DoH encourages network
> administrators in certain regulatory (imagined or real) domains to do
> inline TLS decryption, that potentially _erodes_ the user's privacy.

Yes, if people bugger about MitM'ing TLS, that harms us all.

Every time we see an interesting uptick in use of TLS in any
sphere, we see claims that we'll be overwhelmed by MitMs to
defeat that and arguments that the putative potential fault
for that lies with whomever is causing the uptick. The fact
that that keeps happening seems to be evidence that uses of
TLS between intended endpoints are not being overwhelmed in
that way. That's a good thing IMO even if there are a few
more MitM attack boxes deployed than previously when pretty
much everything was in clear and utterly vulnerable.

In the current discussion, if you do control the client endpoint,
then manage that well and you'll have no need to bugger with TLS
at all. If you do not control the endpoint (or are inept in
doing so) then I'd be interested in how you propose to go about
MitM'ing TLS.

> 
> IMO, this mess started for two reasons:
> 
> First, DoH advocates internalized 

Your or my guesses as to who internalised what seem unlikely to
be a useful part of the discussion. (You'll note I framed my
explanation in terms of what's visible-to/controllable-by different
bits of s/w running on a machine, and not in terms of people's
motivations, which I think ought not be a topic for discussion
here.)

> a particular definition of privacy and
> made the assumption that DoH maximized privacy according to that
> definition, within the constraints of a particular set of use-cases.
> Based on the debate in these forums, it doesn't feel like DoH advocates
> considered the full range of use-cases, and how different sets of users
> define "privacy."
> 
> Second, applications developers like Mozilla made the assumption that
> their vetting of DNS providers was sufficient to justify announcing
> their intent to use said providers by default, rather than leaving that
> decision as a user opt-in.  (And the announcement of intent was enough
> to create this mess, even if they didn't or won't follow-through.)
> 
> It's perfectly reasonable to say that DoH improves certain aspects of
> privacy under certain use-cases.  It's also reasonable to recognize, and
> appropriately disclaim, that there are use-cases and circumstances where
> DoH can undermine privacy.  This is why I believe we need to continue
> work on draft-reid-doh-operator-00,
> draft-livingood-doh-implementation-risks-issues-03, and
> draft-bertola-bcp-doh-clients-00.
> 
>>> Having individual applications do that without the informed consent of
>>> their users is over-reach, IMHO, whatever their lawyers write into their
>>> shrink-wrap licenses.
>>
>> Partly agree. I hate the license-crap the s/w business involves so
>> agree with you there. OTOH, I disagree that informed consent is at
>> all feasible here - we simply cannot expect a typical user to spend
>> literally hours of work needed to really understand the issues here.
> 
> I think your definition of "typical user" is unduly narrow.  Regardless,
> DoH doesn't absolve the user from understanding the issues at hand.  It
> simply migrates the management of a component of the user's personal
> information from "network" to "application," potentially without
> informing the user or letting them opt-in.  IMO the IETF can and should
> take a stand that this is not the desired BCP for DoH.
> 
>> And without understanding there can be no informed consent, except
>> perhaps in some weasel-wordy manner. IOW, I think arguments about
>> consent here are about as convincing as asking that people look up
>> BGP information before allowing their packets be routed.
> 
> I think your analogy is wide of the mark. 

My argument was not an analogy.

To re-iterate:

"without understanding there can be no informed consent"

is the core of my argument on this part of the discussion. I'm
quite happy to defend that proposition (which is not an analogy).

Cheers,
S

> The correct analogy would be
> having users select network providers on the basis of their privacy
> policies and their routing hygiene (prefix filtering, MANRS-compliance,
> origin-validation practices, etc.).  You might say, "but not all users
> do that!" and you would certainly be right.  But some do take those
> factors into consideration (or they ask knowledgeable folks to make
> informed recommendations) and they should be given the necessary
> information to make an informed decision.  And the IETF *can* influence
> this through BCPs.
> 
> michael
>