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

[Michael Sinatra <[e-mail]>]

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?  If applications
choose which DNS server to use without the informed consent of the user
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.

IMO, this mess started for two reasons:

First, DoH advocates internalized 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.  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