Subject: [Add] A thought -- Move the policy decisions outside the application.

From: "Winfield, Alister" <[email-masked]>
Date: Thu, 22 Aug 2019 12:22:57 +0000

The discussions surrounding ’policy’ on this list are long and don't look to be useful other than to highlight how hard the problems are to solve. With no end in sight I'd like to see if some of the issues can be solved by a different method.

What I propose is to externalize the policy decisions. That is take it outside the client and into something (likely an API / OS daemon) that can do the DNS server selection. This doesn’t remove all issues and doesn’t stop malicious / non-compliant applications from doing what they want but….

It allows any viewpoint to be valid, given it could easily be a pluggable solution that allows any party to provide a policy module.
It allows diagnostic tools to use the same settings as the applications knowing that for the most part the same DNS servers and transports are used.
It allows a single point to change settings on most applications (clearly any application can still ignore the settings but this ought to be rare)
It keeps the settings behind administrative authority thus protecting them from trivial abuse by malicious applications.
The policy response can provide information about split views thus giving a method to handle corporate DNS
The policy modules can use any OS available information, some of which may be blocked from applications for a good reason, eg GPS, 802.1x, VPN state etc.

Note I'm not wedded to any specific mechanism just the concept of externalized handling of DNS server policy decisions.

So does anyone else here see this as a reasonable line of thinking worth pursuing ?

--
Alister Winfield

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Aug 2019 11:10:40 -0500

Top posting because I'm responding to the whole idea rather than any 
given point in it.

At a first pass, half of this is really a call for the system resolver 
that is provided by the operating system to implement additional options 
for DNS resolution -- for example, building DoT and DoH into the 
Windows, OS X, and Linux platforms, and allowing for their 
configuration. That would be great!

The other half is exposing information to applications about the way the 
OS is resolving names (encrypted vs cleartext, local-network versus 
public DNS, etc), and the means by which it was configured to do so 
(e.g., by the network as part of acquiring an address, by centralized 
enterprise policy, by local configuration override). The applications 
could then use this information to determine whether there is a policy 
reason to use the local system-configured resolver; and, if so, do so [1].

It is worth highlighting that this second thing is already implemented 
in Firefox [2], to the extent that relevant APIs are provided by the 
operating system today. There are currently two.

The first is Microsoft's "Group Policy" API that is provided to allow 
administrators of enterprise and education networks to push policy to 
machines on their network. When Group Policy is used to configure 
Firefox, it uses whatever DoH settings are present in that policy 
(including honoring a policy decision to disable user configuration of 
DoH). If a Group Policy is present but does not mention DoH, then DoH 
will not be automatically offered to the user.

The second is the "Parental Controls" feature offered by both Windows 
and OS X. If Parental Controls are configured for the account running 
Firefox, it will disable DoH completely, under the assumption that there 
may be some kind of local DNS filtering going on as part of that feature.

With the caveat that I'm not in product management and am simply making 
an educated guess: if operating systems chose to expose the kind of 
information I describe above, I suspect that there is a Really Good 
Chance that Firefox would incorporate them into the decision making 
process about how to handle DoH.

All of that said, it's pretty unclear about whether that kind of thing 
is work that the IETF could usefully take on. It seems more like the 
kind of thing that would need to come from OS vendors, depending on the 
specific features implemented and made available by their operating 
systems. So I like the approach, but it's a bit unclear whether it's 
actionable in this venue.

/a

___
[1] I'll point out this is basically the same thing that Tommy Jensen 
proposed in 
https://mailarchive.ietf.org/arch/msg/add/eb_I9k01GofMYKOgSXmDr0TtR08

[2] Or, at least, will be prior to the widespread release of DoH -- I'm 
not 100% up-to-date on schedules.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 22 Aug 2019 17:41:09 +0000

Thanks for the reference, Adam. The link you provided gives me a 404, not sure if it's a local problem for me or  not, but I'll assume you meant this message [1].

Alister, in short, I do think your thoughts are a reasonable line of thinking. After various discussions here on the mailing list, at least my approach has been to work offline with folks on more concrete proposals for such an OS integration. I'd welcome ideas on or off list as I'm sure other platforms would as well.

I agree with Adam on the platform offering support for encrypted DNS to be a Good Thing. After all, most apps won't think about the need for encrypted DNS [citation needed], and should be benefiting from it anyway when the OS has it available.

I'll point out since the topic is up, that GPO and parental controls are not the only sources of DNS stub configuration in Windows. For example, NRPT rules, which specify behavior for a given domain name pattern, can be created by device admin authority for a number of reasons. For anyone who is interested, you can see PowerShell commands related to getting and setting NRPT rules here [2].

I'm sure other platforms also have related mechanisms for handling the sometimes complex situation of knowing which RR is the correct RR to use for a given domain name, and allowing apps to discover that logic without having to understand each platform's nuance seems like it has significant value. Even better in my mind would be that the platform provides encrypted DNS support and well-behaved apps continued to leave RR selection to the platform. However, if apps would like to dive in and fully grok the system configuration for themselves and redo the work to ensure no user scenario breaks, that's better than using a single RR while ignoring the system configuration and I'll do my best to support them (no harm in having our configuration be more transparent anyway).

Thanks,
Tommy

[1] https://mailarchive.ietf.org/arch/msg/add/PGSg9LN6WB9XuhmYpwrgTO1GEOI

[2] https://docs.microsoft.com/en-us/powershell/module/dnsclient/Get-DnsClientNrptRule?view=win10-ps

