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

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Mar 2019 02:16:05 -0700

I’ve heard a number of questions about Mozilla’s plans around
DoH. We’ve made a number of public statements, but it might be useful
to try to put this all in one place.

In context, the problem we are attempting to solve here is attack on
the user’s name resolution from an attacker with full or partial
control of the network, as contemplated by Section 3 of BCP 72 as well
as BCP 188. There’s ample evidence of monitoring/manipulation of user
traffic via this vector [0][1][2]. Importantly, this includes cases
where the entity which owns the network infrastructure monitors and/or
modifies DNS requests and responses without the user’s consent.

With that problem statement, here are our plans:

    1. We have implemented DNS over HTTPS [RFC8484] and would like to
    deploy it by default for our users. We intend to select a set of
    Trusted Recursive Resolvers (TRRs) that we will use for DoH
    resolution. TRRs will be required to conform to a specific set of
    policies intended to protect user privacy. We’re still refining the
    final policy but we expect it to roughly match the one that Cloudflare
    has already agreed to use
    (https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/).While
    we expect the initial set of TRRs to be small, we’re interested in
    adding new providers who are able to comply with these policies.

    2. The precise details of the user interface are TBD, but we expect
    something like the following:

    3. Copies of Firefox will be configured with a set of TRRs. Different
    regions may have different TRR sets or different defaults. In addition
    we may have DoH/TRR on by default in some regions and not others,
    especially initially.

    4. The user will be informed that we have enabled use of a TRR and
    have the opportunity to turn it off at that time, but will not be
    required to opt-in to get DoH with a TRR.

    5. Any given client will automatically select a resolver out of that
    set and use that for all resolutions [with the two exceptions noted
    below.]  At any time, the user will have the option to select a
    different resolver out of the list, specify their own resolver, or
    disable DoH entirely.

We have heard a number of concerns about the ability of the network to
control the client’s resolver behavior. As noted above, just allowing
the network to dictate the DoH resolver would obviate the security
objective listed above. However, there are two more restricted cases
in which we do think some network control of the resolver is
reasonable.

In cases where the network has a preferred resolver that is on our
approved list we might want a mechanism like
draft-ietf-doh-resolver-associated-doh to guide resolver
selection. We’re watching that document’s progression carefully.

    1. In cases where the network also controls the client (e.g., they are
    able to remotely manage it via MDM), then they should be able to
    select the resolver themselves, disable DoH, etc.

    2. We realize that in the short run, the need for resolvers to be on
    our list creates some challenges for resolver operators.  We would be
    open to discussing how to adapt our security constraints to suit the
    needs of multiple applications, so that as more systems deploy
    DoH/TRR, they can share a list of resolvers vetted to a common
    standard.

There are still a few open issues that we have to sort out, but if
some of the above isn’t clear, I’m happy to try to explain. One thing
I am not able to provide is a detailed timeline. We are still
performing measurements [3] to determine whether users will experience
problems with DoH/TRR enabled, as well as figuring out precisely how
we intend to deal with split horizon DNS, and will need to address
these issues prior to shipping.

-Ekr

[0]
https://cdt.org/blog/dns-strengthening-the-weakest-link-in-internet-privacy/
[1]
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pearce.pdf
[2] Many networks redirect NXDOMAIN to a search/advertising page.
[3] For some of our previous experiments, see:
https://blog.mozilla.org/futurereleases/2018/09/13/dns-over-https-doh-testing-on-beta/
https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Mar 2019 02:24:28 -0700

Now with the numbered lists correctly formatted:

We have implemented DNS over HTTPS [RFC8484] and would like to
The precise details of the user interface are TBD, but we expect

    1. Copies of Firefox will be configured with a set of TRRs. Different
    regions may have different TRR sets or different defaults. In addition
    we may have DoH/TRR on by default in some regions and not others,
    especially initially.

    2. The user will be informed that we have enabled use of a TRR and
    have the opportunity to turn it off at that time, but will not be
    required to opt-in to get DoH with a TRR.

    3. Any given client will automatically select a resolver out of that
    set and use that for all resolutions [with the two exceptions noted
    below.]

    4. At any time, the user will have the option to select a
    different resolver out of the list, specify their own resolver, or
    disable DoH entirely.

