Subject: [Add] When Two Worlds Collide

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 14:55:36 +0000

Some of the more recent discussions (eg on the validity of the network administrator role) have made it clear to me that there are fundamental differences in world view between:  (i) the one hand, network operators / ISPs and others in that ecosystem; and (ii) browser companies / other applications developers.  These differences make it hard if not impossible to reach a mutual understanding of the potential problems and solutions.  Trying to bridge such differences via email is difficult if not impossible, as are time constraints at IETF events.

(NB To be clear, I'm not suggesting that the above is either an original or revolutionary observation!)

With that in mind, would others from each of these two communities see value in taking time for a more structured discussion in a workshop format, either face-to-face or virtually, to set out the challenges and benefits posed by DoH (and possibly also DoT etc if useful)?  My hypothesis is that a better understanding of the perspective of both communities would simplify discussions here, and at the very least help to focus minds on what the real issues are from the other's perspective.  This may in terms speed our path towards solutions.

Do you agree with the above analysis and, if so, would you see value in taking part in such a workshop?  By all means email me directly on this if you prefer not to clog up the mail reflector.

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 08:28:18 -0700

> Do you agree with the above analysis and, if so, would you see value in taking part in such a workshop?  By all means email me directly on this if you prefer not to clog up the mail reflector.  

I don’t think there’s any point in this (and I will point out that you did not mention users, just ISPs and browser vendors).   I think what Martin said here explains why this isn’t going to work: https://mailarchive.ietf.org/arch/msg/add/You2UXZbjDogcASupgZTzjdYVMs

If there is useful work to be done here, it is not in figuring out what rules should be followed.  What people will do will be based on their best interests, not on what the IETF tells them to do, because there isn’t an interop problem here.   What we can and perhaps should do is, as Martin said, do some dispassionate assessment of the use cases and how the prevalence of DoH changes things.

But we can’t do that as long as this feels to some participants like the problem is that there are differences in worldview between operators, users and browser vendors, and that what we need to do is to come into alignment about worldviews.

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 15:46:46 +0000

On Aug 15, 2019, at 16:28, Ted Lemon <[email-masked]> wrote:

> I don’t think there’s any point in this (and I will point out that you did not mention users, just ISPs 
> and browser vendors).   I think what Martin said here explains why this isn’t going to work: 
> https://mailarchive.ietf.org/arch/msg/add/You2UXZbjDogcASupgZTzjdYVMs

You're right that I didn't explicitly mention users, however I would hope that both communities would bring user perspectives into the discussion, accepting that their takes are likely to be quite different given the very different nature of their interactions with those users.  Other stakeholder views could also be very informative in this discussion as well.  For example, the views of regulators will be relevant in many geographies given that many ISPs around the world are regulated whereas many tech companies are not, at least for now.  

> If there is useful work to be done here, it is not in figuring out what rules should be followed.  
> What people will do will be based on their best interests, not on what the IETF tells them to do, 
> because there isn’t an interop problem here.   What we can and perhaps should do is, as 
> Martin said, do some dispassionate assessment of the use cases and how the prevalence of ?
> DoH changes things.
> 
> But we can’t do that as long as this feels to some participants like the problem is that there 
> are differences in worldview between operators, users and browser vendors, and that what 
> we need to do is to come into alignment about worldviews.

I evidently didn't express clearly enough what I meant.  I agree that there is no value in trying to figure out what rules should be followed, I do however think that there is value in spending time trying to understand in more detail why, for example, DoH and possibly other protocols are cause for concern to ISPs and others from an operational perspective and conversely why browser companies and others evidently feel strongly that DoH provides compelling benefits not available to them via other protocols.  

In my experience, gaining a better understanding of an alternate perspective, as opposed to an alignment, is often the precursor to identifying a productive way forward.  Without that understanding we could expend a great deal of time and energy without making any useful progress.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 08:55:02 -0700

> I evidently didn't express clearly enough what I meant.  I agree that there is no value in trying to figure out what rules should be followed, I do however think that there is value in spending tim…

Right, this is what I mean.   There is no lack of clarity in any of the people here who are proponents of DoH in terms of what its impact is on service providers.   We do not think “la li lu, DoH causes no problems.”   We all understand that DoH causes problems.   I doubt there is any disagreement at all on what problems DoH causes for SPs.   So it would be pointless to have a conversation about that.

E.g., if you look at this message from Bret: https://mailarchive.ietf.org/arch/msg/add/wRRmJKwg1Nie_NfBlPLt_c31y8k

There is nothing in here that I disagree with.   All of these are real concerns.   If you look at Martin’s message that I quoted, he reflects back other concerns that have been raised here by operators and agrees that they are valid concerns.   So the problem is not that we need to understand in more detail why Doh is causing concern for ISPs and others.

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 17:45:03 +0000

On Aug 15, 2019, at 16:55, Ted Lemon <[email-masked]> wrote:
> Right, this is what I mean.   There is no lack of clarity in any of the people here who are 
> proponents of DoH in terms of what its impact is on service providers.   We do not think 
> “la li lu, DoH causes no problems.”   We all understand that DoH causes problems.   I 
> doubt there is any disagreement at all on what problems DoH causes for SPs.   So it 
> would be pointless to have a conversation about that.

I don't think that either of us can claim to speak for others, however I note that the above is a clear statement of your personal position.  

> If you look at Martin’s message that I quoted, he reflects back other concerns that have 
> been raised here by operators and agrees that they are valid concerns.   So the problem 
> is not that we need to understand in more detail why Doh is causing concern for ISPs 
> and others.

Interestingly I know a number of ISPs that thought some comments, eg in the material presented at IETF 105, underlined the gulf in understanding of issues between browser companies and ISPs, clearly showed that they were talking passed each other.  

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 13:57:54 -0400

> Interestingly I know a number of ISPs that thought some comments, eg in the material presented at IETF 105, underlined the gulf in understanding of issues between browser companies and ISPs, clearl…

I agree that we are taking  past each other.  But it’s not because DoH proponents aren’t aware of the problems DoH creates for network operators.

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 09:12:54 -0600

So DoH proponents willfully do not care?   

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Aug 15, 2019, at 11:57 AM, Ted Lemon <[email-masked]> wrote:
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 16:25:24 +0100

On Fri, 16 Aug 2019, 16:13 Bret Jordan, <[email-masked]> wrote:

I would characterise my position as: having considered the cost-benefit
analysis, DNS over HTTPS wins.

It's that simple. I care, but not so much as I care about the benefits that
I expect DoH to provide.

-a

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 11:34:17 -0400

> So DoH proponents willfully do not care?   

Incorrect. I can’t speak for others, but to me it’s a situation where we have to choose.  And the choice is very clear. But that does not mean that we aren’t aware that we are making a choice, not does it mean that we aren’t aware of the downsides of the option we feel is the best choice. 

If we were talking about how to mitigate the problems, you would see me trying to help with that. Instead we are talking about which of two options to choose, when the choice has already been made.

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 09:58:45 -0600

The problem is you are trying to make a choice for everyone, assuming that you know what is best for everyone under every situations and condition.  That sounds like a country that I do not want to visit. 

Thanks,
Bret

> On Aug 16, 2019, at 9:34 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 16 Aug 2019 12:08:25 -0400

On Thu, Aug 15, 2019 at 10:55 AM Andrew Campling
<[email-masked]> wrote:

> Some of the more recent discussions (eg on the validity of the network
> administrator role) have made it clear to me that there are fundamental
> differences in world view between:  (i) the one hand, network operators /
> ISPs and others in that ecosystem; and (ii) browser companies / other
> applications developers.  These differences make it hard if not impossible
> to reach a mutual understanding of the potential problems and solutions.
> Trying to bridge such differences via email is difficult if not impossible,
> as are time constraints at IETF events.
>
> (NB To be clear, I’m not suggesting that the above is either an original
> or revolutionary observation!)
>
> With that in mind, would others from each of these two communities see
> value in taking time for a more structured discussion in a workshop format,
> either face-to-face or virtually, to set out the challenges and benefits
> posed by DoH (and possibly also DoT etc if useful)?  My hypothesis is that
> a better understanding of the perspective of both communities would
> simplify discussions here, and at the very least help to focus minds on
> what the real issues are from the other’s perspective.  This may in terms
> speed our path towards solutions.
>
> Do you agree with the above analysis and, if so, would you see value in
> taking part in such a workshop?  By all means email me directly on this if
> you prefer not to clog up the mail reflector.
>
>

The discussions yesterday on various subjects were IMO helpful in
determining corner cases and available mechanisms.

I think this ends up reducing to two separate sets of use cases which may
require different treatment.

I also believe both of those use cases are in need of further work, but I
think the work on those can probably "fork" without too much loss of shared
benefits. I.e. IMO they are different enough that trying to force a single
solution onto both won't work.

The way I'd separate the use cases is:

   1. Unmanaged devices on partially managed networks which are not trusted
   (home networks, guest networks at enterprises, coffee shops, etc.)
   2. Managed devices on managed networks (the proper enterprise case, plus
   analogous environments with stricter controls from the operator, such as
   Paul Vixie's home network.)

The root of the 2nd problem's issues have to do with some of the
assumptions built into things like split-brain DNS, filtered DNS, etc.
Those basically require that there be a single entry point into resolution
(single semantically at least, but possibly not physically). There are
other problems with having the applications' configurations exposed to
users, and with applications  having possibly diverging DNS world-views.

The 1st problem's issues are smaller in scope, and generally relate to
filtering. I have a few ideas there, and I think those would benefit from
Andrew's suggestion of workshop(s).

My expectation is that some of the 1st problem's work may lead to
additional requirements for DoH/DoT to support those.

I also expect that these potential additions will add to, rather than
subtract from, the privacy support, while preserving the specific benefits
of (and in some cases, requirements for) user protection via DNS filtering.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 09:16:05 -0700

On Aug 16, 2019, at 9:08 AM, Brian Dickson <[email-masked]> wrote:
> Those basically require that there be a single entry point into resolution (single semantically at least, but possibly not physically).

It would be helpful if we could acknowledge that in the absence of a completely locked down userland on a device with secure boot validation, this is completely impossible, and any proposal that is based on the assumption that it is possible is not worth spending time documenting.  Or if it is worth spending time documenting, I haven’t heard a good justification for why that’s so.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 16 Aug 2019 12:39:37 -0400

On Fri, Aug 16, 2019 at 12:16 PM Ted Lemon <[email-masked]> wrote:

> (single semantically at least, but possibly not physically).
>
>
> It would be helpful if we could acknowledge that in the absence of a
> completely locked down userland on a device with secure boot validation,
> this is completely impossible, and any proposal that is based on the
> assumption that it *is* possible is not worth spending time documenting.
> Or if it is worth spending time documenting, I haven’t heard a good
> justification for why that’s so.
>
>
That is precisely why I am proposing forking these two use cases. The
majority of ongoing discussion should be for the other one, the one that
does not meet those requirements.

There is a consequence to that forking: mathematical logic says, given a
rule that "A implies B", and a statement of fact that "B is false", the
implication is that "A is also false".

What this means is, from an enterprise network security perspective, if any
of those conditions is not satisfied (locked down userland, secure boot, no
access to DNS resolution configuration in userland and thus none of the
current ADD implementations), the device needs to be treated as unmanaged
and insecure, and placed on guest networks only.

The other branch of the fork may allow some form of DoT/DoH, albeit with
restrictions on configuration of resolver at a minimum.

My questions and ideas yesterday were an attempt to discover whether it was
possible to combine the two forks in a single solution.

I am acknowledging that it is not possible.

Brian

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 16:42:57 +0000

On Aug 16, 2019, at 17:16, Ted Lemon <[email-masked]> wrote:

> It would be helpful if we could acknowledge that in the absence of a completely locked down 
> userland on a device with secure boot validation, this is completely impossible, and any proposal 
> that is based on the assumption that it is possible is not worth spending time documenting.  Or 
> if it is worth spending time documenting, I haven’t heard a good justification for why that’s so.

Perhaps you could you suggest an alternate characterisation of the relevant use cases?  Or is it your view that there is only a single valid use case?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 10:04:27 -0700

> Perhaps you could you suggest an alternate characterisation of the relevant use cases?  Or is it your view that there is only a single valid use case?  

Security is always about tradeoffs.   There is no such thing as absolute security.  The IETF is doing a lot of hard work to try to make the ecosystem as secure as possible.  This is a different strategy than the lock-everything-down strategy I just described.   But e.g. take a look at the work being done in TEEP and SUIT.

The reason that the security geeks are reacting the way we are to this discussion is that DoH is part of making the ecosystem as secure as possible.  It is not the only way to do this, but when you compare the costs and benefits of using DoH to the costs and benefits of trusting the network’s resolver, it’s pretty clear which of these choices makes the ecosystem more secure.  It’s also clear that this has a cost in some cases: in some cases the network’s resolver really is more secure.   But we don’t have a way to validate that assertion, and even if we did, we don’t have a way to enforce it without locking things down as I described.

But again, if your use case is “secure, locked down,” then do the work to make that happen.  Don’t pretend that DHCP is secure.  Don’t pretend that Do53 is secure.   The hard shell, gooey interior model of network security has been definitely shown to be invalid.   If you still imagine that this model works, it’s going to be hard to have a meaningful discussion.

There are real scenarios where we must have the locked down network that only allows locked down devices to participate.   And we don’t fully understand how to do that.  This is an important area of research.   We need this, e.g. for cars, airplanes, power plants, banks, etc.   But the presence or absence of DoH support in Firefox is not going to make an iota of difference for these use cases.   These use cases require you to assume that DoH is present, and act accordingly, treating rogue DoH as a threat, and considering friendly DoH that has been authenticated as a potential piece of the solution.

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 11:53:42 -0600

> It is not the only way to do this, but when you compare the costs and benefits of using DoH to the costs and benefits of trusting the network’s resolver, it’s pretty clear which of these choices makes the ecosystem more secure.  

In your opinion.  The problem with this whole debate is the absolutes and claiming that one’s opinion is the consensus or is by default the best thing to do.  Where is the research and data that backs that up?  

Bret

---

From: Bob Harold <[email-masked]>
Date: Fri, 16 Aug 2019 14:05:23 -0400

On Fri, Aug 16, 2019 at 12:08 PM Brian Dickson <
[email-masked]> wrote:

> require different treatment..
>
>    1. Unmanaged devices on partially managed networks which are not
>    trusted (home networks, guest networks at enterprises, coffee shops, etc.)
>    2. Managed devices on managed networks (the proper enterprise case,
>    plus analogous environments with stricter controls from the operator, such
>    as Paul Vixie's home network.)
>

Unfortunately, we have a third case:  (Especially in a university network)
3. Unmanaged devices on a managed network.

We know we won't have absolute security, but we need to do the best we
can.  At the moment, split DNS is necessary, and RPZ is an important layer
of security. DoT or DoH to our internal DNS would be fine.  We know that
some users will use the quads, and that is their choice.  But DoH to an
external network *without an explicit choice by the user* is not a solution
that I can endorse.  Does that make sense?

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 11:05:51 -0700

> In your opinion.  The problem with this whole debate is the absolutes and claiming that one’s opinion is the consensus or is by default the best thing to do.  Where is the research and data that ba…

It’s not a matter of opinion, any more than it’s a matter of opinion that if you have two apples and I give you two more, you now have four apples.   We are continuing to argue this because you think that math is subject to opinions.

DHCP doesn’t provide a way to authenticate it.   I know this—I’m one of the authors of RFC 3315, and the DHC working group worked for quite a while to come up with an authentication model for DHCP that made sense.   We failed.

DoH does provide a way to authenticate it, and it makes it relatively straightforward for different consumers of DNS resolution to make (and validate!) different choices of resolver.

DoH can’t be blocked without locking down every device on the network.

These are not opinions.   These are facts.   If you think they are not facts, let’s see your math.

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 13:19:28 -0600

These are opinion statements.  Not math.  Just because you do not like the views of the other side, does not mean they are invalid. It is your opinion that a QuadX DoH resolver is less dangerous than the DNS (DoH or Do53) that is provided by your internal network.  That is your opinion and clearly not shared by many on this list.  Some yes, others no. 

Which is a bigger risk for Privacy?  Getting blocked by some filtering DNS or having all of your data be capture, stored, analyzed, and cross correlated?

You say DHCP is not authenticated.. You are right. But as a network administrator you can put in compensating controls to address this.  You can identify very easily if there is more than one DHCP server on your network or a rouge device performing a race condition to trick endpoints.  I was checking for this back in the late 80s early 90s.

Dealing in absolutes and single use-cases and forcing them to apply to everyone is just not right.  

Thanks,
Bret

> On Aug 16, 2019, at 12:05 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 16, 2019, at 10:53 AM, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Aug 2019 19:34:55 +0000

> DoH can’t be blocked without locking down every device on the network.

It’s easy enough to block well-known public DNS resolver IP addresses (or public DNS resolvers using port 443) without locking down every device. Pretty trivial, really.
I've been experimenting with how to do this effectively on my home network, so I'll be ready when applications try to hijack my DNS choices.
Barbara

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 13:43:47 -0600

Just like there are threat intelligence feeds that track bot nets [1] and things like Shodan [2], I am sure someone will come along and produce a threat feed for DoH servers that you can subscribe to or search for.  You can then just list all of them in your IPS or Firewall or as ACLs at your edge and block them.  For organizations that do analysis at the Firewall or have a Proxy, this is super trivial to address and even rewrite on the fly. I have even seen Cisco showing of tools that can do analysis of encrypted traffic without decrypting it. So I am sure there will be many solutions that can block DoH without hardening the endpoint.  

[1] https://abuse.ch/ <https://abuse.ch/>
[2] https://www.shodan.io/ <https://www.shodan.io/>

Thanks,
Bret

> On Aug 16, 2019, at 1:34 PM, STARK, BARBARA H <[email-masked]> wrote:
>

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 15:52:17 -0400

On 16 Aug 2019, at 15:34, STARK, BARBARA H <[email-masked]> wrote:

> It’s easy enough to block well-known public DNS resolver IP addresses (or public DNS resolvers using port 443) without locking down every device.

Several people who run substantial IT networks have told me that they were already set up to strip SSL at their border and inspect the contents of all TLS-wrapped traffic before DoH was even standardised. They did this because it fit the security posture they had already identified as being necessary based on a risk analysis. They distribute organisation-specific certificates to devices used on their network to make this work.

A couple of them have recommended particular firewall products to do this.

A couple of them are already happily blocking DoH because they have their own requirements for devices to use internally-operated resolvers that (e.g.) block resolution of certain domains, e.g. as part of a malware mitigation strategy. They are blocking DoH without needing to curate a list of well-known DoH services by address.

I understand that in many IT networks that use DNS-based control planes much of what I described above is extra work and extra expense. However, having unmanaged devices on your network means that all of this is always a moving target. Security is not absolute; you do the amount that makes sense given your risk analysis.

Some people have laughed bitterly about the fact that DoH (for privacy!) has the run-on effect of SSL-stripping *all* TLS traffic at your border (for surveillance!) and so the outcome doesn't match the goal. I suspect that the situations where that's true are places where there was already limited expectations of privacy (many corporate networks I have attached to, the Internet within the borders of some jurisdictions, home networks operated by Paul Vixie who very reasonably imposes his own rules), although I am wary of generalisation.

People used to spend nothing on security. Now they spend more. Tomorrow the costs will go up. This is kind of the nature of the game.

I don't understand why people insist that blocking DoH is impossible, when what they really mean is that there's a threat today that wasn't there yesterday, and now we have to deal with that as well.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 12:55:06 -0700

On Aug 16, 2019, at 12:19 PM, Bret Jordan <[email-masked]> wrote:
>  It is your opinion that a QuadX DoH resolver is less dangerous than the DNS (DoH or Do53) that is provided by your internal network. 

I’m sorry, maybe I haven’t been very skillful in responding to you on this.   I think I see where the disconnect is now.   I don’t actually think this.   Let’s enumerate the players here:

Do53 resolver on the local network
DoT resolver on the local network
DoH resolver on the local network
DoH resolver on QuadX, as you put it
DoH resolver on my home network, reachable from outside
DoH resolver on my ISP’s network, reachable from outside

And:
Locked down host, can’t access any resolver other than that configured by the operator
BYO host, not controlled by the operator

If we have host (1), is it better off communicating with resolvers (1), (2), or (3)?   That is, what should the local operator configure?

The answer is that it depends on the network.   If the network is locked down as you say, and the device can’t leave the facility, then it’s probably just a matter of whether the operator cares that the queries are going over the wire in the clear.  If, on the other hand, the network can’t be locked down quite that tightly, then it may be worthwhile to have PKI authentication.   If I were setting this up, I’d install a cert on all site-owned devices, and use that to validate that I’m really talking to the DoT or DoH resolver I intend.   Now, whether to use DoT or Doh is just down to whether I’m concerned about blocking.   If I’m concerned about blocking, DoH is better; if I’m not, I think it’s about even.

Now, what if we have device (2) on a locked-down network?   The operator has two choices.   Either allow the device to do DoH, or block all outgoing connections that aren’t explicitly permitted, including connections to port 443.   If such hosts want to connect out, they have to go through a proxy that can look at the HTTP traffic.

Now, consider the case of your own device.  If you are carrying it around, there will be places where your traffic can be snooped.   But it’s not going to be easy to aggregate it (probably, depends on the operators of the networks amongst which you wander, and the configuration of your handset).  If you connect to resolver (4), then your queries can be aggregated and perhaps correlated with your web traffic.   I agree that that’s bad, and something to try to avoid.

I also agree that a resolver on your home network that you connect to from off-site may be better than (4), even though it allows your ISP to track your DNS traffic.

But what I was talking about was not this sort of modeling.   What I was talking about are simply the security properties of the various players.   Any DoH or DoT resolver can be authenticated, because you are connecting to it over TLS.   No Do53 resolver can be authenticated.   If you are able to authenticate the network, meaning that you are using 802.1X and evaluating the cert in a secure way (which is not trivial to configure), and you know that it is operated in such a way that a rogue Do53 resolver would not be reachable by your device, then when you are on that network, that resolver is equivalently safe whether you are talking to it with Do53, DoT or DoH.   When you are on some other network, it is only safe it you talk to it using DoH or DoT.

Another security property: DoH can be used on any network where HTTPS traffic is allowed to exit without being examined.   Sure, you can maintain a blocklist, but this is going to be a losing battle: the people who are motivated to make DoH work will figure out ways to make it work around your block list.

Another security property: DoT can be blocked, because it doesn’t look just like HTTPS traffic.

These security properties are facts.   Which resolver is safer to use is an opinion.   I have a great deal of sympathy for your opinion about QuadX resolvers, and had no intention of arguing with you about that opinion.   Where the disconnect came in is that it appeared that you were contradicting facts in the process of arguing your opinion.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 12:57:28 -0700

On Aug 16, 2019, at 12:52 PM, Joe Abley <[email-masked]> wrote:
> Some people have laughed bitterly about the fact that DoH (for privacy!) has the run-on effect of SSL-stripping *all* TLS traffic at your border (for surveillance!) and so the outcome doesn't match the goal.

In a sense, it’s a win that this is the case: if people whose security model depends on this kind of blocking weren’t doing it before, they were at risk.   The prevalence of DoH is forcing them to do what they ought to have been doing in the first place.

As an added bonus, no sensible person would use a network that does this for anything but its intended purpose.

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 21:28:08 +0100

On Fri, 16 Aug 2019, 20:52 Joe Abley, <[email-masked]> wrote:

>
> Some people have laughed bitterly about the fact that DoH (for privacy!)
> has the run-on effect of SSL-stripping *all* TLS traffic at your border
> (for surveillance!) and so the outcome doesn't match the goal.
>

I would be surprised if DoH was truly the cause of that, since (unless you
embrace instrumenting the clients) I understand that full MITM will be a
necessity for filtering TLS 1.3, which will be far more impactful than DoH
in this respect:

https://forums.theregister.co.uk/forum/all/2018/08/13/tls_13_approved/

-a

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 21:30:19 +0100

> https://forums.theregister.co.uk/forum/all/2018/08/13/tls_13_approved/

Oops; article link:
https://www.theregister.co.uk/2018/08/13/tls_13_approved/

-a

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 21:47:11 +0100

Incidentally, for anyone who is unfamiliar with exactly this same argument
as applied to TLS 1.3, this Twitter thread of mine from 2018 may serve as a
primer:

https://twitter.com/AlecMuffett/status/977267092541100039

>A source in the room described it to me as having been (attempted to be)
"packed" with people to support the [surveillance] extension, ostensibly in
support of banking compliance — link below — irrespective that /my/ friends
in the City are quite sanguine about TLS1.3.
[images]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 23:10:13 +0200

I'd like to note that it's not necessary to MITM DoH traffic. In order to
deploy a MITM proxy, you need to control the devices in the network (so you
can install a trust anchor). In this case, you can simply use that same
access to disable DoH directly or point it at your own server.

-Ekr

On Fri, Aug 16, 2019 at 9:52 PM Joe Abley <[email-masked]> wrote:

> > It’s easy enough to block well-known public DNS resolver IP addresses
> (or public DNS resolvers using port 443) without locking down every device.
>
> Several people who run substantial IT networks have told me that they were
> already set up to strip SSL at their border and inspect the contents of all
> TLS-wrapped traffic before DoH was even standardised. They did this because
> it fit the security posture they had already identified as being necessary
> based on a risk analysis. They distribute organisation-specific
> certificates to devices used on their network to make this work.
>
> A couple of them are already happily blocking DoH because they have their
> own requirements for devices to use internally-operated resolvers that
> (e.g.) block resolution of certain domains, e.g. as part of a malware
> mitigation strategy. They are blocking DoH without needing to curate a list
> of well-known DoH services by address.
>
> I understand that in many IT networks that use DNS-based control planes
> much of what I described above is extra work and extra expense. However,
> having unmanaged devices on your network means that all of this is always a
> moving target. Security is not absolute; you do the amount that makes sense
> given your risk analysis.
>
> (for surveillance!) and so the outcome doesn't match the goal. I suspect
> that the situations where that's true are places where there was already
> limited expectations of privacy (many corporate networks I have attached
> to, the Internet within the borders of some jurisdictions, home networks
> operated by Paul Vixie who very reasonably imposes his own rules), although
> I am wary of generalisation.
>
> People used to spend nothing on security. Now they spend more. Tomorrow
> the costs will go up. This is kind of the nature of the game.
>
> I don't understand why people insist that blocking DoH is impossible, when
> what they really mean is that there's a threat today that wasn't there
> yesterday, and now we have to deal with that as well.
>
>
> Joe
> --
> Add mailing list
> [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Fri, 16 Aug 2019 16:15:43 -0500

> In your opinion.  The problem with this whole debate is the absolutes and claiming that one’s opinion is the consensus or is by default the best thing to do.  Where is the research and data that ba…

This seems unlikely to be productive. When people bring up the behaviors 
that are driving applications to directly use encrypted DNS, there is a 
certain subset of operators who feel attacked, and who claim they're 
being painted as "the bad guys." I've received off-list correspondence 
indicating that at least one operator felt that their participation in 
this conversation was becoming more difficult exactly because of this 
factor.

So I think it would be far more useful to focus on solvable problems -- 
like "best practices for deploying DoH and DoT" -- than it would be 
trying (almost certainly in vain) to come to consensus on which approach 
is actually "more secure."

/a

---

From: Rob Sayre <[email-masked]>
Date: Fri, 16 Aug 2019 14:26:10 -0700

On Fri, Aug 16, 2019 at 2:16 PM Adam Roach <[email-masked]> wrote:

> like "best practices for deploying DoH and DoT"
>

Documents like that tend to be more effective when there's more deployment
experience. It seems a little premature to write one of those right now.
Doing nothing, and then seeing what happens, is always an option.

A lot of the suggestions have veered into UI preferences and OS APIs, both
of which are out of scope for the IETF.

It seems like a subset of list participants want a document that says
shipping software that defaults to a centralized resolver is against the
rules in some way. I'm not sure there's a useful way to specify that, at
least in the IETF.

thanks,
Rob

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 17:32:06 -0400

Hey,

On 16 Aug 2019, at 17:10, Eric Rescorla <[email-masked]> wrote:

> I'd like to note that it's not necessary to MITM DoH traffic. In order to deploy a MITM proxy, you need to control the devices in the network (so you can install a trust anchor). In this case, you can simply use that same access to disable DoH directly or point it at your own server.

Insisting on a local certificate to be trusted being trusted by those uncontrolled devices is straightforward; device owners either install the certificate or you don't get to use HTTPS. It's the kind of problem that solves itself. It's control without the need for direct management.

I agree that if you don't allow unmanaged devices on your network you have a different set of options.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 23:35:34 +0200

On Fri, Aug 16, 2019 at 11:32 PM Joe Abley <[email-masked]> wrote:

> > I'd like to note that it's not necessary to MITM DoH traffic. In order
> to deploy a MITM proxy, you need to control the devices in the network (so
> you can install a trust anchor). In this case, you can simply use that same
> Insisting on a local certificate to be trusted being trusted by those
> uncontrolled devices is straightforward; device owners either install the
> certificate or you don't get to use HTTPS. It's the kind of problem that
> solves itself. It's control without the need for direct management.
>

My impression is that generally this is not done through manual
installation but rather through some sort of management system.

In any case, if you can get users to do this you can get them to disable
DoH.

-Ekr

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 17:42:30 -0400

On 16 Aug 2019, at 17:35, Eric Rescorla <[email-masked]> wrote:

> My impression is that generally this is not done through manual installation but rather through some sort of management system.

No doubt that would be a better approach, if you had some sort of management system.

> In any case, if you can get users to do this you can get them to disable DoH.

I believe the concern is that users may be unwittingly carrying in devices containing software they either don't understand the behaviour of or don't realise is there.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 23:50:58 +0200

On Fri, Aug 16, 2019 at 11:42 PM Joe Abley <[email-masked]> wrote:

> I believe the concern is that users may be unwittingly carrying in devices
> containing software they either don't understand the behaviour of or don't
> realise is there.
>

No, I get that  but then you wont be able to MITM either.

My point is that either (1) you can do MITM, in which case you can disable
DoH or (2) you cannot disable DoH, in which case you won't be able to MITM
anyway. But in neither case should you need to MITM DoH.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Fri, 16 Aug 2019 14:54:20 -0700

> containing software they either don't understand the behaviour of or don't

Yes, "bring your own device". I think the tension is that DoH will make it
more difficult to call these arrangements "secure", but all of the
proposals that aim to preserve this claim amount to a backdoor or
in-the-clear downgrade that weakens security for all internet users.
Organizations that actually value security will provide devices and manage
them.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Aug 2019 23:07:10 +0100

Hiya,

> anyway. But in neither case should you need to MITM DoH.

Well.... not quite. I think you're assuming how mozilla are
implementing DoH - some other application might not have a
way to disable DoH at all. And of course, some enterprise
admin might conclude that it's easier for them to MitM TLS
than to document HOWTO disable DoH for different versions
of many different applications, if they can infest an OS
root store covering all those applications.

All of which is IMO pretty shitty, but might argue for
some guidance as to how to achieve a bit more consistency
in a few aspects of how clients implement DoH. (Not very
confident of that though TBH, could be that encouraging
radical diversity in implementation strategy might be as
not-good-but-less-bad as consistency;-)

Cheers,
S.

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 18:08:27 -0400

On 16 Aug 2019, at 17:50, Eric Rescorla <[email-masked]> wrote:

> My point is that either (1) you can do MITM, in which case you can disable DoH or (2) you cannot disable DoH, in which case you won't be able to MITM anyway. But in neither case should you need to MITM DoH.

I'm confused. This is not unusual.

A user walks into the office with their personal, unmanaged phone. They join the wifi. Some things work, but many things do not. User not technical. What happen. Call IT.

User's problems relate to the fact that all HTTPS is effectively blocked because much software on their device reacts badly to the certificates being presented by the corporate firewall, which is MITMing all the HTTPS traffic it can identify through destination port number or deep packet inspection.

IT person says here, scan this QR code on the poster and follow the instructions. Some eye-rolling accompanies the need to point finger at large, obvious poster; some inference that most people don't need finger to notice poster. User does that, all now work.

The certificate that the user's device retrieved was served from an internal server and is installed on the unmanaged device as a trust anchor. Maybe the certificate that is installed through this process is insufficient for some applications, but most of them now seem to work just fine. The certificate presented by the MITMming corporate firewall is now accepted by the user's applications, and the firewall ALGs them all through to their external destinations with whatever meddling it feels like doing to the plain text as data is shuffled back and forth.

User now happy.

I should hasten to add that I haven't tried this myself, I've just listened to people who do. Is there some nuance here that I am missing?

Joe

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 15:14:39 -0700

> I should hasten to add that I haven't tried this myself, I've just listened to people who do. Is there some nuance here that I am missing?

I think Eric is making the very narrow technical point that if you are able to intercept the DoH connection, there is no need to then terminate it on its intended server.  You can just do the DoH resolution at the point of intercept.   Hence, there is no middle, and no man in the middle.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Aug 2019 22:26:17 +0000

On Aug 16, 2019, at 3:07 PM, Stephen Farrell <[email-masked]> wrote:
> implementing DoH

Agree.

> - some other application might not have a
> way to disable DoH at all.

And yet other applications might not use TRRs, but just set up their own DoH server that firewall admins don't even know about. If some started hard-wiring classic DNS on 8.8.8.8 (and it appears that some non-Google apps have done this, more data to collect), then little is to stop them from hardwiring DoH or some non-standard DNS over HTTPS to their own infrastructure.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Aug 2019 00:43:57 +0200

On Sat, Aug 17, 2019 at 12:08 AM Joe Abley <[email-masked]> wrote:

> > My point is that either (1) you can do MITM, in which case you can
> disable DoH or (2) you cannot disable DoH, in which case you won't be able
> to MITM anyway. But in neither case should you need to MITM DoH.
>
> A user walks into the office with their personal, unmanaged phone. They
> join the wifi. Some things work, but many things do not. User not
> technical. What happen. Call IT.
>
> User's problems relate to the fact that all HTTPS is effectively blocked
> because much software on their device reacts badly to the certificates
> being presented by the corporate firewall, which is MITMing all the HTTPS
> traffic it can identify through destination port number or deep packet
> inspection.
>
> IT person says here, scan this QR code on the poster and follow the
> instructions. Some eye-rolling accompanies the need to point finger at
> large, obvious poster; some inference that most people don't need finger to
> notice poster. User does that, all now work.
>

Why can't those instructions describe how to turn off DoH?

-Ekr

> The certificate that the user's device retrieved was served from an
> internal server and is installed on the unmanaged device as a trust anchor.
> Maybe the certificate that is installed through this process is
> insufficient for some applications, but most of them now seem to work just
> fine. The certificate presented by the MITMming corporate firewall is now
> accepted by the user's applications, and the firewall ALGs them all through
> to their external destinations with whatever meddling it feels like doing
> to the plain text as data is shuffled back and forth.
>
> User now happy.
>
> I should hasten to add that I haven't tried this myself, I've just
> listened to people who do. Is there some nuance here that I am missing?
>
>
> Joe
>

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 17:08:13 -0700

On Aug 16, 2019, at 18:43, Eric Rescorla <[email-masked]> wrote:

That seems like a degenerate case of modifying the traffic carried within
HTTPS, which is what I was trying to describe. So I don't really understand
the question.

Perhaps what is missing is the need to MITM HTTPS for reasons other than
DoH in a network that accepts unmanaged devices, which I mentioned earlier.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Aug 2019 02:33:16 +0200

> DoH in a network that accepts unmanaged devices, which I mentioned earlier.

I also do not understand your question. This is not about managed versus
unmanaged.

Suppose that you have a policy that requires some level of HTTPS MITM. In
order to execute that policy, you need to modify user's computers (either
via a management interface or otherwise) or convince the user to modify
their computers. At that time, you can also disable DoH or convince users
to disable DoH (assuming, as Stephen says, that DoH can be disabled).
Therefore, there should not be a need to MITM DoH traffic, because you can
just divert it to Do53.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Fri, 16 Aug 2019 17:39:28 -0700

> I also do not understand your question. This is not about managed versus

I don't understand it either. Do people really think DNS isn't currently
happening over HTTPS in unstandardized ways?

Is the idea that we're all supposed to pretend that ineffective security
works because someone sells it?

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 16 Aug 2019 18:15:14 -0700

On Fri, Aug 16, 2019 at 2:16 PM Adam Roach <[email-masked]> wrote:

> When people bring up the behaviors

Well, I guess the salient question is "so what?". It seems weird to view
giant telecom companies as oppressed participants.

Maybe their arguments just aren't very good.

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Fri, 16 Aug 2019 21:20:10 -0400

> On Aug 16, 2019, at 8:33 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> That seems like a degenerate case of modifying the traffic carried within HTTPS, which is what I was trying to describe. So I don't really understand the question.
>> 
>> Perhaps what is missing is the need to MITM HTTPS for reasons other than DoH in a network that accepts unmanaged devices, which I mentioned earlier. 
> 
> I also do not understand your question. This is not about managed versus unmanaged. 
> 
> Suppose that you have a policy that requires some level of HTTPS MITM. In order to execute that policy, you need to modify user's computers (either via a management interface or otherwise) or convince the user to modify their computers. At that time, you can also disable DoH or convince users to disable DoH (assuming, as Stephen says, that DoH can be disabled). Therefore, there should not be a need to MITM DoH traffic, because you can just divert it to Do53.
> 
> -Ekr

Hi, Ekr,

Many messages from you today have talked about turning off DoH or diverting to Do53.

I’m confused by this, since AFAICT you are in favor of DoH. Why would you advocate turning off DoH?

Given the potential number of apps doing DNS, the possibility of unknown apps doing DNS, and the possibility that those might be using different resolvers, MitM on DoH would appear to scale better and enable many of the services that non-MitM DoH effectively disabled. This could be accomplished by redirecting to a different DoH server, or by implementing the needed features as a transparent network function (eg RPZ), particularly on the responses rather than on the queries.

I’d rather see the benefits of DoH, than block it entirely. The vast majority of “block” use cases is where the preferred or required resolver isn’t the one being used by the app, or where split-dns is needed, or where RPZ is needed, or a rogue resolver is being used.

If a query isn’t internal, is not on a DNS black list (especially a real time one), and is going to an approved quadX resolver, having that occur over DoH isn’t terrible.

There are other things where the choice of resolver might be suboptimal, or where use of ECS is desired or necessary. Redirecting to a different DoH resolver (especially internal) may make sense in that use case.

I don’t see anyone asking for Do53, actually, so I’m confused... why do that?

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Aug 2019 03:53:17 +0200

> advocate turning off DoH?

I'm not advocating turning off DoH. I'm saying that if you control the
device, you can configure Firefox (and I would assume many other DoH-using
apps) either talk to some DoH resolver of your choice or to defer to the
system resolver. However, I expect that n the vast majority of those
settings, the resolver in question will be Do53, because that's what's
widely available.

-Ekr

---

From: Melinda Shore <[email-masked]>
Date: Fri, 16 Aug 2019 18:07:56 -0800

> Maybe their arguments just aren't very good.

obNoHats:

I'm in the process of catching up on the discussion and am
fairly dismayed by the tone.  If their arguments aren't
very good, refute them.  Comments like this don't move the
technical discussion at all.

The primary thing I'm looking for as I'm sifting through the
discussion is to try to identify useful work that's within
the IETF's purview, and to understand the assumptions that
various parties are bringing to the table.  I think that
policy impacts are inevitable but we are not primarily a policy
organization and tend to be more successful when we focus on
technical discussion.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 22:35:03 -0700

> On Aug 16, 2019, at 20:33, Eric Rescorla <[email-masked]> wrote:
>

I don't actually think I was asking a question, but I still feel like
I'm missing something. So here we go.

> Suppose that you have a policy that requires some level of HTTPS MITM. In order to execute that policy, you need to modify user's computers (either via a management interface or otherwise) or convince the user to modify their computers. At that time, you can also disable DoH or convince users to disable DoH (assuming, as Stephen says, that DoH can be disabled).

Ok.

> Therefore, there should not be a need to MITM DoH traffic, because you can just divert it to Do53.

Well, this is where I think we differ in the way we are thinking about
managed vs unmanaged.

We're talking here about a one-time change to an unmanaged device.
However, subsequent changes can be made and new applications can be
installed by the user without the network administrator's supervision.
Those could include removing whatever change made the device
compliant, e.g. re-enabling DoH or installing a new application like a
future Firefox that uses it by default. These changes don't
necessarily need to be deliberate on the part of the end-user. So this
one-time action by the user or the IT administrator doesn't seem, on
its own, like a permanent application of policy to a single device.

Even if an administrator trying to enforce local policy could have
full knowledge of the range of configuration that might exist on an
unfamiliar/unmanaged device with an array of applications at one point
in time, I don't see how they could expect that state to be invariant
on a device that somebody else manages.

You are suggesting, I think, that a one time change to an otherwise
unmanaged device is sufficient to bring an unmanaged device into line
with an enterprise network policy that requires MITM of HTTPS traffic,
including DoH. I don't see how that works. Right now it feels like
MITM is the prudent choice for a network that has such a policy.

If the answer to all of this is that allowing unmanaged devices to
connect to a network that has such policy is not reasonable, then I
think we should say so clearly. There are lots of such networks in the
world. This not a corner case.

Anyway, the point I was making originally was that people are doing
this kind of MITM today, or at least it's possible for people to do
this today, and hence the suggestion that blocking DoH is impossible
seems false.

Joe

---

From: Rob Sayre <[email-masked]>
Date: Fri, 16 Aug 2019 22:50:30 -0700

> technical discussion at all.

If you give things a close read, I think you'll see various anti-encryption
arguments come up over and over. They are obviously non-technical, and talk
about things like "policy", "regulation", "parental control", "operational
concerns", etc. Even though these arguments are non-technical, I think you
will find all of them thoroughly debunked on this list. There are better
ways than DNS to accomplish all of them.

> the IETF's purview

While I don't want to stop anyone from writing software, I don't think
there is any useful work for the IETF to do at this time.

I also think some parties have overestimated their negotiation position.
It's always possible to deploy something, and document it later (as in RFC
6108).

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 17 Aug 2019 08:32:47 +0200

> I should hasten to add that I haven't tried this myself, I've just listened to people who do. Is there some nuance here that I am missing?

s/Corporate/Access Provider/

  Patrik

---

From: Brian Dickson <[email-masked]>
Date: Sat, 17 Aug 2019 11:23:00 -0400

Sent from my iPhone

> On Aug 16, 2019, at 10:07 PM, Melinda Shore <[email-masked]> wrote:
> 
> various parties are bringing to the table.

IMHO it isn’t enough to limit this to assumptions. It needs to include requirements, at least where those are reasonable, common, and well documented and well understood.

The IETF may not primarily be a policy organization, but failing to accommodate policy requirements would be unhelpful, IMHO.

Providing guidance on standardization for implementers of applications doing DNS could better accommodate interoperability between network operators and those applications.

One relatively simple example might be: check for a DNS server accepting connections on localhost (::1 or 127.0.0.1). If present, use it.
That would provide a standard place for a managed host to install its own service to implement whatever policies it desires, without requiring MitM.

Brian

>  I think that

---

From: Paul Ebersman <[email-masked]>
Date: Sat, 17 Aug 2019 11:00:31 -0600

sayrer> If you give things a close read, I think you'll see various
sayrer> anti-encryption arguments come up over and over. They are
sayrer> obviously non-technical, and talk about things like "policy",
sayrer> "regulation", "parental control", "operational concerns",
sayrer> etc. Even though these arguments are non-technical, I think you
sayrer> will find all of them thoroughly debunked on this list. There
sayrer> are better ways than DNS to accomplish all of them.

Really? Thoroughly debunked? By one slide deck you agree with versus
multiple folks with relevant market and industry experience saying the
contrary and multiple examples of this in use? How do you feel about
climate change?

Your own personal experiences are not proof.

And yes, DNS filtering is not 100%. But it is sufficiently useful and
deployable widely. What alternatives are as available, as deployable and
more effective?

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Aug 2019 13:24:17 -0400

Just a reminder: DoH resolvers can (and do) do DNS filtering. 

Sent from my iPhone

> On Aug 17, 2019, at 13:00, Paul Ebersman <[email-masked]> wrote:
>

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 12:10:31 -0700

On Sat, Aug 17, 2019 at 10:00 AM Paul Ebersman <[email-masked]> wrote:

> contrary and multiple examples of this in use?

I don't mean to imply there is consensus. In fact, I think there is none,
and no work should happen.

That said, an IETF DNS working group is the last place on earth I would
expect good security standards to come from. It's been at least 20 years
since the security problems with Classic DNS became apparent.

> How do you feel about

??

> Your own personal experiences are not proof.

They actually are, in the same way that people talk about their "home
networks" on this list.

> deployable widely. What alternatives are as available, as deployable and

Well, the problem is that it's hard to tell who's doing the filtering. For
example, see this attack:

<https://mailarchive.ietf.org/arch/msg/add/NIk8gIPZu52GXDsT8zy4S1I4QsM>

Sending encrypted DNS directly to 8.8.8.8 or equivalent mitigates this
attack. One thing I want to note is that the advantage of encrypted DNS
here has nothing to do with privacy, it's the message integrity encryption
brings that mitigates this attack.

This seems like a pretty standard encryption trade-off, and the IETF has
been pretty clear about its approach to those: encrypt. DNS isn't special.

thanks,
Rob

---

From: Joe Abley <[email-masked]>
Date: Sat, 17 Aug 2019 12:32:52 -0700

Hi Rob,

On Aug 17, 2019, at 15:10, Rob Sayre <[email-masked]> wrote:

> That said, an IETF DNS working group is the last place on earth I would expect good security standards to come from. It's been at least 20 years since the security problems with Classic DNS became apparent.

... and during that time work in and adjacent to dnsop has resulted in
a lot of good security standards. On the general topic of privacy a
whole other working group was spun up. A global PKI was designed,
implemented and deployed.

I'm a little tired of this general line of anti-dnsop rhetoric, to be
honest. I find it unproductive, inaccurate and insulting to a lot of
people who have put in a lot of work over a long time. I do not see
how it moves the conversation here any closer to any kind of
consensus.

Joe

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 12:38:39 -0700

On Sat, Aug 17, 2019 at 12:32 PM Joe Abley <[email-masked]> wrote:

> honest.

Maybe we should just focus on why this attack is still possible:

thanks,
Rob

---

From: Joe Abley <[email-masked]>
Date: Sat, 17 Aug 2019 16:07:13 -0400

> <https://mailarchive.ietf.org/arch/msg/add/NIk8gIPZu52GXDsT8zy4S1I4QsM>

Home gateways are well known to be vulnerable to a broad set of platform-based attacks. They are mass-produced using very low margins that rarely do not support the cost of even rudimentary software maintenance. See also dnschanger, which was a similar attack that exploited consumer operating systems. These attacks use the DNS, but they are not attacking the DNS protocol; they are attacking platforms that use the DNS.

For a long time, DNS protocol work was done in dnsext and the operation of the resulting implementations was handled in dnsop. dnsext was closed with the idea that indvidual, more tightly-chartered working groups would be created for specific new protocol development work instead.

To answer your question, the dane working group produced standards for verification of certificate authenticity that is (I am told) quite commonly used in mail systems but not so much in browsers. Integrity protection of the DNS results themselves in the form of DNSSEC was designed in dnsext and the operation of the resulting global system is within the dnsop charter. If the applications involved in the phishing enabled by this attack had been using DoH (doh working group) then the change of DNS settings in the router would not have affected them.

Use of TLSA (dane) and DNSSEC (dnsext) in applications, or applications using DoH with a suitable, non-compromised resolver, might well have helped to mitigate the attack you mentioned. TLSA and DNSSEC validation are not deployed by default in any browser that I know about, but that's not because the standards don't exist. DoH in the application is of course precisely what we are talking about here in another venue that has been spun up out of dnsop and dprive.

I may well have got some of the fine details wrong in the ietf dns family tree here, but you get the idea.

It feels like you intended that link (and that message) to be a pithy example of a tremendous failure in dnsop and other dns working groups, but I really don't see it that way.

Joe

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 13:33:32 -0700

On Sat, Aug 17, 2019 at 1:07 PM Joe Abley <[email-masked]> wrote:

>  These attacks use the DNS, but they are not attacking the DNS protocol;
> they are attacking platforms that use the DNS.
>

That sentence doesn't make sense to me. Isn't this precisely the kind of
attack TLS and HTTPS mitigate? See RFC 1958, section 6: "Endpoints should
not depend on the confidentiality or integrity of the carriers." <
https://tools.ietf.org/html/rfc1958#section-6>

>
> For a long time, DNS protocol work was done in dnsext and the operation of
> the resulting implementations was handled in dnsop. dnsext was closed with
> the idea that indvidual, more tightly-chartered working groups would be
> created for specific new protocol development work instead.
>
> To answer your question, the dane working group produced standards for
> verification of certificate authenticity that is (I am told) quite commonly
> used in mail systems but not so much in browsers. Integrity protection of
> the DNS results themselves in the form of DNSSEC was designed in dnsext and
> the operation of the resulting global system is within the dnsop charter.
>

Yes, it seems like DNSSEC does provide integrity and authentication in some
sense, but it's vulnerable to tampering on the wire (intentional or not).

> If the applications involved in the phishing enabled by this attack had
> been using DoH (doh working group) then the change of DNS settings in the
> router would not have affected them.
>

Agreed. The question is whether there's a way to enable
automatically-negotiated "DNS filtering" while preventing that attack. I
don't think there is. I also happen to think DNS filtering is pretend
security, and some parties are really more interested in monetizing
unencrypted DNS queries. But, reasonable people can disagree on that last
sentence.

> It feels like you intended that link (and that message) to be a pithy
> example of a tremendous failure in dnsop and other dns working groups, but
> I really don't see it that way.
>

I think this is a cultural disconnect. In my part of the internet, long
messages are usually viewed as disrespectful or at least presumptuous.

Since I responded to a message that quite publicly questioned my expertise,
I hope you can understand that a few pointed comments might come back in a
reply.

thanks,
Rob

---

From: Paul Ebersman <[email-masked]>
Date: Sat, 17 Aug 2019 14:55:16 -0600

jabley> These attacks use the DNS, but they are not attacking the DNS
jabley> protocol; they are attacking platforms that use the DNS.

sayrer> That sentence doesn't make sense to me. Isn't this precisely the
sayrer> kind of attack TLS and HTTPS mitigate? See RFC 1958, section 6:
sayrer> "Endpoints should not depend on the confidentiality or integrity
sayrer> of the carriers." 
sayrer> <[[https://tools.ietf.org/html/rfc1958#section-6]]>

No, the point is if the device OS doesn't protect the code the device
runs or allows configuration file changes, you can't secure the
device. That's what the article you referenced is highlighting.

No protocol can be secured or trusted if the underlying OS isn't
secure. Consumer CPEs are rife with default or backdoor admin passwords,
which makes them inherently insecure. Claiming that changing what
transport or DNS server you're using is pointless, since this can be
trivially changed by the "bad guys".

That security issue is addressed by having better CPE devices and there
are a number of efforts to help CPE vendors turn out better products.

sayrer> Yes, it seems like DNSSEC does provide integrity and
sayrer> authentication in some sense, but it's vulnerable to tampering
sayrer> on the wire (intentional or not).

How is DNSSEC vulnerable to tampering? It's vulnerable to denial of
service, because you can break validation and the end user/device
doesn't get an answer. That's not at all the same thing.

And how is the integrity "in some sense". I'd agree that DNSSEC doesn't
provide authentication but it does provide integrity.

jabley> If the applications involved in the phishing enabled by this
jabley> attack had been using DoH (doh working group) then the change of
jabley> DNS settings in the router would not have affected them.

sayrer> Agreed. The question is whether there's a way to enable
sayrer> automatically-negotiated "DNS filtering" while preventing that
sayrer> attack. I don't think there is.

That's non-sequitor. The ability to bypass the device OS DNS settings
has nothing to do with DNS filtering being negotiated.

sayrer> I think this is a cultural disconnect. In my part of the
sayrer> internet, long messages are usually viewed as disrespectful or
sayrer> at least presumptuous.

Or an attempt to address the range of statements and questions you pose.
I don't know what "part of the internet" you inhabit, but on IETF lists,
we try to achieve consensus by responding to what's written.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 17 Aug 2019 16:58:19 -0400

Sent from my iPhone

> On Aug 17, 2019, at 3:38 PM, Rob Sayre <[email-masked]> wrote:
> 

Okay, let’s.

The attack is attempted because pointing a DNS forwarder at a malicious DNS resolver is effective in spoofing web sites, if the client host or client app can be convinced that the web site is authentic. It succeeds only because browsers believe the attacker.

Consider how these attacks would be mitigated if the host performed DNSSEC validation and the domain was DNSSEC signed: the result of changing the DNS resolver would at worst result in denial of DNS resolution for the targeted sites. Use of TLSA records, if validated by the browser, would further protect against advanced attacks involving certificates issued by rogue CAs. 

In fact, browsers implementing DNS client functions would facilitate much of these improvements by bypassing limitations of the host OS resolver libraries. Browsers would be able to do TLSA queries directly, and bypass forwarders which fail to do DNSSEC validation.

Standardizing selection of resolver, transport protocol (DoH vs DoT), along with DNSSEC validation and DANE support would seem to be an enormous win/win.

It would not make the above attack impossible (it would still be possible to change the DNS server) but it would make it futile (forged results would be ignored) and discourage further attempts.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 14:07:04 -0700

> device. That's what the article you referenced is highlighting.

No, it's pointing out that the router may be compromised, and that the
endpoints shouldn't trust it.

> How is DNSSEC vulnerable to tampering?

"Most bizarrely perhaps, is that DNSSEC provides no end-to-end security.
Your browser or OS still communicates with your resolver using regular
queries, relying on a single unauthenticated bit to "request" validation.
It's as if LAN/wifi-level abuse wasn't a concern at all, or that public
resolvers (like OpenDNS and Google Public DNS) didn't exist."

<https://news.ycombinator.com/item?id=7450281>

> we try to achieve consensus by responding to what's written.

Sure. I think a close reading of the list will lead you to predict a result
that resembles this meeting: <https://youtu.be/7hclQbuCBws?t=3432>.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 14:18:04 -0700

On Sat, Aug 17, 2019 at 1:58 PM Brian Dickson <[email-masked]>
wrote:

>
> Consider how these attacks would be mitigated if the host performed DNSSEC
> validation and the domain was DNSSEC signed
>

DNSSEC adoption is directly correlated with use of Google's centralized DNS
service.

<https://blog.apnic.net/2019/03/14/the-state-of-dnssec-validation/>

thanks,
Rob

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 17 Aug 2019 23:33:39 +0200

Moin!

> endpoints shouldn't trust it.
Well the application could also be compromised. What are we doing then?
At one point in time everything can be compromised. That doesn’t mean
we should no longer use the technology in general. Otherwise we would
not use computers at all.

> <https://news.ycombinator.com/item?id=7450281>
You bring that at least the second time. And repeating doesn’t make it
true. DNSSEC when deployed with validation at the stub resolver can
detect tampering of the data either by the party I selected to talk
to or by something someone is trying to hand me. So it is end to end
secure from the moment someone entered the data into an authoritative
server up to me as a client or application.

As said before DNSSEC and DoH/DoT are complementary and solve different
problems.

So long
-Ralf
—--
Ralf Weber

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 14:36:21 -0700

On Sat, Aug 17, 2019 at 2:18 PM Rob Sayre <[email-masked]> wrote:

> On Sat, Aug 17, 2019 at 1:58 PM Brian Dickson <
>> Consider how these attacks would be mitigated if the host performed
>> DNSSEC validation and the domain was DNSSEC signed
>>
>
> DNSSEC adoption is directly correlated with use of Google's centralized
> DNS service.
>

I was brought to my attention that these estimates may be a bit on the
optimistic side.

"...maybe 20% of recursives may have 'adopted' validation. Sadly, only
about 1% of zones have really adopted and signed."

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 14:39:00 -0700

> As said before DNSSEC and DoH/DoT are complementary and solve different

Agreed. But I think people are looking for a way to break DoH/DoT, in a
well-meaning way. So, bringing up DNSSEC is actually kind of a distraction.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Aug 2019 22:42:14 +0100

Hiya,

> about 1% of zones have really adopted and signed."

That was a quote from me. (Which is just fine, I was trying
not to add to the list traffic so much;-)

Anyway, I think the above numbers may be close enough to
correct. But the reason for this mail is just to say that
I fully agree with those who say that DNSSEC is complementary
to DoH or DoT.

They just provide different services.

DNSSEC can provide origin authentication for DNS answers.

DoH/DoT can provide confidentiality between stub and
recursive and authentication of a recursive.

Claims that there's a conflict there or that one is better
or worse than the other make no sense.

Cheers,
S.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 18 Aug 2019 07:45:58 +1000

> On 18 Aug 2019, at 7:07 am, Rob Sayre <[email-masked]> wrote:
> 
> 
> 
> No, it's pointing out that the router may be compromised, and that the endpoints shouldn't trust it.
> 
> 
> "Most bizarrely perhaps, is that DNSSEC provides no end-to-end security. Your browser or OS still communicates with your resolver using regular queries, relying on a single unauthenticated bit to "request" validation. It's as if LAN/wifi-level abuse wasn't a concern at all, or that public resolvers (like OpenDNS and Google Public DNS) didn't exist.”

> <https://news.ycombinator.com/item?id=7450281>

DNSSEC was *designed* to be validated on the end device.  It really isn’t hard to do.  Its achievable using the stub resolver shipped in BSD 4.2.  Thats a 30 year old stub resolver.  It does require the recursive resolver to *also* support DNSSEC and will MOSTLY work when that recursive server is NOT validating.  The corner cases require that
the recursive server also validates.

You can quote DISINFORMATION all you like.  It doesn’t make it correct.

> Sure. I think a close reading of the list will lead you to predict a result that resembles this meeting: <https://youtu.be/7hclQbuCBws?t=3432>.
> 
> thanks,
> Rob 
> -- 
> Add mailing list
> [email-masked]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 17 Aug 2019 23:48:24 +0200

Moin!

On 17 Aug 2019, at 23:39, Rob Sayre wrote:

> well-meaning way.
Can’t speak for people, but I’m looking for a way to deploy DoH (DoT never
was a problem) so that we get the benefits of our current distributed
architecture plus the benefits of encryption.

> So, bringing up DNSSEC is actually kind of a distraction.
Sigh. There have been, and there are still are people working on DNSSEC
deployment. IMHO it something we have to do and not a distraction.

So long
-Ralf
—--
Ralf Weber

---

From: Brian Dickson <[email-masked]>
Date: Sat, 17 Aug 2019 18:22:03 -0400

On Aug 17, 2019, at 5:07 PM, Rob Sayre <[email-masked]> wrote:

(I’m not sure if you read any of the comments on that article. They provide
some clues regarding client validation. Still, it seems you may need a bit
more clarity on client validation, which I’m happy to provide below.)

DNS resolvers which are DNSSEC aware are able to perform validation, and
signal successful validation with the AD bit. However, clients do NOT need
to depend on this, and in fact DNSSEC was designed so that resolver
validation is technically optional.

DNS clients can signal their awareness of DNSSEC with EDNS and having the
DO bit set. When this is done, extra DNSSEC responses are returned
alongside the regular DNS responses. This means a DNSSEC-aware client has
everything it needs to independently validate the answer, as long as it
already has the DNSSEC delegation information already. The client can
obtain the delegation chain of DNSSEC data from its resolver if it doesn't
already have it.

Long answer short: DNSSEC does not rely on unsigned DNS responses over
unprotected communication on the last mile, and is in fact designed from
the ground up to support client validation, which does not require
protection of the last mile itself. DNSSEC protects the DNS data over the
last mile from being tampered with, or more precisely, allows the client to
detect any tampering. The only reasons I can see for not validating are
blockers on the OS API for DNS, and/or implementers of clients that don't
have enough cycles or have not prioritized doing so.

There are several open source resolver implementations of validation, whose
code potentially could be integrated depending on licensing limitations.
Similarly it is quite feasible to deploy forwarding-only validating
resolvers on hosts to protect the last mile while benefiting from the use
of the shared upstream resolver’s cache. Closer integration to the app
makes more sense in the long term.

All of the important details are in RFC 4035, in section 4.9:
https://tools.ietf.org/html/rfc4035#section-4.9

I recommend you read that section at a minimum. It is the "lingua franca"
for talking about DNSSEC, particularly for stub (client) context.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sat, 17 Aug 2019 18:27:05 -0400

> about 1% of zones have really adopted and signed."
I don't want to over-commit in this regard, but that 1% value may be
changing substantially in the relatively near future.
(Substantial would be on the order of increasing that from 1% to on the
order of 40%, and relatively near is likely measured months.)

Hopefully this will provide motivation for anyone considering their own
participation in the DNSSEC ecosystem, either as a resolver operator, zone
owner, zone operator, or client developer.
(Browser participants, I am hoping you take note.)

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Aug 2019 23:29:47 +0100

Hiya,

> order of 40%, and relatively near is likely measured months.)

That'd be great. I'd be v. interested in details as and
when possible, on or offlist.

S.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 17 Aug 2019 18:50:32 -0400

On Sat, Aug 17, 2019 at 5:39 PM Rob Sayre <[email-masked]> wrote:

> [...]

But I think people are looking for a way to break DoH/DoT, in a
> well-meaning way.

I'm not sure if you are counting me in the population of "people", but if
so, you are WAY wrong, or at least mistaken on intent.

I'm looking for ways of breaking involuntary change of DNS resolver choice.
This applies to both managed and unmanaged devices, hosts, virtual hosts,
infrastructure, and those of any partner companies, sister companies,
subsidiaries, outsource companies, or customers.

That the target (ie new choice of) DNS resolver might happen to be doing
DoH is completely irrelevant. What matters is that the resolver is changed,
not the protocol being used.

Incidentally, I am strongly in favor of upgrading all DNS client
connections-to-resolvers in our larger ecosystem, to be DoT.

If it is not possible to convince browsers to do DoT, the alternative may
be in-host proxy services that do DoH to DoT conversion. Those are nearly
trivial to implement.

Mostly choosing DoT over DoH is about not adding any HTTP junk to DNS
resolution on the server side. Our DNS servers do not do HTTP anything. We
want the greatest amount of flexibility in choice of servers, and the
smallest available attack surface.

Adding TLS to a regular DNS server (which is what DoT amounts to) is the
simplest option.

This is the exact opposite of wanting to break DoH/DoT.

Wanting to continue to operate infrastructure for DNS resolution, and
maintain (or add) existing DNS-based toolsets, is a significant driver in
this philosophy.

When you operate DNS infrastructure at scale, and offer DNS services at
scale as well, any attempt by any software vendor to interfere with that,
regardless of motivation or intention, is going to provoke a strong
negative response, and justifiably so.

So, in short, please stop what folks like I am doing, as being
anti-encryption or anti-DoH/DoT, because it isn't.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 16:12:55 -0700

> You can quote DISINFORMATION all you like.  It doesn’t make it correct.

After 14 years or so, I think DNSSEC adoption rates speak for themselves.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Sat, 17 Aug 2019 16:18:51 -0700

> I'm looking for ways of breaking involuntary change of DNS resolver

Hmm. I'm not sure this rhetoric is particularly convincing, but I'll think
more about it.

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 18 Aug 2019 08:41:52 +0200

On 17 Aug 2019, at 23:39, Rob Sayre wrote:

> Agreed. But I think people are looking for a way to break DoH/DoT, in a well-meaning way. So, bringing up DNSSEC is actually kind of a distraction.

No, because only by validating the DNSSEC signed response in the client you can detect whether the resolver has modified the result. Regardless of how the DNS response reach the client.

As Ralf wrote, the question of transport for DNS packets and DNSSEC are _complementary_.

You still need DNSSEC validation in the client, regardless of what transport protocol is in use.

   Patrik

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 19 Aug 2019 08:19:58 +0200 (CEST)

> <https://blog.apnic.net/2019/03/14/the-state-of-dnssec-validation/>

Sometimes, sometimes not.

https://stats.labs.apnic.net/dnssec/SE

Sweden has had robust DNSSEC validation amongst ISPs for over 10 years 
now.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Mon, 19 Aug 2019 09:37:14 +0100

> Just a reminder: DoH resolvers can (and do) do DNS filtering.

Ones that conform to Mozilla's TRR policy can't do it in a way that's 
completely consistent with the legal requirements for blocking.

Specifically, their policy requires that the TRR operator publish the 
list of any domains that are blocked.   For some types of block (e.g. 
domains with child abuse imagery) publishing such a list is very 
problematic.

The policy as currently written also doesn't appear to be compatible 
with the feature of RPZ whereby the individual domains blocked can 
change dynamically based on the target name or IP address of the 
domain's NS records.  This is essential for blocking DGA style botnets, 
where often the C&C hosts have been identified but the specific domains 
are not known apriori.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Aug 2019 08:19:56 -0700

On Aug 19, 2019, at 1:37 AM, Ray Bellis <[email-masked]> wrote:
> Specifically, their policy requires that the TRR operator publish the list of any domains that are blocked.   For some types of block (e.g. domains with child abuse imagery) publishing such a list is very problematic.

Is this an issue that the authors of the policy are aware of?   Is this intentional?

FWIW, while I understand the desire for transparency, I tend to agree that this is untenable.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 19 Aug 2019 16:31:32 +0100

On 19/08/2019 16:19, Ted Lemon wrote:

> Is this an issue that the authors of the policy are aware of?

I've no idea.   Hopefully they're aware now.

> Is this intentional?

Is what intentional?

> FWIW, while I understand the desire for transparency, I tend to agree

The IWF (who provide the list) have very strict rules about how the list 
is managed and distributed, that extend right down to controls over 
which staff within those ISPs that use the blocklist have visibility of it.

Even for lesser blocking reasons (e.g. malware protection, etc) the 
requirement to publish a list is IMHO unreasonable.

Ray

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Aug 2019 09:55:34 -0700

On Mon, Aug 19, 2019 at 8:20 AM Ted Lemon <[email-masked]> wrote:

> Specifically, their policy requires that the TRR operator publish the list
> of any domains that are blocked.   For some types of block (e.g. domains
> with child abuse imagery) publishing such a list is very problematic.
>
>

Unfortunately, there is a fairly long history of over-blocking, including
in the UK. See, for instance:
https://en.wikipedia.org/wiki/Internet_censorship_in_the_United_Kingdom#Overblocking,
so some form of transparency is required here.

I don't know enough about the child abuse imagery case to know whether
keeping the list secret actually significantly decreases availability of
such content, however to take the simpler case of malware protection, it's
not clear to me why it needs to be secret. Can you explain why that is
necessary?

-Ekr

---

From: Ray Bellis <[email-masked]>
Date: Mon, 19 Aug 2019 18:13:43 +0100

On 19/08/2019 17:55, Eric Rescorla wrote:

> Unfortunately, there is a fairly long history of over-blocking, 
> including in the UK.

There's been only a very small handful of reported overblocking cases 
with that particular list.

The most widely reported one was many years ago (2008) when the whole of 
Wikipedia got blocked because a specific album cover that they were 
hosting a picture of was deemed unacceptable.

(Interesting legal commentary at
<https://www.pinsentmasons.com/out-law/news/why-the-iwf-was-wrong-to-lift-its-ban-on-a-wikipedia-page>)

> I don't know enough about the child abuse imagery case to know 
> whether keeping the list secret actually significantly decreases 
> availability of such content

AIUI, the intent of keeping the list secret is not to decrease 
availability, but to prevent it falling into the hands of those actively 
seeking that material.

> however to take the simpler case of malware protection, it's not 
> clear to me why it needs to be secret. Can you explain why that is 
> necessary?

I wouldn't say "necessary" but I do think that any intelligence that a 
malware operator can glean about which of its domains are blocked would 
be of use to them.

Ray

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Aug 2019 12:53:20 -0500

> with that particular list.

Is this true? The Open Rights Group reports that the default blocking 
settings for the UK prevent access to almost 10% of the top 100,000 
Alexa-ranked sites today [1]. While this is a vast improvement from the 
20% from five years ago [2], it still seems unacceptably high -- 
especially when considering the nature of the sites that get blocked [3].

> availability, but to prevent it falling into the hands of those 
> actively seeking that material.

I might be alone, but I can't figure out the distinction you're trying 
to make.

> malware operator can glean about which of its domains are blocked 
> would be of use to them. 

For an actor like a malware operator, there will be a very small number 
of already-known domains of interest, and determining whether they are 
blocked is trivial: they can try to resolve said domains and see whether 
they get the expected result.

/a

____
[1] https://www.blocked.org.uk/
[2] 
https://www.independent.co.uk/life-style/gadgets-and-tech/one-in-five-sites-blocked-by-the-uks-over-zealous-pornography-filters-9579838.html
[3] 
https://www.independent.co.uk/life-style/gadgets-and-tech/news/o2-changes-porn-filter-after-charity-sites-blocked-9023209.html

---

From: Ray Bellis <[email-masked]>
Date: Mon, 19 Aug 2019 19:39:15 +0100

> especially when considering the nature of the sites that get blocked [3].

I was talking specifically about the IWF CAI list, not the wider "adult 
content" type filters.

> I might be alone, but I can't figure out the distinction you're trying 

I can't answer for IWF.   Someone should ask them.   The Pincent Masons 
article I linked to earler asserts "The blacklist is kept secret for 
obvious reasons".

> they get the expected result.

Some malware gets through many 10s of thousands of domain names per day. 
  I wouldn't call that a "very small number".

My personal view is that if the blocks are there because:

1.  the relevant legal authorities mandated it, and/or
2.  the end user opted into it (as permitted by TRR policy)

then it's none of Mozilla's business to require that the content of the 
blocks be published.  In both cases, the block is "legal" so what's to 
be gained by requiring publication of the list?

Ray

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Aug 2019 13:51:16 -0500

On 8/19/19 1:39 PM, Ray Bellis wrote:
> In both cases, the block is "legal" so what's to be gained by 
> requiring publication of the list?

Transparency. A free society shouldn't have to rely on cobbled-together 
ad-hoc approaches like https://www.blocked.org.uk/ to find out what is 
being censored by a government, especially when over-blocking is 
manifestly a problem.

I mean, blocking services without public visibility and accountability 
can certainly continue to operate, but I don't see why any specific 
organization should be compelled to endorse them.

/a

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Aug 2019 16:39:53 -0400

> 1.  the relevant legal authorities mandated it, and/or 2.  the end user
    > opted into it (as permitted by TRR policy)

    > be gained by requiring publication of the list?

When a query is blocked, and one believes it was blocked
inappropriately, knowing why it was blocked would tell you what your avenues
for recourse are.

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

---

From: Andrew Campling <[email-masked]>
Date: Tue, 20 Aug 2019 16:12:17 +0000

> Transparency. A free society shouldn't have to rely on cobbled-together ad-hoc approaches 
> like https://www.blocked.org.uk/ to find out what is being censored by a government, especially 
> when over-blocking is manifestly a problem.

> I mean, blocking services without public visibility and accountability can certainly continue to 
> operate, but I don't see why any specific organization should be compelled to endorse them.

It's worth bearing in mind that blocking in the UK / Europe can arise because of legal requirements such as to bar access to child abuse material, other illegal content such as terrorism-related material (which would require a court order, regulatory instruction or similar), and to bar access to copyright-infringing content.  The latter would be driven by a court order from the rights holder rather than government.  In all three cases, legislation and/or court orders underpin the blocks so there is a process to go through - ISPs cannot elect to block access under their own volition otherwise they would themselves be open to challenge in the courts.  If non-ISP resolvers become more prevalent then I suspect they would also be covered by the scope of court orders blocking access to specified content.  

As to whether any specific organisation should be compelled to endorse such an approach, it's the cost of doing business in particular markets, is no different to having to comply to GDPR and ePrivacy if operating in Europe.  

Andrew

---

From: Ray Bellis <[email-masked]>
Date: Tue, 20 Aug 2019 17:21:54 +0100

On 19/08/2019 21:39, Michael Richardson wrote:

> inappropriately, knowing why it was blocked would tell you what your
> avenues for recourse are.

The content was either blocked because the authorities mandated it, or
because you opted-in to filtering.

In the former case you have no recourse.   In the latter case, you can
opt-out again, eliminating the second possibility.

What I didn't see yet is any discussion as to how an individual DoH user 
can actually opt-in.

Ray

---

From: Erik Kline <[email-masked]>
Date: Tue, 20 Aug 2019 10:22:37 -0700

> What I didn't see yet is any discussion as to how an individual DoH user

And maybe that's one short doc that should get written (maybe it's already
written somewhere?):

   A statement that applications and operating systems should generally
      [1] follow the express configuration intent of device owners/users,
and
      [2] if not available, use the network-provisioned service(s).

Applications choosing to do their own nameservice resolution to a service
other than those above (with exceptions for things like diagnostic and
measurement purposes) risk having an IETF kilo-thread devoted to berating
them (and maybe a few other consequences too ;-).

---

From: Eric Orth <[email-masked]>
Date: Tue, 20 Aug 2019 15:50:50 -0400

>       [2] if not available, use the network-provisioned service(s).

[1] is probably so non-controversial to not require publishing a
statement.  If you have explicit user settings but ignore them, you just
have a bad application, and IETF is not going to be able to fix it.  The
only reason we're having these discussions is because device owners/users
usually do not provide an express configuration intent or it's not clear to
all applications involved whether or not a configuration comes from such a
source with the full options available the application wants to provide.

[2] I don't think you're going to get reasonable consensus on as there are
lots of obscure cornercases (you recognize diagnostic and measurement)
where not doing so starts seeming reasonable to more people (but admittedly
not everyone), and there are major relevant stakeholders that clearly
disagree with it in the general case.  Short of some super new
insightful perspective, rather than just rehashing disagreement, I don't
think any of these kilo-threads are going to change opinions on the proper
default.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 20 Aug 2019 15:55:14 -0400

Sent from my iPhone

> On Aug 19, 2019, at 2:39 PM, Ray Bellis <[email-masked]> wrote:
> 
> 
> 
>> Is this true? The Open Rights Group reports that the default blocking settings for the UK prevent access to almost 10% of the top 100,000 Alexa-ranked sites today [1]. While this is a vast improvement from the 20% from five years ago [2], it still seems unacceptably high -- especially when considering the nature of the sites that get blocked [3].
> 
> I was talking specifically about the IWF CAI list, not the wider "adult content" type filters.

From reading the Wikipedia page on IWF and IFW’s own page, here is what appears to be the real issue:
The actual list is mostly limited to URLs only. Domains are only listed if they are exclusively used for hosting the relevant material.
ISPs implement blocking using the URL list however they want, but typically the only available mechanism is to MitM domains hosting the relevant URLs, in order to replace blocked URLs with a placeholder of some kind such as an explanation on why the image was blocked (or a generic 404).

The problem arises in how they become a MitM selectively (only for domains with such URLs): they redirect traffic to a proxy via DNS.

The impacted domains aren’t blocked, only the specific URLs.

Unfortunately, the MitM requires SNAT (source NAT) so the end to end connection works correctly, which leads to problems generally shared by NATs.

IMHO the Open Rights Group is conflating the underlying NAT problem with actual DNS-based blocking of entire domains.

I’m not sure whether it would be feasible for browsers to cooperate with ISPs and the IWF to improve the URL blocking. If it were possible (in a way that the ISPs could trust and verify, for example) it might not be necessary to use the MitM method and consequently not require the DNS redirection.

That would mostly make the UK case moot, since there would no longer be a resolver dependency.

(I believe there are still some entire domains in the list. It isn’t clear whether those would require DNS-level blocking.)

That is a lot of “if’s”, though.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 20 Aug 2019 15:59:12 -0400

Sent from my iPhone

> On Aug 19, 2019, at 4:39 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

I believe how the blocking is done and what message is provided is handled by each ISP independently. I’m not sure whether there is a single “right” solution that UK ISPs could agree on, but I’m sure it is for them (or the regulators) to decide.

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Aug 2019 22:21:20 +0100

On 20/08/2019 20:55, Brian Dickson wrote:
> The problem arises in how they become a MitM selectively (only for
> domains with such URLs): they redirect traffic to a proxy via DNS.
Huh? Where's that described? I've not heard/seen that UK ISPs are
MitMing any HTTP/TLS and would be quite surprised were that the case.

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 16:25:50 -0500

> MitMing any HTTP/TLS and would be quite surprised were that the case.

I'm perplexed, too. Given that nearly 80% of worldwide HTTP traffic is 
encrypted, and that an attempt to MITM such encrypted traffic would 
simply result in the page not being loaded due to a certificate error, 
this seems like it's not even remotely a feasible approach. Or, 
minimally, it would be indistinguishable from a block on the entire 
domain, as the end result would be identical.

/a

---

From: Brian Dickson <[email-masked]>
Date: Tue, 20 Aug 2019 18:54:12 -0400

On Tue, Aug 20, 2019 at 5:21 PM Stephen Farrell <[email-masked]>
wrote:

> Huh? Where's that described?

https://en.wikipedia.org/wiki/Internet_Watch_Foundation#Of_proxy_server_used_by_ISPs

I have no direct knowledge, I'm going off of the wikipedia page.
(In particular, I haven't looked into the HTTP vs HTTPS issue at all, just
summarizing what I read above.)

Brian

> I've not heard/seen that UK ISPs are

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Aug 2019 16:23:21 -0700

> domain, as the end result would be identical.

They have users install trusted root certs.

I think a few UK ISPs have started really locking down their routers (can't
change DNS settings, etc), and I think a few products from a few of those
ISPs come with installers (particularly for Windows), that install root
certs, while others just direct users to install the cert using the OS
control panels. It's not that common, yet, though.

Here's an example of Vodafone MITMing imgur.com: <
https://forums.thinkbroadband.com/vodafone/4549610-vodafone-blocks-sites-with-user-submitted-content.html#Post4610585

thanks,
Rob

---

From: George Michaelson <[email-masked]>
Date: Wed, 21 Aug 2019 07:30:07 +0800

I've always held the current model of a TA bundle inherent in the
browser and embedded systems is probably a bad thing (tm) and we'd to
better to have code signing TA, but as few general purpose TA's as
possible pre-installed and have actually required people to THINK
about this, and install the TA set they wanted.

I know, I know, this is inherently complex, and probably has dangers
too. But, the current model of TA distribution is a giant shell game
of misplaced trust.

-George

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 18:30:47 -0500

On 8/20/19 5:54 PM, Brian Dickson wrote:
>
>
> On Tue, Aug 20, 2019 at 5:21 PM Stephen Farrell 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
> (In particular, I haven't looked into the HTTP vs HTTPS issue at all, 
> just summarizing what I read above.)

Given the shift in cleartext traffic versus encrypted traffic in the 
past few years, I suspect that specific part of the Wikipedia article is 
no longer accurate. As I mention in my other note, 80% of web traffic is 
encrypted today, up from 30% five years ago. The described technique was 
questionable at 30%, and is basically completely broken at 80%.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 18:37:12 -0500

On 8/20/19 6:23 PM, Rob Sayre wrote:
> think a few products from a few of those ISPs come with installers 
> (particularly for Windows), that install root certs, while others just 
> direct users to install the cert using the OS control panels.

While I can't disprove this, I find it wildly implausible, given the 
loud and repeated outcry by various civil society groups whenever 
Kazakhstan attempts something similar. I believe any such move by the UK 
or any of its major ISPs would have been more widely publicized than a 
user-submitted comment on forums.thinkbroadband.com.

/a

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Aug 2019 16:45:42 -0700

> user-submitted comment on forums.thinkbroadband.com.

I only used that because I found the report very clear. Here are some other
data points:

<https://www.google.com/search?q="contentcontrol.vodafone.co.uk
"+certificate>

And here's a report on what mind be found in Android root stores:

<https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/tangled-mass.pdf>

I also found that BT Smart Hub / Home Hub routers require installation of
root certs, but I think it may only be for communicating with the router
and one BT web page, at the moment.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 00:48:46 +0100

Hiya,

> https://forums.thinkbroadband.com/vodafone/4549610-vodafone-blocks-sites-with-user-submitted-content.html#Post4610585

I'm with Adam on this one. Reading at the URL above it appears
like a not that clever attempt to get https from a browser within
the home network to the home router, and not as an attempt to
MitM the web.

I guess it's possible the same private key is used in many home
networks (which'd be crap but has happened numerous times) but
there's no evidence of that at the URL above.

And really - if Vodafone were crazy enough to try that for the
web (and I do not think for a second they are), it'd have been
spotted and front-page news within a day never mind 6 months.

I do wish we could all base our arguments on more thoroughly
validated information. There's enough complexity and controversy
involved in these debates that having to deal with erroneous
information could well be enough to make what's already hard
impossible. "Luckily," in this case, both you and Brian appear
to be making the same improbable claim, so it kinda balances
out:-)

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Aug 2019 16:54:54 -0700

> the home network to the home router, and not as an attempt to

https://www.reddit.com/r/unitedkingdom/comments/c73b0z/new_vodaphone_router_stealth_blocking_vpn_sites/

" It even breaks Imgur’s SSL by default, and they suggested to install and
trust their ssl certificate as a fix.. crazy"

"Imgur pretty much failed to work and support felt you needed their root CA
in order to simply browse."

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2019 01:05:40 +0100

Hiya,

> in order to simply browse."

Actually, apologies to both you and Brian - following a few
of those links it sure does look like people are saying
Vodafone may have been or are MitMing some HTTP/TLS
connections to imgur for some reason that's speculated to
be connected to IWF.

Can anyone verify that and send traces?

If so, bugger me but that's mad and, I would hope, an
absolute magnet for a fine from ICO. I'd not be that
surprised if there's a GDPR exemption somewhere there,
but I fail to see why should an ISP get to look at
loads of users' images just for that reason?

Ta,
S.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Aug 2019 17:10:26 -0700

> connections to imgur for some reason that's speculated to

I actually found a reply from a Vodafone community manager.

https://www.reddit.com/r/AskNetsec/comments/5v158o/trying_to_find_out_if_vodafone_broadband_uk/diuhx7l/

"Our current content controls means that HTTPS traffic to this website will
appear to be insecure"

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Aug 2019 17:26:34 -0700

On Tue, Aug 20, 2019 at 5:10 PM Rob Sayre <[email-masked]> wrote:

> "Our current content controls means that HTTPS traffic to this website
> will appear to be insecure"
>

I found this too: <
https://wiki.openrightsgroup.org/wiki/Vodafone_Content_Control>. I guess
they're running Blue Coat on the whole ISP.

I wonder if this shows up as Blue Coat interception on <
https://malcolm.cloudflare.com>.

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Tue, 20 Aug 2019 20:31:25 -0400

Given some of the recent information we have collectively uncovered, I suggest more research may be worth doing.

The things I think are worth getting to the bottom of are:
Methods used by UK ISPs
Listings (UK vs non-UK, as IWF’s page seems to suggest different practices for those)
Durations of listings and number of concurrent listings 
False positives reported, confirmed

Given the consequences and implications, I would encourage some kind of official outreach from Mozilla and Google (browser department), to engage with IWF. Some independent verification of the nature and severity of the images, on a sampled basis, may allow a better comprehension of the legitimacy of the CAI URL list.

Whether and how either browser might decide to endorse their URL list, including whether that should be UK only or perhaps wider in scope, is something best handled by those with responsibility and accountability.

Third and fourth hand, and anecdotal reports are probably not suitable for important issues such as child abuse images .

Brian

> On Aug 20, 2019, at 7:30 PM, Adam Roach <[email-masked]> wrote:
> 
>>> On Tue, Aug 20, 2019 at 5:21 PM Stephen Farrell <[email-masked]> wrote:
>>> 
>>> 
>> (In particular, I haven't looked into the HTTP vs HTTPS issue at all, just summarizing what I read above.)
> 
> Given the shift in cleartext traffic versus encrypted traffic in the past few years, I suspect that specific part of the Wikipedia article is no longer accurate. As I mention in my other note, 80% of web traffic is encrypted today, up from 30% five years ago. The described technique was questionable at 30%, and is basically completely broken at 80%.
> 
> /a

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 19:34:27 -0500

> loads of users' images just for that reason?

Wow. I'm going to have to walk back my comments as well, and extend a 
similar apology. This is utter madness.

I'll note that the comments on the cited reddit discussion quickly get 
into the finer points of using 1.1.1.1 versus 8.8.8.8. That isn't 
applications doing DNS, although it touches on the centralization issue 
that is frequently conflated with it.

/a

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Aug 2019 18:15:18 -0700

> similar apology. This is utter madness.

I agree it seems strange, even if well-meaning. To recap, we have
well-documented examples of:

ISPs using Classic DNS to fuel ad networks (they could still do this if
they provided DoT/DoH)
ISPs MITMing TLS connections in an effort to provide content filtering
Entertainment devices hard-coding DNS services, ignoring the OS and network
administrator
Routers that use centralized DNS services without user
interaction, ignoring the OS and network administrator
Android handsets that enable a VPN on certain networks by default, and all
networks with user interaction, bypassing local DNS
Home routers being exploited to hijack Classic DNS

It just doesn't seem like consensus is likely in this landscape.

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 21 Aug 2019 07:11:02 +0200

On 21 Aug 2019, at 1:48, Stephen Farrell wrote:

> And really - if Vodafone were crazy enough to try that for the web (and I do not think for a second they are), it'd have been spotted and front-page news within a day never mind 6 months.

Agree, and those issues can only be resolved by really doing an outcry and choosing a different access provider. That customers use their feet.

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Tue, 20 Aug 2019 23:11:47 -0700

On Tue, Aug 20, 2019 at 10:11 PM Patrik Fältström <[email-masked]> wrote:

>
> Agree, and those issues can only be resolved by really doing an outcry and
> choosing a different access provider. That customers use their feet.
>

I think reasonable people can disagree on this kind of issue. Do you work
for a big company or a government or something? I don't, but I feel like
it's a fair question.

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 21 Aug 2019 08:58:45 +0200

On 21 Aug 2019, at 8:11, Rob Sayre wrote:

> I think reasonable people can disagree on this kind of issue. Do you work for a big company or a government or something? I don't, but I feel like it's a fair question.

Let me expand on this a bit.

As myself and others have said many times on this list, court orders have ordered access providers in many legislations to block access to certain "things". Some of these court orders are sealed, and of course people are trying to get their hands on the orders, validate whether they are correct and what not.

With "things" I have seen everything from IP addresses via domain names to URLs.

I have not seen any explicit statements in the court orders I have seen how this is to be implemented, so the implementation is up to the access provider. There might very well exist such details, and I am happy to see what they contain.

We all know that such court orders might be viewed differently if they are coming from a difficult democracy than when they come from for example courts in Sweden where the courts are (as the president of the USA seems to not understand) completely independent from the political system. But the fact is that the court orders are there.

We all seems to agree that ultimately we want the end user to a. discover that something fishy is going on and b. be able to control the situation.

Now, this is something that is not going to go away, and the fact that the access provider is responsible for the blocking of access will probably not go away either. MAYBE if centralized recursive resolvers are growing in use (DoH or DoT or Do53 does not matter) there might be interest in courts to have those be changing the responses just like they attack registries and registrars. But I have not seen that (yet). Maybe it is happening in the jurisdictions where The Big Players are located, I do not know.

What I am because of this talking about is whether the access provider (that is the target of the court order) is doing "the right thing", and let me be clear, I do not think forcing me as an end user to trust the CA that the access provider forces on me is the right way of moving forward. I know that some enterprises do this, and I have reluctantly viewed this as acceptable. Better than the eTLS solution discussed in ETSI. I am very very nervous over what is going on in GSMA.

And I am disappointed in IETF not looking more carefully at this situation and including it as a scenario IETF should look into.

This is the basis for my view that:

- We should add privacy as much as we can do DNS queries, and this includes query minimization and DoT *in*the*client*, not accept any queries with RD flag go out from the client
- We should do DNSSEC validation *in*the*client* so that the client notices when some modification is happening
- If the RD flag must be set on a query, or if validation can not be done, we MUST use the extended status flags in the DNS query so that the TRUSTED resolver can signal back really what has happened
- On top of that, we must allow the access provider to separate the DNS traffic from other HTTPS traffic <--- This is something I missed pushing when the DoH spec did flow through the IETF, I was sleeping at the wheel...but that said, I do not mind having DoH specified so that we do get interoperability, I just do not think it is appropriate to use it at large scale for the reasons above

Ok, when then to do in difficult democracies? Am I not with these "rules" help the regimes there, the regimes we (including myself) is doing bad things?

Yes I am doing that, but I also want anyone "to do the right thing" while the end user should detect when bad things happen. When the access provider is NOT "doing the right thing".

At that point in time, the end user probably want to run TOR, VPN, tunnel IP packets over DNS or whatever else. I.e. the issues there are not solved by running DoH.

Then we have another shade of gray, and that include the access providers in democracies and States which are ok. The ones that do support an open Internet and UK is definitely up there.

UK is one of the few members of SG20 in ITU that for example do fight in favor actively for an open Internet, and not that "IoT" (whatever that is) should be something special.

We can not compare UK with other States.

We just can not!

So in the UK, the access providers, like Vodaphone, must be helped by the IETF on technical measures on how they deal with court orders. Together with us helping Vodaphone explain to the courts what words should be in the orders "to make sense".

And to conclude, if the access providers in such good States like UK is still not follow our recommendations, THEN we should vote with our feet, use the tools we have in the market economy and go somewhere else.

Some people might not agree with me, but this is my view.

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Aug 2019 00:15:13 -0700

I think Patrik's message does a great job of representing a certain
worldview.

While I might disagree with that view, I must also admit that it exists.

thanks,
Rob

On Tue, Aug 20, 2019 at 11:58 PM Patrik Fältström <[email-masked]> wrote:

> > I think reasonable people can disagree on this kind of issue. Do you
> work for a big company or a government or something? I don't, but I feel
> like it's a fair question.
>
> As myself and others have said many times on this list, court orders have
> ordered access providers in many legislations to block access to certain
> "things". Some of these court orders are sealed, and of course people are
> trying to get their hands on the orders, validate whether they are correct
> and what not.
>
> I have not seen any explicit statements in the court orders I have seen
> how this is to be implemented, so the implementation is up to the access
> provider. There might very well exist such details, and I am happy to see
> what they contain.
>
> We all know that such court orders might be viewed differently if they are
> coming from a difficult democracy than when they come from for example
> courts in Sweden where the courts are (as the president of the USA seems to
> not understand) completely independent from the political system. But the
> fact is that the court orders are there.
>
> We all seems to agree that ultimately we want the end user to a. discover
> that something fishy is going on and b. be able to control the situation.
>
> Now, this is something that is not going to go away, and the fact that the
> access provider is responsible for the blocking of access will probably not
> go away either. MAYBE if centralized recursive resolvers are growing in use
> (DoH or DoT or Do53 does not matter) there might be interest in courts to
> have those be changing the responses just like they attack registries and
> registrars. But I have not seen that (yet). Maybe it is happening in the
> jurisdictions where The Big Players are located, I do not know.
>
> What I am because of this talking about is whether the access provider
> (that is the target of the court order) is doing "the right thing", and let
> me be clear, I do not think forcing me as an end user to trust the CA that
> the access provider forces on me is the right way of moving forward. I know
> that some enterprises do this, and I have reluctantly viewed this as
> acceptable. Better than the eTLS solution discussed in ETSI. I am very very
> nervous over what is going on in GSMA.
>
> And I am disappointed in IETF not looking more carefully at this situation
> and including it as a scenario IETF should look into.
>
> - We should add privacy as much as we can do DNS queries, and this
> includes query minimization and DoT *in*the*client*, not accept any queries
> with RD flag go out from the client
> - We should do DNSSEC validation *in*the*client* so that the client
> notices when some modification is happening
> - If the RD flag must be set on a query, or if validation can not be done,
> we MUST use the extended status flags in the DNS query so that the TRUSTED
> resolver can signal back really what has happened
> - On top of that, we must allow the access provider to separate the DNS
> traffic from other HTTPS traffic <--- This is something I missed pushing
> when the DoH spec did flow through the IETF, I was sleeping at the
> wheel...but that said, I do not mind having DoH specified so that we do get
> interoperability, I just do not think it is appropriate to use it at large
> scale for the reasons above
>
> Ok, when then to do in difficult democracies? Am I not with these "rules"
> help the regimes there, the regimes we (including myself) is doing bad
> things?
>
> Yes I am doing that, but I also want anyone "to do the right thing" while
> the end user should detect when bad things happen. When the access provider
> is NOT "doing the right thing".
>
> At that point in time, the end user probably want to run TOR, VPN, tunnel
> IP packets over DNS or whatever else. I.e. the issues there are not solved
> by running DoH.
>
> Then we have another shade of gray, and that include the access providers
> in democracies and States which are ok. The ones that do support an open
> Internet and UK is definitely up there.
>
> UK is one of the few members of SG20 in ITU that for example do fight in
> favor actively for an open Internet, and not that "IoT" (whatever that is)
> should be something special.
>
> So in the UK, the access providers, like Vodaphone, must be helped by the
> IETF on technical measures on how they deal with court orders. Together
> with us helping Vodaphone explain to the courts what words should be in the
> orders "to make sense".
>
> And to conclude, if the access providers in such good States like UK is
> still not follow our recommendations, THEN we should vote with our feet,
> use the tools we have in the market economy and go somewhere else.
>

---

From: [email-masked]
Date: Wed, 21 Aug 2019 20:24:57 +0200 (CEST)

> I have not seen any explicit statements in the court orders I have seen how this is to be implemented, so the implementation is up to the access provider. There might very well exist such details,…

There have been several verdicts in the Oslo District Court ordering
Norwegian ISPs to prevent access to certain domains - and to implement
this explicitly using DNS blocking.

One such verdict from 2015 is available here (in Norwegian):

https://docplayer.me/2483170-Oslo-tingrett-kjennelse-01-09-2015-i-oslo-tingrett-15-067093tvi-otir-05-tingrettsdommer-jon-ostensvig-1-warner-bros-entertainment-norge-as.html

The latest verdict we received is from 01.06.2018, court reference
number is 18-039103TVI-OTIR/02. Excerpt from the text:

"
<List of ISPs> pålegges:

- å hindre eller vanskeliggjøre kundenes tilgang til LiveTV ved å
iverksette DNS-blokkering av følgende domenenavn med subdomener:
livetv.sx, livetvcdn.net, ...
"

<same paragraph repeated for several other sites: EPLSite,
Livefootballol, Cricfree>

The key phrase is "DNS-blokkering", i.e. DNS domain name blocking.

In these cases the court verdicts are of course openly available,
with the full list of domain names the ISPs are required to block.

I happen to work for one of the ISPs required to perform such
blocking. *In the context of such a verdict* it is completely
irrelevant for us how effective (or ineffective) such domain name
blocking is - we are simply required by the court to perform domain
name blocking.

Steinar Haug, AS2116

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 22 Aug 2019 07:56:33 +0200

Thanks for the information.

  Patrik

On 21 Aug 2019, at 20:24, [email-masked] wrote:

> There have been several verdicts in the Oslo District Court ordering Norwegian ISPs to prevent access to certain domains - and to implement this explicitly using DNS blocking.
>
> The latest verdict we received is from 01.06.2018, court reference number is 18-039103TVI-OTIR/02. Excerpt from the text:
>
> "
> <List of ISPs> pålegges:
>
> In these cases the court verdicts are of course openly available, with the full list of domain names the ISPs are required to block.
>
> I happen to work for one of the ISPs required to perform such blocking. *In the context of such a verdict* it is completely irrelevant for us how effective (or ineffective) such domain name blocking is - we are simply required by the court to perform domain name blocking.
>
> Steinar Haug, AS2116
>
> -- 
> Add mailing list
> [email-masked]

---

From: Alec Muffett <[email-masked]>
Date: Thu, 22 Aug 2019 07:12:02 +0100

On Wed, 21 Aug 2019 at 19:25, <[email-masked]> wrote:

> ...

> blocking is - we are simply required by the court to perform domain

So, for clarity, do the verdicts / obligations also extend to requiring
[Norwegian ISPs] to ban access to alternative name-resolution services in
order to support the efficacy of such a block?

    - alec

-- 
http://dropsafe.crypticide.com/aboutalecm

---

From: [email-masked]
Date: Thu, 22 Aug 2019 08:27:53 +0200 (CEST)

> order to support the efficacy of such a block?

The verdicts don't say anything about alternative name-resolution
services.

My personal view (note: IANAL): If only a few customers used such
alternative name-resolution, authorities probably wouldn't care.  If
"sufficiently many" customers did this, authorities would probably
take note, and require ISPs to implement blocking by other methods.

Steinar Haug, AS2116

---

From: Alec Muffett <[email-masked]>
Date: Thu, 22 Aug 2019 08:29:39 +0100

> take note, and require ISPs to implement blocking by other methods.

Noted; that's a concern that I hear a lot, that increasing adoption of more
secure, more private technologies - incidentally thereby creating a
two-tier internet for the "privacy-haves" and the "privacy-have-nots" -
will bring about a general political backlash against freedom of expression
and online privacy.

My experience of realpolitik is that in most "western" countries, such
blocks are essentially meant to symbolically express that the state has
"done something" to address access to [whatever].

They are only symbolic because (as we all understand) such blocks are
trivially circumvented via increasingly popular technologies such as VPNs
and Tor; and we all fear the blocks becoming more concrete, eg: by
implementation of a "Great Fjordwall of Norway" filtering all traffic
between Norway and the rest of the world.

I don't fear the cited "require ISPs to implement blocking by other
methods" - but then I am not an ISP.

Instead, I am someone who spends a *lot* of time[1][2][3] explaining to
politicians why their various blocks and restrictions won't work.

In this era of Netflix / Amazon / streaming services increasingly shipping
own-brand content and geolocking it, I would greatly welcome the
opportunity to put politicians to the test regards whether they believe
(say) VPNs are morally acceptable in any given country, rather than
timorously live and work in a grey area.

This is because I believe that no internet technology or protocol is
inherently immoral, and that the only objective moral metric which can be
applied reasonably to an internet technology is the intent of the specific
user and the result of its being used.

If and when this is recognised, then we will not have to expend time in
discussions such as these, which themselves are only echoes of similar
arguments[4][5] back in ~1998 about how the adoption of HTTPS was going to
lead to Government crackdowns and demands for key escrow.

And we will also reduce, perhaps stop, the destructive tendency of
splitting society into tiers of people who are technologically capable of
bypassing blocks, versus those (older? poorer? less educated?) who lack the
capability.

    - alec

[1] https://medium.com/@alecmuffett/on-the-digital-economy-bill-1df356862ac2
[2]
https://www.theguardian.com/technology/2017/mar/29/uk-government-encryption-whatsapp-investigatory-powers-act
[3]
https://www.openrightsgroup.org/blog/2017/the-british-public-and-its-freedom-to-tinker-with-data
[4] https://www.cnet.com/news/white-house-shuns-fbi-crypto-plan/
[5]
https://www.eff.org/deeplinks/2014/09/nine-epic-failures-regulating-cryptography

---

From: [email-masked]
Date: Thu, 22 Aug 2019 13:59:20 +0200 (CEST)

> "done something" to address access to [whatever].

I agree with this view, at least partly. However,

> methods" - but then I am not an ISP.

The fact that I agree to at least part of your view here is totally
irrelevant for my employer. My employer has been served with a court
order, and it would be extremely difficult to convince my employer
that such a court order should *not* be followed - especially since
this concerns rather blatant copyright violations.

> politicians why their various blocks and restrictions won't work.

I'm happy to hear that some people are trying to convince politicians
about this.

Steinar Haug, AS2116

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Aug 2019 08:58:49 -0700

> On Aug 21, 2019, at 11:27 PM, [email-masked] wrote:
> 

For the courts ISP are not special, they are just convenient. We already see plenty of examples of court orders affecting search engines, for example "right to forget" cases. The obvious outcome is not for courts to force ISP to block TLS. The most likely outcome is that court orders will apply to the quad resolvers as well.

-- Christian Huitema

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 22 Aug 2019 21:31:46 +0000

On 8/22/19, 11:59 AM, "Add on behalf of Christian Huitema" <[email-masked] on behalf of [email-masked]> wrote:
> The obvious outcome is not for courts to force ISP to block TLS. The most likely outcome is that court orders will apply to the quad resolvers as well.

[JL] I suspect some countries are very nearly at that point, which reflects the reality of market conditions, share, and control.

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 22 Aug 2019 21:37:19 +0000

From: Add <[email-masked]> on behalf of Rob Sayre <[email-masked]>
> I don't mean to imply there is consensus. In fact, I think there is none, and no work should happen.

[JL] This thread has gone a bit off-track from the initial message, but your sentiment above seems to be key. So let me note that personally I think you’ve expressed quite strongly that you do not feel any ADD-related work should happen, and you are welcome to that opinion as others are to theirs. My opinion is that I think it may be worth recognizing that many people feel that there is work to do, so perhaps it is worth letting that happen and seeing what comes of it (speaking as someone working to deploy encrypted DNS).