________________________________
From: Add <[email-masked]> on behalf of Adam Roach <[email-masked]>
Sent: Thursday, August 22, 2019 9:10 AM
To: Winfield, Alister <Alister.Winfield=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Add] A thought -- Move the policy decisions outside the application.

/a

___
[1] I'll point out this is basically the same thing that Tommy Jensen
proposed in
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fadd%2Feb_I9k01GofMYKOgSXmDr0TtR08&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C35fd77260b174c8904a708d7271b5236%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637020870616953421&amp;sdata=HeGcnAsgc099k0BRGnZtcE4T0hFUali3Fz7hSzSfui8%3D&amp;reserved=0

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C35fd77260b174c8904a708d7271b5236%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637020870616953421&amp;sdata=A2dneDTBGJX2QW6DTDOvGN%2F41ebFPxrovp6c5LTo9S4%3D&amp;reserved=0

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Aug 2019 13:26:09 -0500

On 8/22/19 12:41 PM, Tommy Jensen wrote:
> I'll point out since the topic is up, that GPO and parental controls 
> are not the only sources of DNS stub configuration in Windows. For 
> example, NRPT rules, which specify behavior for a given domain name 
> pattern, can be created by device admin authority for a number of 
> reasons. For anyone who is interested, you can see PowerShell commands 
> related to getting and setting NRPT rules here [2].

I've been digging through these commands recently (for reasons very 
similar to what you imply), and was wondering whether there was some API 
(rather than calling out to commandline executables) that could be used 
to retrieve this and similar information (like DNS search lists). Do you 
know?

/a

---

From: Rob Sayre <[email-masked]>
Date: Thu, 22 Aug 2019 16:11:38 -0700

On Thu, Aug 22, 2019 at 11:26 AM Adam Roach <[email-masked]> wrote:

> I'll point out since the topic is up, that GPO and parental controls are
> not the only sources of DNS stub configuration in Windows. For example,
> NRPT rules, which specify behavior for a given domain name pattern, can be
> created by device admin authority for a number of reasons. For anyone who
> is interested, you can see PowerShell commands related to getting and
> setting NRPT rules here [2].
>
>
> (rather than calling out to commandline executables) that could be used to
> retrieve this and similar information (like DNS search lists). Do you know?
>
Chromium has some code for this in "dns_config_service_win.cc". It looks
like they just use a generic Windows registry search routine to fish out
the values. The NRPT code looks incomplete, but it is there.

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 23 Aug 2019 13:36:58 +0200 (CEST)

Il 22 agosto 2019 19:41 Tommy Jensen <jensen.thomas=[email-masked]> ha scritto:

I also think that Alister's idea is quite useful, even more when you take the policy issues into account. One of the major concerns is about the user losing control over the DNS resolution practices of their device; even if most users won't care, still many do and should be empowered to do that; the more so if you consider that the main driver for informed resolver selection by users today is exactly when something bad happens and unaware users suddenly feel the need to learn about DNS resolution and take back control, overriding their system's defaults.

A centralized configuration mechanism that can inform all applications of the user's wishes is key to this, even if we all know that applications will still be free to ignore that configuration for both user-friendly and user-adversarial reasons.

Regarding whether this is work for the IETF or not, well - this goes beyond protocol specification, but I think it's clear that the changes potentially created by the deployment of encrypted DNS involve multiple layers and many different stakeholders, so they need to be addressed through coordinated work in many places (some technical, some policy). I increasingly think that we need some ad-hoc effort to sit together and work out the overall picture and who needs to be involved where.

--

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 10:50:40 -0400

{I'd like to suggest that everyone limit themselves to one reply per day}

Adam Roach <[email-masked]> wrote:
    > The other half is exposing information to applications about the way
    > the OS is resolving names (encrypted vs cleartext, local-network versus

Long ago, in the early days of DNSSEC, before type-code-rollover, I suggested
that we needed WAY MORE than SERVFAIL as the failure code to applications
when DNSSEC did not validate.
Having a full (secure) resolver inside the application makes it much easier
to get better diagnostics.

    > Firefox, it will disable DoH completely, under the assumption that
    > there may be some kind of local DNS filtering going on as part of that
    > feature.

That's an interesting thing to know about.

    > actionable in this venue.

It's API work.  It's often within the system.
If we took the view that we needed better communication of errors for
resolvers not just within the system, then maybe it's our problem.

We might also find that the in-system resolvers use DNS wire format
for their responses, and would like to allocate codes from IANA to keep
things straight.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 26 Aug 2019 09:56:17 +0200

> when DNSSEC did not validate.

That's being worked on for a couple of years now:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

I generally think we should focus on the ability to pass such
information inside the DNS protocol.  Pushing operating system APIs to
some direction seems way much harder, and the in-DNS path sometimes
provides additional advantages (e.g. for forwarding in this case).

--Vladimir

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Aug 2019 13:14:00 -0400

> provides additional advantages (e.g. for forwarding in this case).

Ted (or was it Paul?) also mentioned that there was an effort to be able to
return positive DNSSEC validation, while also saying that the name has been
censored.  I haven't understood that proposal well.

It seems that dnsop-extended-error includes 4.17 -- Censored.

I see there to be three technical things that applications doing DNS(SEC) need:

1) discover "local" DoT and DoH resolvers, particularly when "public" DoT/DoH
   resolvers might be blocked due to legal requirement.  There are a few
   different proposals in dprive WG already.

2) discover anchors for DoT and DoH resolvers, and along with this, discover
   what the privacy and censorship policy of those resolvers is.
   We removed this from the next version of draft-reddy-dprive-bootstrap-dns-server,
   with the intention of having a new draft, which I have not completed, but
   we think it is work for DPRIVE.