-Ekr

[0]

On Wed, Mar 27, 2019 at 2:16 AM Eric Rescorla <[email-masked]> wrote:

>     (
> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/).While

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 27 Mar 2019 11:18:41 +0100

>     we may have DoH/TRR on by default in some regions and not others,

Can I suggest you pick a default behaviour and stick with it?  This idea of
having a different default configuration depending on what region the user
is in (at what point?  at the time they downloaded it?  installed it?  at
runtime? how big is a "region" and how are you determining which one the
user is in?) is going to be a bit of a support nightmare for IT departments
with users in different regions.

I'm also curious what your fallback plan is in the event that DoH is
disabled or unreachable.  One hopes DoT will be tried next, before falling
back to plan DNS.

---

From: Valentin Gosu <[email-masked]>
Date: Wed, 27 Mar 2019 11:22:16 +0100

On Wed, 27 Mar 2019 at 11:19, Matthew Pounsett <[email-masked]> wrote:

> Can I suggest you pick a default behaviour and stick with it?  This idea
> of having a different default configuration depending on what region the
> user is in (at what point?  at the time they downloaded it?  installed it?
> at runtime? how big is a "region" and how are you determining which one the
> disabled or unreachable..  One hopes DoT will be tried next, before falling
> back to plan DNS.
>

Firefox uses the system's resolver via getaddrinfo if the DoH server can't
be reached.
If the OS's stub resolver uses DoT, then that's great. Otherwise it's
regular DNS.

---

From: Kevin Borgolte <[email-masked]>
Date: Wed, 27 Mar 2019 11:58:09 +0100

> On Mar 27, 2019, at 10:24, Eric Rescorla <[email-masked]> wrote:
> 

Thanks, much appreciated!

>     we may have DoH/TRR on by default in some regions and not others,

Out of personal curiosity, does EU GDPR compliance/interpretation uncertainty play a role in regionally different defaults? For example, that a US-based DoH TRR if not opt-in could seen as a GDPR violation by Mozilla?

- Kevin

---

From: Neil Cook <[email-masked]>
Date: Wed, 27 Mar 2019 16:15:14 +0000

> On 27 Mar 2019, at 09:24, Eric Rescorla <[email-masked]> wrote:
> 

But Mozilla doesn’t know whether the modification is with or without the user’s consent. As the various drafts that have been presented this week attempt to make clear, there are a large number of use cases where users actively want the modification of their DNS (parental control, enterprise networks, malware/phishing detection, botnet C&C communication disruption etc.), indeed they may even be paying for such a service.

So the Mozilla answer to possible DNS modification without user’s consent is to enable over-the-top DNS resolution for all users, using an opt-out model (how a normal user is supposed to understand what they’ve been opted into brings up all kinds of user consent issues itself), and sending all DNS requests to a third-party with whom the user almost certainly has no relationship, contractual or otherwise, and potentially located in a third-party country.

To summarise, in an attempt to deal with a possible (but essentially unknown) issue of user consent, Mozilla "would like to deploy it by default for our users.” 

All the above seems rich with irony and contradiction.

Neil

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Mar 2019 16:32:24 +0000

>     different resolver out of the list, specify their own resolver, or

Will Firefox inform its users whether the local resolver supports DoT or
DoH?

> However, there are two more restricted cases in which we do think some
> network control of the resolver is reasonable.

What about allowing Firefox users to access private / internal domain
names?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
each generation is responsible for the fate of our planet

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Mar 2019 09:56:12 -0700

> Will Firefox inform its users whether the local resolver supports DoT or

We don't currently expect to do so. As noted above, we don't think secure
transport to the local resolver is sufficient to ensure the privacy and
security guarantees we are trying to provide.

> What about allowing Firefox users to access private / internal domain

If a name doesn't resolve with DoH, we fall back to the system resolver.
This doesn't work properly when the same name is available on the public
DNS but pointing to a different location. As I alluded to in my email,
we're still working out how to deal with this split horizon scenario.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Wed, 27 Mar 2019 18:34:24 +0100

> we're still working out how to deal with this split horizon scenario.
I think there are data leakage and enterprise-specific issues, above and
beyond this, but I think there are ways to limit that, and identify the
split horizon existence:

If you do QNAME minimization and compare the delegations returned from the
system resolver and DoH server, if they don't have identical results, that
should point to the need to use the system resolver.

I can't think of reasons why they would differ except for split-horizon,
and possibly geo-ip stuff.

Non-split-horizon stuff follows:

I'd like to suggest other tests for determining whether using a public
resolver might be contrary to network policy, and thus be indicative of a
need for explicit user approval (opt-in).

   - Make connection attempts to the public resolver's IP address on UDP
   port 53, TCP port 53, and TCP port 853 (DoT).
   - Success on any of those could be interpreted as that public resolver
   being permitted by network policy.
   - Failure on all of those should be interpreted as that public resolver
   not being permitted by network policy.
   - I would also like to suggest adding a standardized DoH-only port,
   where the DoH-only port is used when policy appears to permit access to the
   third party resolver.
   - And finally, I would humbly suggest that the DoH "shared" 443 (HTTPS)
   port be used only with explicit user permission, and only when none of the
   above ports are accessible, i.e. "dissident mode".

(IMHO, dissident mode should also engage, or require the user to have
previously engage, whatever the specific browser calls its privacy mode,
e.g. "incognito", "private", etc., so as to minimize any residual risk to
dissidents.)

There are host/network security reasons about why "DoH to third party, on
by default" is a riskier choice, or where the mechanisms of enabling DoH to
third party locations are easily accessible.
Malware C&C communication, and malware data exfiltration over DNS, are
host-specific concerns, whereby malware might take advantage of encrypted
DNS to offsite providers, by accessing the browser as a DNS vector.
Even if it doesn't raise the bar that much, taking it out of the realm of
"trivial" (i.e. requiring some activity on the part of malware to enable
DoH) would be preferable.

Brian

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Mar 2019 18:50:41 +0000

Hiya,

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

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.

S.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 27 Mar 2019 20:11:57 +0100

> if we stopped using that kind of wording.

+1!

We don't call HTTPS dissent mode as it's now table stakes for safely
browsing (e.g.,
https://https.cio.gov/everything/ )
-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Brian Dickson <[email-masked]>
Date: Wed, 27 Mar 2019 21:08:27 +0100

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

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.

> 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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Mar 2019 22:46:37 +0000

Hiya,

> If you are going to quote me, please do me the courtesy of doing so

I did.

> phrase that captures the nuances.)

There are no such quotes in your mail as rendered by my MUA.

>    refraining from such usage if access is blocked.

I do not accept the above as a useful distinction for this topic.

Those in the category of your first bullet can only be protected
by technology when (essentially) all those in other categories
use the same technology. (That said, I could quibble with your
text, but won't for now:-)

But, and it's a big but, those whose safety is not at risk (today),
also have valid interests to protect, and mechanisms that we have
to offer for such protection need to be widely deployed to be
effective.

> for the first group, DISTINCT FROM any corresponding label for the second

I won't, sorry. I don't accept your proposed dichotomy as valid.
IOW, our disagreement isn't about the word, but the concept that
such a (likely small) set of people are a usefully distinct set
for this discussion.

Cheers,
S.

PS: I won't respond to your other text below as I think doing so
would be repetitive with the above or wouldn't further the discussion.

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 28 Mar 2019 00:16:26 +0100

Moin!

>     adding new providers who are able to comply with these policies.
As said on the mic in the IETF DOH side session having a small list of
providers will be a disservice to privacy. My colleague Jon Reed just
counted the distinct IP addresses from resolvers we see to one of our
service at Akamai over a day. It was 2.64 million. Having millions of
different entities (or tens of thousands if you assume some of these
will be run by the same entity) seeing the user traffic is far better
privacy than have some large US cloud providers getting all of it,
as at the moment these would be the only choices.

And as another colleague of mine, Erik Nygren, said there is a cost
associated of running such TRR at Internet scale, and companies usually
don’t spend money without expecting a return on their investment.

For ISPs the case is clear they get money and have a contract with
the user and want to provide a good service, possibly better then
there competitor (in a lot of european countries there are regular
tests on the speed and service ISP provide).

For the cloud providers the case is not so clear, but looking at
the published privacy policies of Cloudflare and Google neither of
them say that they will not look at the data, and 24 hours is a lot
of time to convert it to get it into some machine learning, but
having looked at lots of DNS data over the last decade even without
the IP address this data, or the result of the analysis of the data
has value.

So to sum up I think opting in the users by default to a couple of
big mostly US based cloud providers is a bad idea. If the interest
really is in getting a secure private resolution for the user then
reaching out to the ISPs and getting them to work with you IMHO is
a better way than declaring them the attacker.

>     we may have DoH/TRR on by default in some regions and not others,
How do you decide which region the user is in? Does it move or is it 
based
on the locale setting?

>     different resolver out of the list, specify their own resolver, or
So the application provider gets to decide who does get to see all the
user data, or will the use have to select one and as stated repeatedly
most users will not be able to make that informed decisions. I don’t
think anyone has problem of an informed user selecting what he believes
is his best choice for resolving, we have that today already. But per
default switching the resolution and thus all the browsing data that
the user generates (even in private mode ;-) to a third party the user
doesn’t have a contract with is the wrong way IMO.

So long
-Ralf
—--
Ralf Weber

---

From: Brian Dickson <[email-masked]>
Date: Thu, 28 Mar 2019 09:26:54 +0100

> I won't, sorry. I don't accept your proposed dichotomy as valid.

I would like to point out the consequences of your position.
I'm interested in your position on the various implications.
I don't want to put words in your mouth, but rather want you to use your
own words.

First question:
Consider the two following URIs, for use by a DoH client (e.g. in a
configured template):

https://some-resolver.example.com/dns-query
https://some-resolver.example.com:<NEW_PORT>/dns-query

(replace <NEW_PORT> with a dedicated-to-DoH port number assigned by IANA)

Let's presume the only server-side difference involved is the port the DoH
server listens to.
i.e. the DoH server listens only on 443, vs the DoH server listens on both
443 and NEW_PORT.

Would you consider those two URIs to be "the same technology"?

Second question:
Consider the two following models for end-user access to DoH from within an
enterprise network.

   1. Escalation model: The user attempts to contact the DoH server via
   NEW_PORT.
      -  If the user is unable to reach the DoH server over NEW_PORT, the
      user is given two options:
         - Don't use that specific DoH server (sub options: pick another
         DoH server, pick a DoT server, pick a Do53 server, don't
connect to the
         network)
         - Make an informed (e.g. warnings and explicit user acceptance)
         choice to reach DoH over 443. This may have personal
consequences for the
         user if DoH443 is prohibited and detected.
            - One possible version of this is that the browser facilitates
            a per-user, opt-in configuration, of always doing the
escalation without
            further prompting.
            - Another possible variation is that the browser facilitates a
            per-user, opt-in configuration, of bypassing the NEW_PORT
attempt. This is
            still distinguished from the "Blind Model" in that it is
opt-in, and that
            the user makes a specific informed choice.
         2. Blind model: No assessment of network posture regarding DoH is
   attempted. User contacts DoH on port 443.

What are you saying about model 1?
Are you rejecting it out-of-hand? I
f you are, have you considered the consequences to users?

Commentary on the second question and its implications:
I see several benefits with model 1, to both the users, and the network
operators:

   1. It facilitates use of the user's choice of DoH server, when not
   prohibited by the network operator.
   2. NEW_PORT is ONLY used for DoH, so the network operator blocking
   NEW_PORT is an unambiguous signal to the user: you do not have the
   permission of the network operator to access that specific DoH server.
   3. It does not directly block access to the user's choice of DoH server,
   over OLD_PORT (443).
   4. It requires the user's informed consent prior to enabling access to
   the DoH server on OLD_PORT, if NEW_PORT is blocked.
   5. For network operators, blocking or allowing NEW_PORT access scales
   extremely well, since it is applicable only to DoH traffic. In particular,
   it is compatible with the use of white-lists as well as black-lists. In
   contrast, network-level blocking on OLD_PORT fundamentally only supports
   black-lists, unless the operator employs large-scale HTTPS white-lists.

In contrast, here are my observations about model 2 (blind model):

   1. The user is not provided any meaningful ability to provide informed
   consent.
   2. The user is not able to infer network policy regarding permission to
   access any particular choice of DoH server.
   3. Even if there were a mechanism to express network policy on
   permission to access particular DoH servers, there would not be any
   scalable enforcement mechanism.
      1. The main issue is that white/black lists for web servers and DoH
      servers would be unavoidably commingled. Updates to DoH server
permissions
      would have impact on web server access, and the management of those ACLs
      might typically be done by different groups with different
permissions and
      different management systems (possibly incompatible).

The bottom line is, that without a technical mechanism with similar
semantics to the NEW_PORT stuff above, this has direct impact to both
network operators (particularly enterprise network operators), and to users.

Without the NEW_PORT mechanism (or something like it), the network operator
who is required to block some or all DoH servers, must employ un-scalable
methods, which may place significant NEW operational, performance, and cost
burdens on the network operator.
Without the NEW_PORT mechanism (or something like it), the network operator
is unable to distinguish users who would otherwise have been interested in
complying with the network operator's policy (think employees with binding
restrictions which are legal in their jurisdiction).
Without the NEW_PORT mechanism (or something like it), the network operator
is unable to distinguish new DoH servers being access, from random HTTPS
connections occurring. Contrast this with the NEW_PORT semantics: the
network operator would see new failed attempts to reach DoH servers, and be
able to determine whether this is abnormal (malware) or due to a new DoH
operator, where the network operator may wish to facilitate access to the
new DoH operator.

