Re: [Doh] Mozilla's plans re: DoH

[Brian Dickson <[e-mail]>]

On Wed, Mar 27, 2019 at 7:50 PM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 27/03/2019 17:34, Brian Dickson wrote:
> > dissident mode
>

If you are going to quote me, please do me the courtesy of doing so
correctly.
I wrote ' "dissident mode" ', not 'dissident mode' (i.e. it was in quotes,
to indicate that I recognize its connotations, but that there is no short
phrase that captures the nuances.)

I am open to alternate terms, provided they also capture the nuances.

(I would also note that the person from the ACLU was specifically referring
to dissidents, it was not me alone who used the term.)

What I would like to distinguish is:

   - Persons whose safety requires that their communications and DNS usage
   be encrypted to trusted servers; persons who do not have alternative ways
   of accessing trusted DNS, and who by necessity must take actions (using
   third party encrypted DNS) which may be in violations of laws, contracts,
   or terms of service (which may be unconscionable but technically legal);
   persons who are acting in solidarity with the aforementioned folks, or
   participating in acts of civil disobedience, and
   - Persons who are taking advantage of legal, permissible, explicitly
   allowed, and openly available third party DNS over encrypted channels, and
   refraining from such usage if access is blocked.
   - From a technological basis, the desire is to facilitate this
   distinction at scale. One obvious mechanism would be to use distinct TCP
   port numbers, even if the DoH server is the same (and the same IP address
   and TLS certificate are used).

To facilitate the ongoing discussions, we need some suitable label for the
former.
If you find the term I originally used objectionable, please provide one
for the first group, DISTINCT FROM any corresponding label for the second
group.

Making assertions that the two groups are actually one group is much worse
for the ongoing discussions, and would be materially inaccurate,
deliberately conflating the two groups, highly counterproductive, and
inflammatory. I would politely ask that you refrain from doing so. (I am
not claiming that you have done so, I'm just trying to dissuade such in
anticipation of the possibility.)

I welcome any label you prefer for the first group.

For the second group, any different label from the first group would be
fine; I'd suggest "privacy-aware". They use privacy by choice, not by
strict necessity (on threat of violence or death), and are freely able to
make that choice with no personal consequences.

What I am interested in pursing is ways to protect the first group, while
enabling the ability for legitimate enterprise policy enforcement (e.g.
blocking) to be done scalably.
E.g. Make the traffic of the second group identifiable, and to encourage
(or require) that how browsers implement the access to the third-party DNS
services over encrypted channels, provide a scalable way for networks to
block usage for the second group.

Here is why having an easy way to distinguish the two groups, at a network
level (i.e. TCP port), is important, IMHO:
The best protection for the first group, is to have them easily
distinguished from the second group.
The logic is a bit non-obvious, so let me attempt to explain.
The typical volume of traffic by all members of the second group, is likely
to be significantly higher than the first group.
If enterprise networks have ways of blocking the second group, and if the
users in the first group only enable their specific "mode" for limited
intervals, the occasional burst of traffic from the first group won't
likely result in the enterprise wanting to attempt to block the first
group. This has the benefit of not having persistent use of the mechanisms
of the first group, and doesn't create the residual risk (e.g. of malware
abuse of the first group's DNS traffic).
On the other hand, if the exact same mechanism is used by both groups, and
there is no practical/simple method of blocking only the second group, the
resulting scenario is lose/lose/lose (possibly more "lose" terms).
The enterprise would need to employ costly (due to not being scalable),
possibly less reliable/available border enforcement, or risk any of the
side effects of unconstrained/unblocked DNS carried outside the enterprise
via encrypted transport. The impact to the users would be uniform; the
second group would be inconvenienced, while the first group would lose
their necessary (by definition) DNS privacy.




>
> As stated at the side-meeting, I think the above phrase is
> counterproductive and inaccurate and it'd be a fine thing
> if we stopped using that kind of wording.
>
>
It may be counterproductive, but it is accurate.

I am distinguishing two use cases, even when the same underlying technology
is employed (DNS carried via HTTPS). One is where the user would like to
use the technology, and where the access may or may not be permitted, and
the user does not exceed the permissions (and thus either uses a different
provided DNS service, possibly encrypted, possibly not, or does not user
the network at all.) The other use case is where the user must use the
technology without regard to whether this activity is permitted.

The first group is best categorized as dissidents. From an online
dictionary:

>  a person who opposes official policy, especially that of an authoritarian
> state.
> "a dissident who had been jailed by a military regime"
> synonyms: dissenter, objector, protester, disputant; freethinker,
> nonconformist, independent thinker; rebel, revolutionary, recusant,
> renegade; subversive, agitator, insurgent, insurrectionist,
> insurrectionary, mutineer; informal: refusenik
> "a dissident who had been jailed by the regime"


If you object to the phrase, please provide a semantically equivalent but
inoffensive phrase.

Brian

P.S. It may not be clear, but I definitely am in favor of providing DoH to
everyone who requires it, i.e. members of this specific group.

P.P.S. I disagree with "conscripting" unaware users into using the same
mechanism using opt-out, always-on resolution via DoH to third party
providers. Doing so may place them in jeopardy of one form or another, and
is especially objectionable when it is done without explicit and informed
consent. The other reason for using technology to block only the second
group, is to protect any users who accidentally leave an application or
device in the "privacy" mode, when they are on a network which prohibits
encrypted access to third party DNS providers. The blockage protects the
network; the requirement for explicit user consent to break network policy
(and bypass the blockage) is what protects the wayward, innocent user.