3) communicate better errors concerning censorship to applications, which
   DNSOP WG seems to already be doing.

====

There are some political layer things that we need to be cognizant about:

a) there are significant local political forces for a wide variety of
   censorship, with the legal mandate to be able to enforce it.
   We (the IETF) prefer that they do this in ways that does not involve
   a belief that they can contradicts mathematical science.  No nuking of hurricanes.

b) there is conversely, significant interest in making browsing private,
   specifically to enable open and free access to all web sites.  The
   Mozilla approval list is unlikely to scale *geopolitically*, and there
   are many (IETF "objectively") freedom-loving entities that will be unable
   (legally) to comply to the requirements listed, but which end users and
   end-network administrators (i.e: "parents", "teachers") will find have
   value.   It is important that it is possible to communicate the privacy
   policy to users.

c) All jurisdictions are subject to NSLs, and therefore equally able to
   be forced to make disclosures.  To paraphrase Orwell: Some jurisdictions
   are more equal than others.    I don't think it is the IETF's business
   to say declare winners among (a) and (b), but rather to enable end
   users to be aware of what is going on.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Adam Roach <[email-masked]>
Date: Mon, 26 Aug 2019 12:55:18 -0500

>     value.   It is important that it is possible to communicate the privacy

Since you're citing Mozilla's TRR policy directly, I'd like to clarify 
that the policy you refer to states that "Resolvers may block or filter 
content with the user’s explicit consent." It also allows for blocking 
as "specifically required by law in the jurisdiction in which the 
resolver operates."

You may already know both of these things, but people reading your 
message without reading the actual policy might have inferred 
incorrectly that neither clause exists.

/a

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Aug 2019 13:56:56 -0400

Ted Lemon <[email-masked]> wrote:
    > One thing that Dot and DoH could potentially provide is a way to
    > establish a level of trust for “censored” result codes.   These result
    > codes can in principle be used as an attack, but if it’s the rule that

Does this go into the dnsop document?
A dprive document that references it?
Or do you think that this is new work that requires a new WG?

Do you think that I missed any technical work?

    > a censored result code is never returned by any resolver other than the
    > one that is doing the censoring, then you could have a trust
    > relationship with a resolver from which you want this service, and then
    > based on the PKI validation, you could trust the result code as an
    > indication that the entity from which you have agreed to purchase or
    > accept filtering service has applied a filter.

I very much like this.

    > (BTW, I don’t really believe in validation on the resolver, except as a
    > way to avoid caching crap, so it can’t have been me that said that,
    > although it could have been that other Ted.)

Maybe it was Paul that mentioned this effort.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Aug 2019 13:20:02 -0400

One thing that Dot and DoH could potentially provide is a way to establish a level of trust for “censored” result codes.   These result codes can in principle be used as an attack, but if it’s the rule that a censored result code is never returned by any resolver other than the one that is doing the censoring, then you could have a trust relationship with a resolver from which you want this service, and then based on the PKI validation, you could trust the result code as an indication that the entity from which you have agreed to purchase or accept filtering service has applied a filter.

(BTW, I don’t really believe in validation on the resolver, except as a way to avoid caching crap, so it can’t have been me that said that, although it could have been that other Ted.)

> On Aug 26, 2019, at 1:14 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> https://www.ietf.org/mailman/listinfo/add

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Aug 2019 16:36:47 -0400

> Do you think that I missed any technical work?

My overall knowledge of what has been written about this is sketchy at best—I’ve been using these documents as a reference resource rather than implementing them.  So hopefully if at some point our fearless AD mods these posts, someone who knows more about this than either of us will weigh in.

FWIW, my opinion, independent of any knowledge of what documents actually exist or what their status is at present, is that the document that defines the result code should also define the trust model and the propagation rules.   That somewhat argues for not putting it in the extended-option-codes document, but it could go there if the authors are willing to do this work.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 Aug 2019 22:03:06 -0400 (EDT)

> censored.  I haven't understood that proposal well.

It was my idea to change RPZ to allow it to function with DNSSEC,
without losing the ability to detect malicious censorship from opted-in
censorship.

The idea is that if the good guy filters, it moves the Answer Section data to
the Authoritative Section. Current clients will thus be censored, since
these clients will not look in the Authoritatve Section. Clients
supporting this new RPZ 2.0 would look in the Authoritatve Section, pick
up the data for DNSSEC validation, and also withhold it from the client
unless the client asks for more additional information. Clearly that
would need to be signaled from the DNS library to the application. This
could be done with the above references Extended Errors, eg have an
"RPZ 2.0 filtered" error.

The advantage of this method is also that it required user's opt-in. If
filtered maliciously, the user will get a proper DNSSEC error since the
validation will fail. If the filter is properly done, the user can
DNSSEC validate the response and decide to 1) not use the results
because it trusts the censor, or 2) ignore the censor and use it anyway.

This should faciliate Enterprise or Parental censorship while preventing
nation state abuse. Of course nation states can filter the answer and
omit all the data, but then you get a DNSSEC validation error to confirm
to the enduser that they are being censored (the best you can do with
a nationstate absolute filter in your path)

Paul

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 27 Aug 2019 11:07:02 +0200 (CEST)

Il 26 agosto 2019 19:20 Ted Lemon <[email-masked]> ha scritto:

One thing that Dot and DoH could potentially provide is a way to establish a level of trust for “censored” result codes.

In general, while I think that the IETF will never come to consensus on whether altering DNS replies at the resolver level is philosophically always unacceptable, always acceptable or acceptable only under certain conditions, I think things would be much better for everyone if we could at least introduce more transparency, security and user-friendliness to this practice.