I am interested in your feedback on the above, and whether this affects
your view of the dichotomy.

Sincerely,
Brian

P.S. Sorry about the confusion caused by your MUA. You might want to report
that to the vendor as a bug.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 28 Mar 2019 09:44:02 +0100 (CET)

>     Il 27 marzo 2019 alle 23.46 Stephen Farrell < [email-masked] mailto:[email-masked] > ha scritto:
> 
The problem is that, in DoH's "obfuscated traffic mode" (is that better than "dissident mode"?), increased transport privacy for the individual (not necessarily increased privacy, but that's a different story) is obtained at the expense of network security. Other tradeoff points are possible, giving the user almost the same amount of privacy but also more security, so while I find it justified to push the tradeoff to the extreme side of privacy when someone's life and freedom could be at risk, I would prefer a more balanced tradeoff point (the one in which DoH traffic is clearly identifiable and can be blocked by the network if necessary) in other contexts, at least as the default.

More generally, beware that if you build an Internet that is designed to work as if everyone on the planet were a dissident in an authoritarian country, it is not unlikely that you will then get an Internet regulatory and access environment that looks like the one of authoritarian countries, even in democratic ones.

Ciao,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Mar 2019 10:01:24 +0100

On 3/28/19 09:44, Vittorio Bertola wrote:
> More generally, beware that if you build an Internet that is designed 
> to work as if everyone on the planet were a dissident in an 
> authoritarian country, it is not unlikely that you will then get an 
> Internet regulatory and access environment that looks like the one of 
> authoritarian countries, even in democratic ones. 

