[There is actually a proposal at the bottom of this e-mail. Bear with me.]

On 20 Mar 2019, at 11:09, Jared Mauch <ja...@puck.nether.net> wrote:

> Often as an industry we may discuss various solutions that are great for 
> oneself but don’t scale when looking at the big picture.

I think what we are seeing is the fundamental tension between privacy and 
control. You need to give up some privacy in order to make the control 
possible; you need to give up some control in order to afford privacy.

Some in this thread want certainty that they are able to exercise control, e.g. 
for devices in their network.

Some in this thread want certainty that they can obtain privacy, e.g. for for 
their device in any network.

When those people meet, the pitchforks come out. This is already true today; 
it's not a new DoH problem. I think the balance of the tensions has shifted 
with the prospect of a change in default behaviour, not because any of this is 
fundamentally new. The change in defaults tips the power balance (e.g. the 
balance of cost) between control and privacy. This is Paul's basic point, I 
think.

Some people seem to be getting worked up about whether the desire for control 
is more important than the desire for privacy. I don't think that question has 
an answer, but I think most reasonable people could acknowledge that both 
positions exist. This is Stephen's basic point, I think.

It's possible today to communicate over covert channels in order to avoid 
control. This is different from *all* communication happening over covert 
channels so that no control in the future is possible. That's not how things 
happen today; that would be a change, a new situation. This is your basic 
point, I think (that's how I read "scale" in your e-mail, above).

Seems to me that there's a middle ground within sight here.

Standardise this privacy mechanism, and specify (with reasoning) that it should 
be implemented such that the existence of the channel (but not the content) can 
be identified as distinct from other traffic by third parties. Maybe specify 
use of a different port number, as was done with DoT.

Those who choose to ignore that direction and create a covert channel using 
port 443 instead will do so. Nothing much we can do to stop that today (I 
guarantee it is already happening). The future is not really different.

Of course when people shift the focus of the conversation from DoH in general 
to resolverless DNS, and want to interleave DNS messages with HTML and cat GIFs 
over the same HTTPS bundles, the pitchforks will need to come out again. So 
keep them handy.


Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to