For example, rather than having to alter the response (and break DNSSEC) to redirect the user to a meaningful explanation page, a filtering resolver could just return the "blocked" or "censored" error code and add the altered IP address / explanation URL somewhere in an extra field - the "extra-text" of Warren's draft or something more specific - which the client could then use to show the resolver's message to the user. This would require client support, while old clients would just get the error rather than the altered response, so we'd have to think whether this could actually work in all use cases, but still, once widely implemented, this would provide a cleaner architecture and a better user experience in the basic "web filter" cases.

These result codes can in principle be used as an attack, but if it’s the rule that a censored result code is never returned by any resolver other than the one that is doing the censoring, then you could have a trust relationship with a resolver from which you want this service, and then based on the PKI validation, you could trust the result code as an indication that the entity from which you have agreed to purchase or accept filtering service has applied a filter.

Also, even when the filtering is made against your will, at least you could be sure of who exactly is doing what - and PKI certificates could even be used to prove who is the third party that asked the resolver to apply the filter.

However some people might say that this would be "the IETF building infrastructure for censorship", so we'd first need to agree that doing this is better than doing nothing.

--

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

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 27 Aug 2019 11:12:55 +0200 (CEST)

> Il 26 agosto 2019 19:55 Adam Roach <[email-masked]> ha scritto:
> 

May I ask how do you plan to reconcile this latter clause with the objective of providing uncensored web access in countries where the law requires Internet censoring for political reasons? Will you have a list of countries where even law-mandated blocking would not be allowed to TRRs? Or will you not accept TRRs from those countries? Will it be a case-by-case evaluation for each TRR? 

--

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 12:41:32 -0400

>> > That's being worked on for a couple of years now: >
    >> > I generally think we should focus on the ability to pass such >
    >> Ted (or was it Paul?) also mentioned that there was an effort to be
    >> able to return positive DNSSEC validation, while also saying that the
    >> name has been censored.  I haven't understood that proposal well.

    > The idea is that if the good guy filters, it moves the Answer Section
    > data to the Authoritative Section. Current clients will thus be

Is this in a draft yet?

    > This should faciliate Enterprise or Parental censorship while
    > preventing nation state abuse. Of course nation states can filter the
    > answer and omit all the data, but then you get a DNSSEC validation
    > error to confirm to the enduser that they are being censored (the best
    > you can do with a nationstate absolute filter in your path)

The question is whether or not the nation states would agree that this is
enough.

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Aug 2019 14:25:33 -0500

On 8/27/19 1:31 PM, Michael Richardson wrote:
> Thank you for clarifying this.
>
> BUT: Do you agree with my *technical* point that we need a way to communicate the
>       policy to the end user, so that there can be informed consent?
>

I think the means by which such policy information is conveyed to the 
user remains an open question for now. I'll note that there are a few 
different attempts to get policies -- both human-readable and 
machine-readable -- published on /.well-known/ endpoints:

  * Machine-readable DNT policies can be published under
    <https://www.w3.org/TR/tracking-dnt/#status-resource>, which is
    itself a refinement of EFF's human-readable proposal described at
    <https://www.eff.org/dnt-policy>
  * Email STS policies can be published as per
    <https://tools.ietf.org/html/rfc8461#section-3.2>
  * There's an (unregistered) effort to publish a set of URLs (some
    pointing to machine-processable content, others to human-readable
    content) that defined policy and related things for reporting
    security vulnerabilities at <https://securitytxt.org/>.
  * The format defined in <https://tools.ietf.org/html/rfc6415>
    leverages the link-relation registry
    <https://www.iana.org/assignments/link-relations/link-relations.xhtml>
    to allow inclusion of site policy documents (e.g., copyright
    licensing terms and privacy-policy).

I presume that you have something like this in mind?

/a

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 14:31:24 -0400

Adam Roach <[email-masked]> wrote:
    >> b) there is conversely, significant interest in making browsing
    >> private, specifically to enable open and free access to all web sites.
    >> The Mozilla approval list is unlikely to scale *geopolitically*, and
    >> there are many (IETF "objectively") freedom-loving entities that will
    >> be unable (legally) to comply to the requirements listed, but which
    >> end users and end-network administrators (i.e: "parents", "teachers")
    >> will find have value.  It is important that it is possible to
    >> communicate the privacy policy to users.

    > as "specifically required by law in the jurisdiction in which the

I understood that the TRR requires the resolvers to publish their block list,
but that the list in many countries is very very carefully kept confidential.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Aug 2019 11:26:51 +1000

Hi Vittorio,

> On 27 Aug 2019, at 7:07 pm, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 

Similar things have been proposed in the past, at other layers; e.g., 
  https://www.ietf.org/archive/id/draft-nottingham-proxy-explanation-00.txt

There's a bigger issue than figuring out how to make it backwards-compatible. Without trying to speak for them, the impression I got is that the browser vendors are less than enthusiastic about exposing untrusted content to users, even if it's heavily constrained (as is the case in the proposal above), as it's a potential attack vector. 

While technical people (like those on this list) might be able to interpret such a message safely and productively, many users of the Internet don't have that skill; for similar reasons, browsers have substantially changed the user experience of security for TLS over the last few years, and are continuing to do so, so that it's "safe by default", even in the face of user ignorance / apathy. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 29 Aug 2019 11:39:58 +0200 (CEST)

> Il 28 agosto 2019 03:26 Mark Nottingham <[email-masked]> ha scritto:
> 

Thanks for sharing this. It prompted some thoughts on what kind of untrusted content could come this way, as I assume that we could authenticate the resolver and keep the channel secure, and even require EV certificates so that the user could know who is sending the message on the landing page.