This is getting pretty far off topic, but you're squarely confusing 
cause with effect. See BCP 188.

/a

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 09:03:41 +0000

Hi,

-----Ursprüngliche Nachricht-----
Von: Doh <[email-masked]> Im Auftrag von Neil Cook
Gesendet: Mittwoch, 27. März 2019 17:15
An: DoH WG <[email-masked]>
Betreff: Re: [Doh] Mozilla's plans re: DoH

>> I’ve heard a number of questions about Mozilla’s plans around DoH. 
>> We’ve made a number of public statements, but it might be useful to 
>> try to put this all in one place.
>> 
> But Mozilla doesn’t know whether the modification is with or without the user’s consent. As the various drafts that have been presented this week attempt to 
> make clear, there are a large number of use cases where users actively want the modification of their DNS (parental control, enterprise networks, 
> malware/phishing detection, botnet C&C communication disruption etc.), indeed they may even be paying for such a service.
That is a very valid assumption. And if they pay for the service they also expect that the service will work and does not break if they install a new client (browser/app/...) on their end systems. In most of the cases they even do not know were a functionality is implemented and they do not change default settings (which is fine, because "default" usually means that nothing will break). From my experience a new default disabling an existing feature (malware/phishing protection, DNS64, Load Balancing, ...) will lead to problems.

Regards

Nic

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Mar 2019 09:11:50 +0000

Hiya,

> I would like to point out the consequences of your position.

I don't believe answers to your questions below reflect any
consequences of my position that use of the term dissident
in this discussion isn't a good plan. But happy to answer...

> Would you consider those two URIs to be "the same technology"?

Yes.

> f you are, have you considered the consequences to users?

I have rejected nothing, neither in nor out of hand;-)

I'd disagree with aspects of what you describe as model 1, e.g.
"the user is given two options" seems overly prescriptive and
we all know (I hope) that terms like "informed choice" seem to
mean very different things to different people involved in this
discussion.

Anyway, allocating a new port for use of DoH seems like it's
worth exploring, but I don't know if it'd work or not. (And I
don't control any browser, nor recursive s/w, so am not really
the right person to chat with for that anyway.)

Fixating now on a new port as the-one-right-answer also seems
unwise to me, given there are multiple dimensions to this overall
topic.

> that to the vendor as a bug.

Thanks for the sympathy but my MUA is just fine in that respect;-)
There are no quotes around the word dissident visible at [1] either,
so I just didn't misquote you at all.

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/msg/doh/wE-FqNjC67oyl_ZXKrHKClSqHVo

---

From: Brian Dickson <[email-masked]>
Date: Thu, 28 Mar 2019 10:18:01 +0100