I do see risks if you are using an untrusted resolver: for example, the resolver could reply to a request for www.mybank.example with a "blocked" error and a redirection to a phishing page. However, how is this different from an untrusted resolver today, without those extensions? It could already reply with the IP of a phishing page and even claim that it's been DNSSEC-validated.

On the other hand, this kind of enhanced user experience could also be a driver for resolvers to adopt encryption and authentication and get into a "trusted resolver" status (however ascertained).

---

From: "John Levine" <[email-masked]>
Date: 28 Aug 2019 13:42:19 -0400

In article <[email-masked]> you write:
>May I ask how do you plan to reconcile this latter clause with the objective of providing uncensored web access in countries where the law requires Internet censoring for political reasons?

In the UK the law effectively requires filtering of child abuse
material.  In parts of Canada, it requires filtering illegal offshore
gambling sites.  These are implemented partly or entirely as DNS filters.

I am sure that Mozilla do not think of themselves as advocates of
pedophilia or money laundering, or advocates of botnets and malware on
networks with RPZ security filters in the resolver.  But when they
encourage users to use their "trusted" DNS rather than the default,
that's what they're doing.

Until we can admit this is a big problem, and we can't wave our hands
and say "censorship" and make it go away, we're not going to make any
progress.

R's,
John

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Aug 2019 09:53:44 -0700

Hi John,

On Thu, Aug 29, 2019 at 8:22 AM John Levine <[email-masked]> wrote:

> >May I ask how do you plan to reconcile this latter clause with the
> objective of providing uncensored web access in countries where the law
> requires Internet censoring for political reasons?
>

Obviously, I don't work for Mozilla and do not speak for them.  I will say,
though, that I don't think this is a fair characterization of their
position.  At least to me, they seem to be making a very strong effort to
increase the confidentiality and tamper resistance of DNS queries flowing
between clients and recursive resolvers.  That involves moving two
parties:  those that make the queries and those that respond.  They are
updating their own client code to accomplish the first.  They are working
with others to lead by example for the second.  They have made very clear
that the client configuration is always subject to change by whomever
controls the computer, and they have made very clear in the terms of the
TRR that a resolver obeying the local laws will be counted as in
compliance.  They are not blocking access to resolvers that follow those
laws, in other words:  they are waiting for them to catch up and offer
service which is confidential and tamper-resistant.

We are in an uncomfortable pause in the development and deployment of these
technologies, and I hope we can move forward from here rapidly.  But the
direction of that move should be, in my personal opinion, along the path
that takes us to confidential, tamper-resistant connections being the
default substrate between clients and recursive resolvers.  Once we are
there (or closer to there), discussing how to select a recursive can go
back to the usual track of balancing the other optimizations required.

I suspect, without a shred of evidence to back it, that this may involve us
moving to a state where a client commonly has more than one recurisve
resolver to consult, in order to balance split-DNS needs with other
optimizations and in order to avoid concentration.  That, however, is
probably a discussion for a later day.

regards,

Ted Hardie
(as an individual contributor)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Aug 2019 21:36:39 +0100

John,

> and say "censorship" and make it go away, we're not going to make any

I think that until people discussing this resist the
temptation to present totally one-sided perspectives,
we are not going to make progress. I think you failed,
and failed badly, in resisting that temptation in your
mail.

And when you go further and claim that "what they're
doing" makes them "advocates of pedophilia" - that
seems entirely out of order to me.

Regards,
S.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 29 Aug 2019 17:25:46 -0400

> that's what they're doing.
I would think it would be obvious that building tools that resist
censorship, observation, and tampering of traffic does not mean anyone
doing so is aligned with the worst elements that avail themselves of those
tools, nor does it mean that the tools are the solution to those problems.

I think on the ADD list and others it's been made very clear that DNS is
not an integral feature of networks, but a configurable one, and that any
regime that relies on DNS filtering will wither in the face of people
spray-painting 8.8.8.8 and 1.1.1.1 (and 9.9.9.9, if they want that RPZ
filtering over some other set).

I think we can admit this is a big problem but also say that DNS is not the
focal point for solutions to those problems. best, Joe

-- 
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: Vittorio Bertola <[email-masked]>
Date: Fri, 30 Aug 2019 12:28:33 +0200 (CEST)

Il 29 agosto 2019 23:25 Joseph Lorenzo Hall <[email-masked]> ha scritto:

On Thu, Aug 29, 2019 at 11:22 AM John Levine <
[email-masked]> wrote:

In article <

I would think it would be obvious that building tools that resist censorship, observation, and tampering of traffic does not mean anyone doing so is aligned with the worst elements that avail themselves of those tools, nor does it mean that the tools are the solution to those problems.

I think on the ADD list and others it's been made very clear that DNS is not an integral feature of networks, but a configurable one, and that any regime that relies on DNS filtering will wither in the face of people spray-painting 8.8.8.8 and 1.1.1.1 (and 9.9.9.9, if they want that RPZ filtering over some other set).

I think we can admit this is a big problem but also say that DNS is not the focal point for solutions to those problems. best, Joe

I am sure that Mozilla never meant to facilitate any kind of crime, be it child pornography, money laundering or whatever.

I also think that they, in the beginning, failed to appreciate in full the complexity of the problem and of today's DNS, and based their approach on two wrong assumptions:

1. any kind of DNS-based content/access filtering is "censorship"

2. DNS should not be used as a control point for the Internet