Sent from my iPhone

> On Mar 28, 2019, at 10:11 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Ah, I see the problem in my original email.
I used quotes the first time I used the term, but not the second time.

My apologies.

Brian 

> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Mar 2019 11:29:03 +0000

Hiya,

On 28/03/2019 08:44, Vittorio Bertola wrote:
> 
>> Il 27 marzo 2019 alle 23.46 Stephen Farrell <
>> [email-masked] mailto:[email-masked] > ha
>> scritto:
>> 
>> Those in the category of your first bullet can only be protected by
>> technology when (essentially) all those in other categories use the
>> same technology. (That said, I could quibble with your text, but
>> won't for now:-)
>> 
>> But, and it's a big but, those whose safety is not at risk
>> (today), also have valid interests to protect, and mechanisms that
>> we have to offer for such protection need to be widely deployed to
>> be effective.
>> 
> The problem is that, in DoH's "obfuscated traffic mode" (is that
> better than "dissident mode"?), 

Better, but still not good:-) I'm not sure we ought think about
different modes of operation at all tbh - that may be assuming
that we're dealing with a single dimension when we're not.

> increased transport privacy for the
> individual (not necessarily increased privacy, but that's a different
> story) is obtained at the expense of network security. 

I'm not sure that conclusion has been established. (It has been
asserted certainly.) What does seem true is that some deployment
models for DoH are inconsistent with use of some current network
security tools. That doesn't mean there's no other way to get the
same benefits, even if it may be disruptive.

> Other tradeoff
> points are possible, giving the user almost the same amount of
> privacy but also more security, so while I find it justified to push
> the tradeoff to the extreme side of privacy when someone's life and
> freedom could be at risk, 

As I've said, I don't think that's a good way to help us analyse
the situation.

> I would prefer a more balanced tradeoff
> point (the one in which DoH traffic is clearly identifiable and can
> be blocked by the network if necessary) in other contexts, at least
> as the default.

It could be that making DoH traffic visible as being DoH traffic
has some role to play, or maybe it won't turn out that way. It is
not at all clear to me though that doing that to enable blocking
DoH traffic would be a useful mechanism - ISTM some applications
(and all malware) would just avoid that.

> authoritarian countries, even in democratic ones.

+1 to what Adam said.

Cheers,
S.

> [email-masked]
> mailto:[email-masked] Office @ Via Treviso 12,
> 10144 Torino, Italy
> 
> 
> _______________________________________________ Doh mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/doh
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Mar 2019 16:08:55 +0000

> should point to the need to use the system resolver.

There are situations where that isn't sufficient, e.g. our private zone
has the same name servers for its internal and external views.

(Also QNAME minimization in the client to a cloudy resolver is going to be
really slow!)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: Southwest 7 to severe gale 9, veering west 6 to gale 8 later. Rough
or very rough, occasionally moderate in southeast, but high at first in west.
Occasional rain later. Good, occasionally moderate later, but poor at first in
west.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 28 Mar 2019 21:41:47 +0100 (CET)

>     Il 28 marzo 2019 alle 12.29 Stephen Farrell < [email-masked] mailto:[email-masked] > ha scritto:
> 
> 
> 
>     Hiya,
> 
Well, this is a discussion that we need to have, and having it without clear terminology makes it confusing. We could name the different technical deployment models that have been mentioned (port 443 on dedicated IP addresses, new protocol-specific port, or port 443 on existing web servers) without attributing them directly to any use case (this is why I agree that "dissident mode" is a bad name). Once we have them, we could discuss whether different use cases would benefit from different models.

Same for the rest - I am happy to let you challenge my proposals, but first of all we should focus on an agreed statement of the issues.

> >         authoritarian countries, even in democratic ones.
Ok, but is this off topic or not? I replied to Adam privately, I am happy to do it in public as well.

Ciao,
-- 
Vittorio Bertola
Head of Policy & Innovation

Cell: 	+39 348 7015022
Direct Chat: 	vittorio.bertola https://chat.open-xchange.com/direct/vittorio.bertola
Email: 	[email-masked] mailto:[email-masked]

Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com
Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court Cologne HRB 95366
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Director: Frank Hoberg

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA

Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.

---

From: Petr Špaček <[email-masked]>
Date: Fri, 29 Mar 2019 12:05:36 +0100

On 27. 03. 19 17:56, Eric Rescorla wrote:
> 
> 
> On Wed, Mar 27, 2019 at 9:32 AM Tony Finch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>     >
> We don't currently expect to do so. As noted above, we don't think
> secure transport to the local resolver is sufficient to ensure the
> privacy and security guarantees we are trying to provide.
> 
> 
> 
> we're still working out how to deal with this split horizon scenario>
> -Ekr

IANAL, nevertheless I will say Beware of
https://patents.google.com/patent/US20160197898A1

BTW This patent is very likely to soon become property of IBM as part of
Red Hat acquisition. I'm not sure what is going to happen with Red Hat's
patent promise.

Petr Špaček  @  CZ.NIC

> 
> 
>     Tony.
>     -- 
>     f.anthony.n.finch  <[email-masked] <mailto:[email-masked]>> 
>     http://dotat.at/

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Mar 2019 12:13:51 +0100

[as an area director in the associated area]