(#1 is also in your PEARG draft, and you know I disagree with that choice of language.)

In reality, the access control capabilities of DNS resolvers are used in most cases for different objectives than what would commonly be called "censorship" (blocking content for political reasons in undemocratic regimes).

Also, DNS *is* an effective control point, and this is demonstrated by the fact that it is widely used to that effect almost everywhere on the planet with satisfaction. Claiming that "since it doesn't work 100% of the time then it doesn't work at all" is a fallacy, especially if it's not done by the people that use the system, but by other people that would like to disrupt it.

Many non-technical Internet stakeholders (public authorities, businesses, civil society and end-users) make use of that control point, and many people and companies in the DNS, ISP and networking industries cater to that need, and use it for themselves as well. I don't see any of these stakeholders willing to give up this use of the DNS, so any attempt by Mozilla, the IETF or others to disrupt the use of DNS as a control point will be seen like John did, and perceived as an attack on security, network management, business and law enforcement tools that are vital to those stakeholders.

This is why reiterating any of the two points above is also very "one sided", and not conducive to a solution.

I think we should rather work (like Mozilla has started doing with their split DNS recognition experiments) on ways to preserve the current use of the DNS as a control point, while giving users the additional privacy and security which are the stated objectives of DNS transport encryption, and a way to bypass these controls in specific use cases of actual "censorship".

--

---

From: Bret Jordan <[email-masked]>
Date: Fri, 30 Aug 2019 16:23:56 +0200

> While technical people (like those on this list) might be able to interpret such a message safely and productively, many users of the Internet don't have that skill; for similar reasons, browsers h…

"Safe by default” is the wrong term.  Just because my session or data has not been modified in transit, does not mean it is safe. 

Also, just because something is trusted or cryptographically verified, does not make it safe. 

Bret

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 30 Aug 2019 05:53:09 -0400

On Thu, Aug 29, 2019 at 20:46 Brian Dickson <[email-masked]>
wrote:

>
>
> On Thu, Aug 29, 2019 at 4:46 PM Joseph Lorenzo Hall <[email-masked]> wrote:
>
>>
>>
>>> [snip]
>> In parts of Canada, it requires filtering illegal offshore
> [snip]
> So, point of clarification.
> When you say "any regime", are you limiting the intended scope to
> countries generally considered by neutral, major newspapers to be regimes?
> Or, did you just call Canada a regime?
>
> (Note to Barry: did the use of the term "regime" slip by you, or did you
> deliberately allow this through the moderation filtering you are doing? I
> thought we were trying to limit inflammatory language.)
>

Apologies, by regime I simply meant governing power structure.

Joseph Lorenzo Hall

---

From: Brian Dickson <[email-masked]>
Date: Thu, 29 Aug 2019 17:45:55 -0700

[snip]

So, point of clarification.
When you say "any regime", are you limiting the intended scope to countries
generally considered by neutral, major newspapers to be regimes?
Or, did you just call Canada a regime?

>
> I think we can admit this is a big problem but also say that DNS is not
> the focal point for solutions to those problems. best, Joe
>

The main point here, is not whether DNS is the best solution, or not, but
whether it is legitimate to allow/support the use of DNS filtering where it
is required by local law in democratic countries?

And by "legitimate to allow", the meaning of the question is, as far as ADD
context is concerned:

Is it reasonable to require that software implementers comply with these
local laws, either completely, or at least by default that requires
informed user consent to override?

(I don't think the specifics on how that is accomplished are that
important. It could be having software change its behavior based on
location, or different versions for different locations, or something else.)

And I concur with John L, the starting point needs to be admitting it is a
problem.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Fri, 30 Aug 2019 10:00:21 -0700

> temptation to present totally one-sided perspectives,

It occurred to me that many of the same use cases came up in HTTP/2's
adoption of TLS. The HTTP/2 spec doesn't require TLS, but I don't think
many clients support its use unencrypted.
<https://github.com/http2/http2-spec/wiki/Proxy-User-Stories>. Now that TLS
is so prevalent on the web, there are many proxy implementations and RFCs
that are no longer relevant. I also went back to check out the mailing
list, and the debate is eerily similar. <
https://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/thread.html#msg1357

I think what's different about this discussion is that there seem to be
people advocating that a client should *always* let the network decide
whether to encrypt DNS, and where to send the traffic. This seems unusual
for the IETF. And, as we've documented, there are already many easy-to-use
products that make various choices about DNS encryption and choice of
server.

The issue seems contentious because DNS is one of the few remaining clear
text control points, but RFC7258 does still seem to apply <
https://tools.ietf.org/html/rfc7258>.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 30 Aug 2019 15:11:55 -0700

On Fri, Aug 30, 2019 at 2:42 PM STARK, BARBARA H <[email-masked]> wrote:

>
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of * Rob Sayre
>
>
>
> <bhs> I haven’t seen massive outcry against encryption of DNS. That’s not
> the issue. Please stop saying it is. Many ISPs are seriously looking at
> both DoT and DoH. Continuing to claim people are saying something they
> aren’t saying is not beneficial to the discussion.
>

Hello,

I think there are a mix of opinions. It sounds like you're saying DoT/DoH
might be ok, but you're concerned about server selection. It is unusual for
the IETF to dictate that--at most some set of authoritative options might
be suggested. I suppose my message did not call out that specific
combination, but I also didn't mention ISPs.

There are other people on this list who are ok with only one of DoT or
DoH.  And, there are messages that mix up data integrity and message
integrity in confusing ways--I can't tell what they think. Then, there are
people who seem to think DNS in the clear is ok, as it does allow for a
variety of middlebox software.

thanks,
Rob

---

From: Ray Bellis <[email-masked]>
Date: Fri, 30 Aug 2019 22:25:28 +0100

> seems entirely out of order to me.

It may be out of order, but it's exactly what has happened in the past.

 From September '96:

<http://www.rogerclarke.com/II/EFAUK.html>

"The Sunday, August 25 issue of the London Observer splashed across its 
front page a sensationalized account of child pornography on the 
Internet, falsely accusing two Internet Service Providers, Clive Feather 
of Demon UK (a full service site) and Johan Helsingius of anon.penet.fi 
(an anonymous remailer) of involvement in the distribution of child 
pornography. Why were these accusations made? Demon UK had refused to 
remove a broad range of sexually-oriented newsgroups identified by UK 
authorities as possible sources of child pornography, and anon.penet.fi 
was identified without substantiation as a source for `90% of child 
pornography on the Internet.'"

I've also personally attended a meeting at the UK Home Office along with 
many other ISPs a couple of years after this happened where we were 
pretty much told "filter this, or we'll make sure you're the next ones 
on the front pages of the tabloid press".

Ray

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 30 Aug 2019 21:42:40 +0000

From: Add <[email-masked]> On Behalf Of Rob Sayre
On Thu, Aug 29, 2019 at 4:45 PM Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

It occurred to me that many of the same use cases came up in HTTP/2's adoption of TLS. The HTTP/2 spec doesn't require TLS, but I don't think many clients support its use unencrypted.
<https://github.com/http2/http2-spec/wiki/Proxy-User-Stories<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_http2_http2-2Dspec_wiki_Proxy-2DUser-2DStories&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=g5Ke0YrSwIj2j-kA0HNvd5jqeORhZ-5I_hA5AcJJWd8&s=_P5u8JGfueKsucOCWVpBmqVYQrHO1n5_FKrorPkXK4I&e=>>. Now that TLS is so prevalent on the web, there are many proxy implementations and RFCs that are no longer relevant. I also went back to check out the mailing list, and the debate is eerily similar. <https://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/thread.html#msg1357<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.w3.org_Archives_Public_ietf-2Dhttp-2Dwg_2013OctDec_thread.html-23msg1357&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=g5Ke0YrSwIj2j-kA0HNvd5jqeORhZ-5I_hA5AcJJWd8&s=shiTxvFW_9RdMQkx6iMZo0dvcZapPJ59N5sWRQRmmFk&e=>>

I think what's different about this discussion is that there seem to be people advocating that a client should *always* let the network decide whether to encrypt DNS, and where to send the traffic.. This seems unusual for the IETF. And, as we've documented, there are already many easy-to-use products that make various choices about DNS encryption and choice of server.

The issue seems contentious because DNS is one of the few remaining clear text control points, but RFC7258 does still seem to apply <https://tools.ietf.org/html/rfc7258<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7258&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=g5Ke0YrSwIj2j-kA0HNvd5jqeORhZ-5I_hA5AcJJWd8&s=3MM-UP3gxKPl6onIP3xoiwTJaTWUVbCvDeqp7xogQJY&e=>>.

thanks,
Rob

<bhs> I haven’t seen massive outcry against encryption of DNS. That’s not the issue. Please stop saying it is. Many ISPs are seriously looking at both DoT and DoH. Continuing to claim people are saying something they aren’t saying is not beneficial to the discussion.
Barbara

---

From: Brian Dickson <[email-masked]>
Date: Fri, 30 Aug 2019 16:00:55 -0700

On Fri, Aug 30, 2019 at 2:00 PM Rob Sayre <[email-masked]> wrote:

> <https://github.com/http2/http2-spec/wiki/Proxy-User-Stories>. Now that
> TLS is so prevalent on the web, there are many proxy implementations and
> RFCs that are no longer relevant. I also went back to check out the mailing
> whether to encrypt DNS, and where to send the traffic..
>

There are nuances involved in what I'm advocating. I can't speak for anyone
else, but I can attempt to explain them better than I might have previously.

It basically falls into a privilege model, or privilege escalation perhaps,
or a permissions model at least.

Here is what I'm advocating:

   - Networks should be able to restrict IP addresses (and possibly names),
   as well as port numbers, for outbound connections from hosts.
   - The operative phrase is "be able to". This does not mandate that they
   do so, only that they should have the ability to over-ride host activity
   that runs afoul of whatever the network's policy is.
   - DNS resolution (e.g. client selection of provider and transport)
   should abide by the network's desire to enforce any such policies.

In some (many?) environments, if the network does not have a policy or is
liberal in its policy, this would be compatible with hosts using whatever
DNS resolver and whatever protocol they wish.

I am also an advocate of a bunch of other things related to the above:

   - ISPs should be regulated according to "network neutrality" principles,
   with Internet access being treated as an essential service
      - Encrypted DNS should NOT be blocked to any destination where
      unencrypted DNS isn't also blocked ("no downgrade attacks")
   - The presumption that users have a choice of ISPs is no longer
   universally valid
   - The "coffee shop" is not an ISP per se, and can have Ts & Cs to that
   effect
   - The "coffee shop" experience is a take it or leave it situation,
   presumably where the customer can choose not to use the network offered
   - The regulators for a given jurisdiction should govern ISP behavior
   with respect to DNS in a public, transparent fashion
      - E.g.  regulators could provide a list of IPs and ports that must
      NOT be blocked (e.g. DNS public recursives that comply with
      jurisdiction-specific policies).
         - Those lists should be public.
         - The onus would be on the regulators to keep those lists current.
         - ISPs should use only the same lists as publicly published.
         - Obviously, discovery/publication is a huge problem to achieve
         scalable interoperability between client OS or app software, and DNS
         provider selection
      - Generally, the scope of ISPs and regulators should be in rough
      alignment
      - Management of ISPs' DNS white-lists would likely be through
      provisioning systems, ideally compatible with automation
   - Bypassing any enforcement mechanisms in use by network operators,
   should only be done with informed user consent, since doing so may have
   consequences.

> This seems unusual for the IETF. And, as we've documented, there are
> already many easy-to-use products that make various choices about DNS
> encryption and choice of server.
>

I think this isn't as cut-and-dry as it might seem, at least when comparing
DNS and HTTPS.
HTTPS is end-to-end, client to (content) server. End-to-end encryption
between the client (which originates the connection) and the *correct*
server is strictly necessary to prevent monitoring by any third party.

The only current methods of assuring the client that the *correct* server
is the far end of the connection, IMHO requires the following:

   - Publishing A/AAAA records in DNS with a chain of trust back to the
   root of the DNS, protected with DNSSEC.
   - Use of TLS 1.2 (or above)
   - Publishing TLSA records to protect the TLS certificate (which requires
   DNSSEC)
   - Client validation for DNSSEC

Without all of this, there exists an attack surface against the client
connection, which includes the TLS certificate (e.g. rogue CA), the
resolver (without regard to client-resolver encrypted transport), and the
DNS data (if not DNSSEC signed).

Yes, encrypted transport from the client to resolver adds privacy, but
without the four elements above, the desired result (protection against
pervasive monitoring) is unfortunately not 100% guaranteed.

I.e. DoH/DoT may be necessary, but is definitely not sufficient by itself.

Brian

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 31 Aug 2019 15:12:06 +0200 (CEST)

> Il 31 agosto 2019 05:37 John Levine <[email-masked]> ha scritto:
> 
> I was with you until that last clause.  The modern Internet is
> unusable without content filtering, the distinction between filtering
> and censorship is a purely political one, and the IETF is terrible at
> politics.  (I say this as someone who spent a decade in political
> elective office, long enough to get elected many times and to realize
> I wasn't very good at it.)

+1 for "the IETF is terrible at politics", and even at understanding basic Internet governance principles such as "stakeholder groups" and "sovereignty".  (I'm trying to hide from posterity my past role in the ascent of the current populist ruling party in Italy, but it was a very instructive experience as well, though it ended in disaster.)

> It's fine to design a system that can cooperate with controls, or can
> not cooperate with controls, but it is asking for trouble to actively
> circumvent controls.  That's setting us up for a largely political
> battle against people who are much better at it than we are, fought on
> turf we do not control.

I agree, but I sympathize with people trying to fight for their rights in oppressive regimes, and since Mozilla and others seem so attached to the idea of fighting that battle, I don't think we should be telling them that they shouldn't.

So it's fine if they want to work on instruments to circumvent censorship, but of course only if they don't break the rest of the Internet in the meantime, including circumventing other controls.  Moreover, they bear any legal consequence of their actions, and it's on them to find how to tell "censorship" from normal content control; if you remember, this thread started exactly because I asked Adam Roach how do they plan to do that, and it was not a rhetorical question.

However, I'd still advise them that changing politics and law in a country (which is an entirely inappropriate objective for the IETF, but not for a private organization like Mozilla, if they so want) is not a technical problem, but a cultural one.  Government arrangements, even the most authoritarian ones, are largely a consequence of the mindset and culture of their societies; many places that in the West are called "undemocratic" simply never had an illuminist revolution that made certain concepts popular, and have been governed by a supreme ruler since history exists, just changing the title from "Emperor" to "Party Secretary" or "President".  Trying to force political changes through technology is an attractive shortcut, but it does not lead to true results; a change of culture inside society is necessary for that. 

--

---

From: "John Levine" <[email-masked]>
Date: 30 Aug 2019 23:37:27 -0400

In article <[email-masked]> you write:
>I also think that they, in the beginning, failed to appreciate in full the complexity of the problem and of today's DNS,
>and based their approach on two wrong assumptions: 

>In reality, the access control capabilities of DNS resolvers are used in most cases for different objectives than what
>would commonly be called "censorship" (blocking content for political reasons in undemocratic regimes). 
>
>Also, DNS *is* an effective control point, and this is demonstrated by the fact that it is widely used to that effect
>almost everywhere on the planet with satisfaction. Claiming that "since it doesn't work 100% of the time then it doesn't
>work at all" is a fallacy, especially if it's not done by the people that use the system, but by other people that would
>like to disrupt it. 

Thank you, all very well said.

>I think we should rather work (like Mozilla has started doing with their split DNS recognition experiments) on ways to
>preserve the current use of the DNS as a control point, while giving users the additional privacy and security which are
>the stated objectives of DNS transport encryption, and a way to bypass these controls in specific use cases of actual
>"censorship". 

I was with you until that last clause.  The modern Internet is
unusable without content filtering, the distinction between filtering
and censorship is a purely political one, and the IETF is terrible at
politics.  (I say this as someone who spent a decade in political
elective office, long enough to get elected many times and to realize
I wasn't very good at it.)  I also observe that unless you are one of
the tiny minority of people who run their own mail server, it is
unlikely you have much control over the spam filters that manage your
mail, but our mail systems seem usable anyway.  Absolute control over
"censorship" is not something that users expect, nor that providers
offer.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 30 Aug 2019 21:08:45 -0700

On Fri, Aug 30, 2019 at 6:55 PM Ray Bellis <[email-masked]> wrote:

>
> I've also personally attended a meeting at the UK Home Office
>

Why should greater internet care about this? The UK has some well-meaning
regulations here, but they don't seem to be very effective or
well-specified.

thanks,
Rob