On 3/29/19 12:05, Petr Špaček wrote:
> [patent elided]

With a reminder that mail to IETF mailing lists is covered under the 
definition of "IETF Contributions," I request that you read 
https://tools.ietf.org/html/bcp79#section-5.3

Please review the remainder of BCP 79 and take appropriate action. You 
may wish to consult with legal counsel in determining how to proceed.

/a

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 29 Mar 2019 16:37:27 +0000

+1 to what Adam said - this can avert serious legal / IPR issues later on. 

On 3/29/19, 7:14 AM, "Doh on behalf of Adam Roach" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    /a

---

From: Brian Dickson <[email-masked]>
Date: Fri, 29 Mar 2019 17:49:47 +0100

> definition of "IETF Contributions," I request that you read

Hi, Adam,

Unfortunately, English (my native language BTW) is ambiguous in the meaning
of "you"; it could be second person singular OR second person plural.
Additionally, the "To:" line of your email was the DoH WG mailing list.

Could you clarify, to whom were you addressing the message re: BCP 79?
(The possibilities seem to be, Petr, or the whole list, or maybe implicitly
any WG participants who are employed/sponsored by whoever owns that patent?)

Thanks,
Brian

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 29 Mar 2019 19:15:59 +0100

> may wish to consult with legal counsel in determining how to proceed. 

The mentioned patent belongs to Red Hat (according to the link), but I
can't see any (current) employee of Red Hat in this WG's discussion, on
a quick look, so there seems to be no obligation.  What perhaps applies
is 5.1.3 (a): third-party IPR, so the information is accessible in the
usual way.

Well, correct me if I'm wrong, as I'm rather avoiding patents whenever I
can (and I'm no lawyer).

--Vladimir

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 29 Mar 2019 18:30:56 +0000

> [2] Many networks redirect NXDOMAIN to a search/advertising page.

[JL] This is a reply on this somewhat minor point because NXDOMAIN was also raised at the side meeting. I wonder if folks have more specific references to networks that are *currently* engaged in NXDOMAIN redirection. My sense is that this practice was largely fallen by the wayside as a result of being overtaken by the browser-based omnibox function that launched several years ago and the resulting change in user behavior to just type search terms into the address bar and then click on search results. In any case, curious to know if there's a list of ISPs currently doing this.

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Mar 2019 20:30:10 +0100

On 3/29/19 17:49, Brian Dickson wrote:
> (The possibilities seem to be, Petr, or the whole list, or maybe 
> implicitly any WG participants who are employed/sponsored by whoever 
> owns that patent?)

The specific request was for Petr, although it's never a bad time for 
anyone to go refresh their memory about the contents of BCP 79.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Mar 2019 20:47:24 +0100

I'm not in a position to know what specific obligations may apply, as I 
don't know anything about peoples' current or past employers, previous 
potential involvement, or a host of other subtle issues that might be 
relevant. This is why I directed Petr to BCP 79 rather than trying to 
parse out the details of his situation.

The important issue is that any mention of specific patents must be done 
through the formal patent disclosure process rather than sending 
patent-related information to a mailing list or bringing it up as part 
of any other IETF contribution (such as during an IETF in-person session).

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Mar 2019 21:02:19 +0100

On 3/29/19 19:30, Livingood, Jason wrote:
> [JL] This is a reply on this somewhat minor point because NXDOMAIN was also raised at the side meeting. I wonder if folks have more specific references to networks that are *currently* engaged in NXDOMAIN redirection.

I can get you the specific IP addresses returned once I'm back home, but 
I know with absolute certainty that AT&T (Uverse) and T-Mobile both 
perform such interception. I'm *pretty* certain that Spectrum does as 
well, although I'll have to double-check this to be 100% sure.

I see evidence that Verizon does so as well, at least based on 
https://www.verizon.com/support/residential/internet/home-network/settings/opt-out-of-dns-assist

I see that Comcast turned its DNS hijacking off back in 2012. I fear 
this makes Comcast fairly unique within the US.

/a