Subject: [Add] draft-grover-add-policy-detection-00

From: Rob Sayre <[email-masked]>
Date: Sat, 13 Jul 2019 15:48:05 -0700

This draft doesn't seem to conform to the requirements laid out in BCP 61.

https://tools.ietf.org/html/bcp61

thanks,
Rob

---

From: Andy Grover <[email-masked]>
Date: Sun, 14 Jul 2019 17:12:29 -0700

I don't follow, in what way?

---

From: Rob Sayre <[email-masked]>
Date: Sun, 14 Jul 2019 17:18:01 -0700

It's right there in BCP 61:
"However security must be a MUST IMPLEMENT so that end users will have the
option of enabling it when the situation calls for it."

It seems like this proposal standardizes automatically disabling security.
Maybe we could generalize it. Let's add some domains to the draft that
switch HTTPS to HTTP, and switch SSH to telnet.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 Jul 2019 17:30:31 -0700

On Sun, Jul 14, 2019 at 5:18 PM Rob Sayre <[email-masked]> wrote:

> Maybe we could generalize it.
>

Let's take a step back here. First, this document doesn't violate the
section of BCP 61 you are quoting, because that text doesn't require that
security be on by default. Second, there's plenty of precedent for
opportunistic encryption in IETF; see, for instance:
https://tools.ietf.org/rfcmarkup?doc=7435. Of course, this doesn't mean
that this document is necessarily a good idea, but to the best of my
knowledge it's not prohibited by any RFC.

The question of whether it's a good idea is rather more complicated: at a
high level we have a situation where nearly all DNS is unencrypted and sent
to a resolver which is insecurely configured. Some of those resolvers do
policy enforcement and in some of those cases, the user wanted that kind of
policy enforcement, so just switching over to a secure Trusted Recursive
Resolver potentially violates POLA, and it would be nice to be able to
detect those cases and do something [0]. Now, of course, that signal itself
is insecure, so this is pretty far from ideal, but the whole situation is
pretty messy, so it seems worthwhile to explore the space a bit.

> Let's add some domains to the draft that switch HTTPS to HTTP, and switch
> SSH to telnet.
>

This sort of rhetoric doesn't seem particularly helpful.

-Ekr

[0] And this draft doesn't say what "something" is, so, how good an idea
this is partly depends on what that is.

>> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Rob Sayre <[email-masked]>
Date: Sun, 14 Jul 2019 17:33:12 -0700

> This sort of rhetoric doesn't seem particularly helpful.

What's the difference?

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 Jul 2019 17:35:55 -0700

On Sun, Jul 14, 2019 at 5:33 PM Rob Sayre <[email-masked]> wrote:

>>> Let's add some domains to the draft that switch HTTPS to HTTP, and
>>> switch SSH to telnet.
>>>
>>

I believe I answered this question in my previous response.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Sun, 14 Jul 2019 17:37:42 -0700

On Sun, Jul 14, 2019 at 5:36 PM Eric Rescorla <[email-masked]> wrote:

> I believe I answered this question in my previous response
>

Hmm, maybe we could encrypt them using Dual_EC_DRBG.

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 15 Jul 2019 12:26:53 +0200 (CEST)

Il 15 luglio 2019 02:30 Eric Rescorla <[email-masked]> ha scritto:

The question of whether it's a good idea is rather more complicated: at a high level we have a situation where nearly all DNS is unencrypted and sent to a resolver which is insecurely configured. Some of those resolvers do policy enforcement and in some of those cases, the user wanted that kind of policy enforcement, so just switching over to a secure Trusted Recursive Resolver potentially violates POLA, and it would be nice to be able to detect those cases and do something [0].

Also, often that policy enforcement is actually being done on behalf of the user to increase his/her security, so even if we only wanted to focus on maximizing security, the choice would be between connecting securely to a (from the user's point of view) less secure resolver, and connecting insecurely to a more secure resolver; which option of the two is in the end more secure depends on the specific case (threat scenarios and their likelihood), so I think each application will make its own choice, often asking the user. Of course the proper solution is to have a way for the users to connect securely to the more secure resolver, but in the meantime both options should be made available.

--

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

---

From: Alec Muffett <[email-masked]>
Date: Mon, 15 Jul 2019 14:14:29 +0100

Rather than snark, I would like to raise the negative example of
"Haystack", a failed security and anonymity tool from several years back,
which collapsed in much contentiousness.

I was involved in revealing its flaws, so am deeply aware of the story:

*
https://www.theguardian.com/media/2010/mar/29/austin-heap-megas-innovator-award
[context]
*
https://www.computerworlduk.com/it-business/-awardwinning-haystack-security-system-could-risk-iranian-lives--3569566/
* https://dropsafe.crypticide.com/article/4409
*
https://liberationtech.stanford.narkive.com/jMCy8EpJ/deconstructing-the-security-risks-narrative-of-haystack#post2

Long story short: the application upon startup "beaconed" its existence in
a way which could lead to those who used it to be revealed to repressive
authorities, contra both its intention and its advertising.

It strikes me that any system - in pursuit of "protecting" the user with
"filters" - which both delegates the ability for the feature to be used to
some environmental authority and also reveals its use, is:

* defeating the intention of security, or at least placing the threat model
of the environment above that of the user, and...
* revolting against the end-to-end principle which drives so much of
ancient, and modern, internet architecture

As I understand it, we went to great lengths to ensure that TLS1.3 was not
open for environmentally-driven "downgrade attacks" to be possible; I
cannot reconcile this stance with the above proposal, where:

* [as I understand it] any cafe owner using PiHole will be able to suppress
TBD.arpa resolution, and disable DoH
* [as I understand it] any state telco (Iran, above?) can suppress TBD.arpa
resolution, and arrest anyone who attempts to resolve it for using
"non-compliant" software
* albeit the desire to protect people with MITM-filters is variously
legislated and appears desirable, I cannot see how delivery of such is now
compatible with the themes of rfc7258

Hence, I do and will strongly disapprove of this, and any other,
proposition that would disable -- or, importantly, reveal! -- explicit DoH
enablement choices that have made by a user.

I believe that DoH is a long-awaited universal good, and that it should
become common, even default, in order to foster consumer choice both in the
application space, and in the space of DNS providers; and that such choice
that must not be overridden by "environmental factors" - for all such
filters are men in the middle.

If not -- if policy detection and disablement is acceptable -- then why did
we work to expunge downgrade attacks in TLS1.3?

- alec

---

From: Alec Muffett <[email-masked]>
Date: Mon, 15 Jul 2019 14:17:55 +0100

On Mon, 15 Jul 2019 at 14:14, Alec Muffett <[email-masked]> wrote:

>
> * [as I understand it] any cafe owner using PiHole will be able to
> suppress TBD.arpa resolution, and disable DoH
> * [as I understand it] any state telco (Iran, above?) can suppress
> TBD.arpa resolution, and arrest anyone who attempts to resolve it for using
> "non-compliant" software

Alas how often one hits "Send" and then realises what one should have added:

* [as I understand it] any telco, state-sponsored or otherwise, can capture
the IP address of any host which beacons/attempts to resolve "TBD.arpa",
and then block all traffic to it, or else divert the latter for "special
treatment"

That's not really in the spirit of rfc7258, either.

    - alec

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

---

From: Alec Muffett <[email-masked]>
Date: Mon, 15 Jul 2019 14:54:36 +0100

On Mon, 15 Jul 2019 at 11:27, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> Also, often that policy enforcement is actually being done on behalf of
> the user to increase his/her security, so even if we only wanted to focus
> on maximizing security, the choice would be between connecting securely to
> a (from the user's point of view) less secure resolver, and connecting
> insecurely to a more secure resolver; which option of the two is in the end
> more secure depends on the specific case (threat scenarios and their
> likelihood), so I think each application will make its own choice, often
> asking the user. Of course the proper solution is to have a way for the
> users to connect securely to the more secure resolver, but in the meantime
> both options should be made available.
>

Hi Vittorio!

May I please observe for everyone that one of the quirks which will
complicate discussion of this proposal, is overloading of the word "secure"
in descriptions like this?

I am presuming that most people here have worked with some kind of "threat
modelling", but the high-level challenge here is that the word "secure"
(and "more/less secure") is abstract and not descriptive of "why" someone
might want to use one resolver over another; or why the environment
surrounding that user may wish to impose a different resolver upon them.

Hence something like:

*Also, often that policy enforcement is actually being done on behalf of
the user to increase his/her {PRIVACY, INTEGRITY}, so even if we only
wanted to focus on maximizing {PRIVACY, INTEGRITY}, the choice would be
between connecting {PRIVATELY, TAMPERPROOFLY, ASSUREDLY} to a (from the
user's point of view) less {PRIVATE, TRUSTWORTHY, TAMPERPROOF} resolver,
and connecting {WITH WEAK PRIVACY, ASSURANCE, TRUST} to a more {PRIVATE,
TRUSTWORTHY} resolver; which option of the two is in the end more
{PRIVATELY, TAMPERPROOF} depends on the specific case (threat scenarios and
their likelihood), so I think each application will make its own choice,
often asking the user. Of course the proper solution is to have a way for
the users to connect {PRIVATELY, TAMPERPROOFLY} to the more {PRIVATE,
TRUSTWORTHY} resolver, but in the meantime both options should be made
available.*

...delete as applicable? :-)

tl;dr - the "S" word does not mean anything without further explanation.

     - alec

---

From: "Dixon, Hugh" <[email-masked]>
Date: Tue, 16 Jul 2019 10:31:46 +0000

Hi Alec –
Given that this is at its core (just) a protocol for asking (any) DNS server whether it has a filtering policy, won’t “non-compliant software” will be the sort of software which does not beacon?  (sort-of detectable but not if it’s essentially optional app behaviour anyway, such that the absence of a beacon isn’t a significant “flag” – certainly not as much of a one as non-existent DNS activity - as it would be if all lookups have gone DoH-to-third-party)?
I think this is just a policy-signalling protocol, to enable users who “want to” to use the preferred policy-implementing resolver (quite possibly using DoH as the transport).  The wording gets a touch confusing in there – I’m sure a next draft would make the distinction clearer.
My comments are not a commentary on the wider effectiveness of the draft proposal by the way, just on the specific example given.

H

From: Add <[email-masked]> on behalf of Alec Muffett <[email-masked]>
Date: Monday, 15 July 2019 at 14:18
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [Add] draft-grover-add-policy-detection-00

On Mon, 15 Jul 2019 at 14:14, Alec Muffett <[email-masked]<mailto:[email-masked]>> wrote:

* [as I understand it] any cafe owner using PiHole will be able to suppress TBD.arpa resolution, and disable DoH
* [as I understand it] any state telco (Iran, above?) can suppress TBD.arpa resolution, and arrest anyone who attempts to resolve it for using "non-compliant" software
* albeit the desire to protect people with MITM-filters is variously legislated and appears desirable, I cannot see how delivery of such is now compatible with the themes of rfc7258

* [as I understand it] any telco, state-sponsored or otherwise, can capture the IP address of any host which beacons/attempts to resolve "TBD.arpa", and then block all traffic to it, or else divert the latter for "special treatment"

    - alec

--
http://dropsafe.crypticide.com/aboutalecm<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdropsafe.crypticide.com%2Faboutalecm&data=02%7C01%7Chugh.dixon%40sky.uk%7C3dc632e5eddf44e1891208d70926f9f2%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636987935332970513&sdata=304yZx6JcxrylBxUncE%2B6sdPBPWyO7qBA5IBPP8Rt1s%3D&reserved=0>
--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
--------------------------------------------------------------------

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

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

---

From: Alec Muffett <[email-masked]>
Date: Tue, 16 Jul 2019 12:26:36 +0100

> Hi Alec –

Hi Hugh!

Given that this is at its core (just) a protocol for asking (any) DNS
> server whether it has a filtering policy, won’t “non-compliant software”
> will be the sort of software which does not beacon?
>

That's kinda the whole point; the problem is that innocent people might try
using Firefox to access Twitter from Turkey during a civil rights
crackdown, their Firefox-implementing-this-mechanism will give them away as
trying to evade Government blocking of Twitter, and they will end up
arrested or worse.

Not everyone is in a position to welcome or appreciate upstream DNS
filtering "for their own good" - for instance, this example from Turkey:

https://www.mic.com/articles/85987/turkish-protesters-are-spray-painting-8-8-8-8-and-8-8-4-4-on-walls-here-s-what-it-means

It would seem regressive of Mozilla's principles to assist someone getting
identified & thrown in jail for non-compliance with repressive blocking;
not to mention - to repeat - the other obvious possibility is that any IP
address which beacons-out a lookup of TBD.arpa will immediately be
blackholed / firewalled, again to dissuade people from fact-checking their
government's spokespeople.

Or, perhaps you would consider this non-compliant-behaviour, worthy of such
sanction?

- alec

---

From: "Dixon, Hugh" <[email-masked]>
Date: Tue, 16 Jul 2019 11:50:34 +0000

[gah – can’t get mail client to indent-and-mark quoted content properly..  sorry – using bullets … ]

From: Alec Muffett <[email-masked]>
Date: Tuesday, 16 July 2019 at 12:26
To: "Dixon, Hugh" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [EXTERNAL] Re: [Add] draft-grover-add-policy-detection-00

On Tue, 16 Jul 2019, 11:31 Dixon, Hugh, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alec –
Hi Hugh!

Given that this is at its core (just) a protocol for asking (any) DNS server whether it has a filtering policy, won’t “non-compliant software” will be the sort of software which does not beacon?

·         That's kinda the whole point; the problem is that innocent people might try using Firefox to access Twitter from Turkey during a civil rights crackdown, their Firefox-implementing-this-mechanism will give them away as trying to evade Government blocking of Twitter, and they will end up arrested or worse.
Doesn’t requesting TBD.arpa signal intent-to-comply rather than the other way around?  I don’t quite get the link between “.. their Firefox-implementing-this-mechanism ..” and “..trying to evade .. blocking ..”. At any rate, it’s a draft policy-discovery protocol not an implementation guide, no?

·         Not everyone is in a position to welcome or appreciate upstream DNS filtering "for their own good" - for instance, this example from Turkey:
The proto doesn’t say that – it just drafts a possible mechanism for any DNS resolver to indicate to the caller that there is policy.  Could be for lots of reasons, and users with device/os/app admin intent and rights might well not check it, act on it, not act on it, sometimes act on it/interact with it.

·         It would seem regressive of Mozilla's principles to assist someone getting identified & thrown in jail for non-compliance with repressive blocking; not to mention - to repeat - the other obvious possibility is that any IP address which beacons-out a lookup of TBD.arpa will immediately be blackholed / firewalled, again to dissuade people from fact-checking their government's spokespeople.
I don’t get (see above) why a check for TBD.arpa indicates intent to subvert.  I was thinking [intent to subvert] <=> [not checking TBD.arpa] ..?

H

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 16 Jul 2019 14:29:25 +0200 (CEST)

Il 16 luglio 2019 13:26 Alec Muffett <[email-masked]> ha scritto:

That's kinda the whole point; the problem is that innocent people might try using Firefox to access Twitter from Turkey during a civil rights crackdown, their Firefox-implementing-this-mechanism will give them away as trying to evade Government blocking of Twitter, and they will end up arrested or worse.

I agree with you that it would be foolish for Firefox to look for local policies in that case, and it would endanger the user; that is a case where no policy discovery should ever be performed, and I would find that totally justified, with the caveat that if you replace "innocent people" with criminals, "Twitter" with a criminal website, and "Turkey" with the Western-democratic country that you like, you get the very same technical situation but with a completely different policy, regulatory and ethical flavour; but how to tell the two situations apart is a policy/UX problem that each application has to solve for itself.

However, that case does not make a policy discovery mechanism useless or unnecessary.

There are two symmetric cases of adversarial scenarios: one is the one that you describe, i.e. an application needing to bypass any local policy without leaving traces, and the other one is the local resolver willing to enforce any local policy even on users that want to bypass it by using other resolvers. In both cases, the non-cooperative actor will just ignore whatever mechanism for local resolver and policy discovery we devise: the application will not perform any policy discovery attempt, and the resolver will not advertise that it applies any policy. So, the fact that a discovery mechanism exists is irrelevant for those two cases.

On the other hand, the case by far most common is that of an ordinary consumer in an averagely democratic country that wants to access the Internet as securely as possible, relying for that on all the actors - the application, the Internet access provider and the public authorities. In that case, it is reasonable to expect that those actors cooperate and exchange the necessary information to establish the best possible environment for the final user, generally following whatever configuration the user prefers or needs for the application-level services to work. This, I guess, is the use case that the draft wants to address.

Ciao,

--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 07:21:28 -0700

Hi Alec,

This is a good question.

As I alluded to in my response to Robert Sayre, DoH has a difficult
deployment problem. Specifically, whether we like it or not, there are
some environments in which DNS filtering is in place and the user
wants it that way (parental [0] or anti-malware filtering are good
examples of this).

Now, this isn't an issue for a situation in which the user has
explicitly enabled DoH with a preference or setting, because the user
has indicated they want that (just as if they installed a VPN). And I
agree that if the user has done that, then the client should insist on
DoH whatever the local network environment. This is more analagous
to the TLS 1.3 case where we know that the user wants TLS.

The more difficult situation, however, is if you want to switch the
client's defaults, in which case you risk changing the user's
experience in a way they didn't want, which is also suboptimal.  So,
it would be good to determine when that is the case and avoid doing
it/warn the user/something. In some cases, it's possible to do this in
a secure way (e.g., see if there are enterprise settings for a
specific resolver), but sometimes there is no local setting and I'm
not aware of a secure way to detect that case (I agree that the
mechanism in this draft is insecure). In this case, the problem seems
more difficult.

In any case, hopefully this clarifies the situation. If you have
good ideas for the best way to address the problem, I would certainly
be interested.

-Ekr

[0] We can debate who the user in parental controls cases is, but
general the parent is the one who owns the device.

On Tue, Jul 16, 2019 at 4:26 AM Alec Muffett <[email-masked]> wrote:

> That's kinda the whole point; the problem is that innocent people might
> try using Firefox to access Twitter from Turkey during a civil rights
> Or, perhaps you would consider this non-compliant-behaviour, worthy of
> such sanction?
>
> - alec
>
> --
> Add mailing list
> [email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 08:23:58 -0700

> wants it that way (parental [0] or anti-malware filtering are good

Parental controls and malware detection are usually done on the device.

https://www.apple.com/newsroom/2019/04/the-facts-about-parental-control-apps/
https://blog.google/products/chrome/cleaner-safer-web-chrome-cleanup/

>
> In any case, hopefully this clarifies the situation.
>

It does not.

thanks,
Rob

>> https://www.mic..com/articles/85987/turkish-protesters-are-spray-painting-8-8-8-8-and-8-8-4-4-on-walls-here-s-what-it-means
>> <https://www.mic.com/articles/85987/turkish-protesters-are-spray-painting-8-8-8-8-and-8-8-4-4-on-walls-here-s-what-it-means>
>>
>> It would seem regressive of Mozilla's principles to assist someone
>> getting identified & thrown in jail for non-compliance with repressive
>> blocking; not to mention - to repeat - the other obvious possibility is
>> that any IP address which beacons-out a lookup of TBD.arpa will immediately
>> be blackholed / firewalled, again to dissuade people from fact-checking
>> their government's spokespeople.
>>

---

From: "Dixon, Hugh" <[email-masked]>
Date: Tue, 16 Jul 2019 15:26:51 +0000

“usually” is a distinctly statistical term.  Do you have any data ?

On Tue, Jul 16, 2019 at 7:22 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alec,

This is a good question.

https://www.apple.com/newsroom/2019/04/the-facts-about-parental-control-apps/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apple.com%2Fnewsroom%2F2019%2F04%2Fthe-facts-about-parental-control-apps%2F&data=02%7C01%7CHugh.Dixon%40sky.uk%7C3de4c155bbd6433210b308d70a01a74c%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636988874526692307&sdata=eQOV2bY5YeT%2Frhcox%2FcfmcJq8i1UyjXQlZg7GHTU%2FJ0%3D&reserved=0>
https://blog.google/products/chrome/cleaner-safer-web-chrome-cleanup/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.google%2Fproducts%2Fchrome%2Fcleaner-safer-web-chrome-cleanup%2F&data=02%7C01%7CHugh.Dixon%40sky.uk%7C3de4c155bbd6433210b308d70a01a74c%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636988874526692307&sdata=%2FpcZybWQN%2BhtlAJAvDok%2F8rHvsQy6Nw0oHKf6Y9ajfY%3D&reserved=0>

It does not.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 08:38:09 -0700

> https://blog.google/products/chrome/cleaner-safer-web-chrome-cleanup/

They are often done, but not always. For instance:
https://www.xfinity.com/support/articles/set-up-parental-controls-with-comcast-networking
https://www.quad9.net/faq/#How_does_Quad9_protect_me_from_malicious_domains

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 08:39:00 -0700

> “usually” is a distinctly statistical term.  Do you have any data ?

Sure, here's how parental control features work:

https://www.apple.com/families/

Windows Defender is a good example of malware removal and parental control:

https://www.microsoft.com/en-us/windows/comprehensive-security

That's the default software shipped by Apple and Microsoft. I have to
concur that this looks like a downgrade attack.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 09:10:24 -0700

> https://www.quad9.net/faq/#How_does_Quad9_protect_me_from_malicious_domains

I agree that some companies sell these products, but it doesn't seem like
they would work very well.

In any case, BCP 188 covers the issue we're describing quite well.

"The same techniques to achieve [Pervasive Monitoring] can be used
regardless of motivation.  Thus, we cannot defend against the most
nefarious actors while allowing monitoring by other actors no matter how
benevolent some might consider them to be, since the actions required of
the attacker are indistinguishable from other attacks."

Pervasive Monitoring Is an Attack
https://tools.ietf.org/html/rfc7258

thanks,
Rob

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 16 Jul 2019 16:29:56 +0000

I agree that some companies sell these products, but it doesn't seem like they would work very well.
Based on what data? From the non-technical customer perspective, it might actually be easier than learning each platform's chosen security/family friendly software. We shouldn't so easily dismiss an existing use case.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Rob Sayre <[email-masked]>
Sent: Tuesday, July 16, 2019 9:10 AM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked] <[email-masked]>; Dixon, Hugh <[email-masked]>; Alec Muffett <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00

On Tue, Jul 16, 2019 at 8:38 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

They are often done, but not always. For instance:
https://www.xfinity.com/support/articles/set-up-parental-controls-with-comcast-networking<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.xfinity.com%2Fsupport%2Farticles%2Fset-up-parental-controls-with-comcast-networking&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C82eff32a2ec24e15046608d70a0828a4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636988902477013835&sdata=t4CPtIpSAeuzAT0xElNYTqm4u5mKOLMLY5fuYoptmc4%3D&reserved=0>
https://www.quad9.net/faq/#How_does_Quad9_protect_me_from_malicious_domains<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.quad9.net%2Ffaq%2F%23How_does_Quad9_protect_me_from_malicious_domains&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C82eff32a2ec24e15046608d70a0828a4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636988902477013835&sdata=Rq%2F5NNW1fFT3OkvOhD4Ahu0qFt4yQQMCsoxALefxMGY%3D&reserved=0>

I agree that some companies sell these products, but it doesn't seem like they would work very well.

"The same techniques to achieve [Pervasive Monitoring] can be used regardless of motivation.  Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required of the attacker are indistinguishable from other attacks."

Pervasive Monitoring Is an Attack
https://tools.ietf.org/html/rfc7258<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7258&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C82eff32a2ec24e15046608d70a0828a4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636988902477013835&sdata=LLFHK5Wu0NrZEuJFaAcJvJ47lT4sUalpu%2Fe4GiUXjlQ%3D&reserved=0>

thanks,
Rob

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 16 Jul 2019 09:33:32 -0700

On 7/16/19 8:38 AM, Eric Rescorla wrote:
> 
> 
> On Tue, Jul 16, 2019 at 8:24 AM Rob Sayre <sayrer@gmail..com 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Tue, Jul 16, 2019 at 7:22 AM Eric Rescorla <ekr@rtfm..com
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Alec,
> 
>         This is a good question.
> 

Also, note that parental controls are but one use-case.  There are a 
number of enterprises which require DNS-based filtering, *in addition 
to* other controls on the endpoint.  The entire USG and many of its 
contractors are required to do DNS filtering.  Many organizations that 
provide grants to educational institutions have conditions that the 
recipient of the grant must make efforts to "block porn" (and yes, 
that's about the extent of the definition).  DNS filtering is a very 
reasonable way of complying.  Institutional DNS filtering works well 
with DoT configured at the system level on the stub resolver, and 
supported by the institution.  DoH can be made compatible with 
institutional filtering requirements, but it can also easily skirt those 
requirements: the devil is in the defaults.

Mozilla, with its documented plans to circumvent institutional DNS with 
Mozilla-blessed services running DoH, exemplifies the case where the 
default behavior is going to be incompatible with institutional 
requirements and regulatory frameworks.  The result is predictable: 
Where endpoints are under strict control, Mozilla will be uninstalled 
and effectively banned.  Where endpoint controls are not as strict, 
attempts will be made to block well-known DoH services.  This is already 
being done in some sectors.

Unless we find ways of making DoH compatible with institutional 
controls, the banhammer will come down and we will end up in an arguably 
worse spot (think proxy decryption of all HTTPS, banning of certain 
browsers, blocking of well-known services, etc.).  Personally, I don't 
want that to happen, but I fear it will if we don't make DoH more 
flexible by default.

michael

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 09:49:39 -0700

On Tue, Jul 16, 2019 at 9:33 AM Michael Sinatra <[email-masked]>
wroteil is in the defaults.

> and effectively banned.

Obviously, I can't control whether people install or uninstall any
particular piece of software,
but I do want to emphasize that (1) enterprise policy can be used to
disable and configure
DoH and (2) Firefox will disable DoH entirely if an enterprise policy is in
place but it
doesn't otherwise configure DoH.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 10:21:47 -0700

> https://tools.ietf.org/html/rfc7258

I'm quite familiar with this BCP but given it's emphasis on passive
monitoring and the associated interest in opportunistic security (RFC 7435)
I don't see any conflict here.

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Jul 2019 18:25:49 +0100

> On 16 Jul 2019, at 17:33, Michael Sinatra <[email-masked]> wrote:
> 
> Unless we find ways of making DoH compatible with institutional controls, the banhammer will come down and we will end up in an arguably worse spot (think proxy decryption of all HTTPS, banning of certain browsers, blocking of well-known services, etc.).  Personally, I don't want that to happen, but I fear it will if we don't make DoH more flexible by default.

Obligatory nit-picking:

What you're actually talking about here is one deployment/application of DoH, not the protocol itself. The basic protocol is fine (pretty much). It's how the protocol gets used that can create problems. DoH doesn't have to or need to become "compatible with institutional controls". It's the applications and services which use DoH might have to do that.

FWIW, I agree with what you say if "DoH" was replaced with "DoH deployment".

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Jul 2019 18:35:39 +0100

> On 16 Jul 2019, at 17:49, Eric Rescorla <[email-masked]> wrote:
> 
> Firefox will disable DoH entirely if an enterprise policy is in place but it
> doesn't otherwise configure DoH

Could you provide more clarification? How will Firefox know if an enterprise policy is in place or what that policy is? If Firefox "doesn't otherwise configure DoH", does that mean DoH will always be disabled by default unless the end user deliberately and intentionally switches it on? Would DNS/DoH filtering policies at say an ISP or coffee shop be considered as an enterprise policy?

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 16 Jul 2019 10:36:12 -0700

> FWIW, I agree with what you say if "DoH" was replaced with "DoH deployment".
Yes, everything I am talking about in this thread is as you say--my 
intent was "DoH deployment" even though I only said "DoH."  Thanks for 
the opportunity to clarify.

The one disagreement I have with DoH as a protocol is that it 
essentially obfuscates the DNS resolution process, from a network 
perspective.  But that's not under discussion here (and it's basically 
water under the bridge anyway).

michael

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 10:46:48 -0700

On Tue, Jul 16, 2019 at 9:29 AM Tommy Jensen <[email-masked]>
wrote:
> Based on what data?

The fact that they don't work very well? I actually happen to be a customer
of one of the services EKR linked, and I use a VPN to work around their DNS
quite often (not for control reasons--I think it just breaks a lot, so I
have to).

On the other hand, on-device enterprise policies are an effective way to
control DNS resolution.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 10:55:20 -0700

Sorry, this was badly written. Here's an attempt to clarify:

if there is an enterprise policy that is set and it configures or enables
DoH, then when we will respect that. If there is an enterprise policy set
and it says nothing about DoH, then our plan is to disable DoH on the
theory that with high probability the enterprise would want DoH off.

When I refer to enterprise policy I mean:
https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise

-Ekr

On Tue, Jul 16, 2019 at 10:35 AM Jim Reid <[email-masked]> wrote:

> Could you provide more clarification? How will Firefox know if an
> enterprise policy is in place or what that policy is? If Firefox "doesn't
> otherwise configure DoH", does that mean DoH will always be disabled by
> default unless the end user deliberately and intentionally switches it on?
> Would DNS/DoH filtering policies at say an ISP or coffee shop be considered
> as an enterprise policy?
>
>

---

From: Alec Muffett <[email-masked]>
Date: Tue, 16 Jul 2019 19:04:02 +0100

As an aside, I am finding it terribly interesting to consider that any
pursuit of "protecting" the user from their installing TorBrowser and using
it willy-nilly MUST be client-based... because it is a matter of
restricting access to such a browser viewed in its aspect as a chunk of
software.

Put differently, from the perspective of some of these enterprise controls
we are talking about, TorBrowser might be viewed as "malware".

Yet: Firefox is literally the foundation of TorBrowser, but somehow when
Firefox is resolving DNS addresses via DoH, it suddenly becomes a problem
where we are talking about the "necessity" of things which otherwise we
dismiss as pervasive monitoring: canary domain names, privacy-busting
beacons, and third party enforcement over someone else's ability to connect
to their intended destination.

Odd, that.

-a

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 14:19:57 -0400

> https://blog.google/products/chrome/cleaner-safer-web-chrome-cleanup/

I can't speak to parental control systems in general.
Only devices locked against the user can implement parental controls in the device.
(In my house, my kid owns his own devices, so controls are implemented in the
router, and are almost all time-based, not content based)

The Cisco "Umbrella" and CIRA "D-Zone Firewall" are two products that I'm aware
of, which work by denying DNS lookups that result in connections to malware.
This is not done in the device.

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

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 16 Jul 2019 11:32:57 -0700

On 7/16/19 11:04 AM, Alec Muffett wrote:

> Firefox is resolving DNS addresses via DoH, it suddenly becomes a 
> problem where we are talking about the "necessity" of things which 
> otherwise we dismiss as pervasive monitoring: canary domain names, 
> privacy-busting beacons, and third party enforcement over someone else's 
> ability to connect to their intended destination.

In the case of most enterprise policy enforcement, it's not a third 
party that's imposing the restrictions, it's the enterprise itself.  The 
enterprise *may* decide to outsource this activity, and it may also be 
"guided" by a regulatory framework.  However, I wouldn't necessarily 
call that "third party enforcement."

As another example, in my home network, I impose DNS filtering 
restrictions, in conjunction with endpoint management, to restrict the 
set of destinations that *my software* can contact.  I have configured 
Firefox (for example) to explicitly not use DoH or its TRR list, so that 
*I* can better control what Firefox does on my network when I am using 
it.  As someone who operates my own resolver on my home network, with 
QNAME minimization enabled, I am a big supporter of ADoT.  DoH 
(depending on how it is deployed), however, has the potential to 
complicate my ability to control what my applications do.  This is 
especially the case if applications try to obfuscate or prevent me from 
disabling their own resolution methods to use mine.  Part of my goal in 
this discussion is therefore to ensure that the applications that *I* 
use play properly with *my* controls.

Finally, since you brought up pervasive monitoring, consider a scenario 
where I run my own resolver and ADoT is pervasively deployed.  Would 
Firefox sending all of me DNS queries to Cloudflare (a third party, no?) 
afford me more privacy than what I currently have?

michael

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 11:49:35 -0700

> I don't see any conflict here.

I think the conflict is that the BCP states that the perceived benevolence
of an application (parental controls, malware blockers, etc) doesn't
matter, but that seems to be the case being made here.

Aside from that seemingly obvious conflict, it doesn't seem like DNS-based
solutions would really work very well for these benevolent applications.
It's sort of like using a coffee cup as an umbrella--it will catch some
rain, yes.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 11:54:52 -0700

> It's sort of like using a coffee cup as an umbrella--it will catch some

Oh, also, RFC 7435 is Informational, while RFC 7258 is a BCP. BCPs are the
documents that describe what the IETF is supposed to be doing, right?

thanks,
Rob

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Tue, 16 Jul 2019 18:56:29 +0000

Hi

On Jul 16, 2019, at 1:56 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

if there is an enterprise policy that is set and it configures or enables DoH, then when we will respect that. If there is an enterprise policy set and it says nothing about DoH, then our plan is to disable DoH on the theory that with high probability the enterprise would want DoH off.

When I refer to enterprise policy I mean: https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise

Just so I understand, this looks like it only applies to enterprise managed desktops, or to PCs enrolled in a managed AD environment.

Is there a general means for the enterprise to communicate it's policy for any Firefox instance that runs in its network?

-Glenn

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 16 Jul 2019 13:02:19 -0600

sayrer> I think the conflict is that the BCP states that the perceived
sayrer> benevolence of an application (parental controls, malware
sayrer> blockers, etc) doesn't matter, but that seems to be the case
sayrer> being made here.

The point is that the perceived benevolence doesn't matter if there was
no user choice. The use case of parental blocking or enterprise security
policies is made with user choice and cooperation so this BCP isn't
relevant to those use cases.

sayrer> Aside from that seemingly obvious conflict, it doesn't seem like
sayrer> DNS-based solutions would really work very well for these
sayrer> benevolent applications. It's sort of like using a coffee cup as
sayrer> an umbrella--it will catch some rain, yes.

Please stop saying this. Your own personal dissatisfaction is at odds
with literally millions of homes using these parental blocks via DNS and
most of the fortune 500 and many other SMBs using DNS RPZ/firewall. Both
parental and enterprise use are long standing, effective and popular.

Let's move on, please.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 12:10:43 -0700

> parental and enterprise use are long standing, effective and popular.

I don't dispute that people sell them, but I do dispute that they work well.

Whenever encryption is introduced to a protocol, there will be some
middlebox vendors that get disintermediated.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 12:19:41 -0700

> middlebox vendors that get disintermediated.

So, to bring a little data to the table, two of the top 100 grossing US
iPhone apps are VPNs (Norton Secure VPN - WiFi Proxy, HotspotShield VPN &
Wifi Proxy).

I haven't used either one, but they are easily installed through the app
store and integrated into the iOS network settings app. These would bypass
any DNS-based filter policy.

You don't need to be hacker to install this stuff, and their position on
the grossing charts seems to indicated that they are effective (otherwise
people would not pay).

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 12:22:49 -0700

On Tue, Jul 16, 2019 at 11:56 AM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> Hi
>
> On Jul 16, 2019, at 1:56 PM, Eric Rescorla <[email-masked]> wrote:
>
> Just so I understand, this looks like it only applies to enterprise
> managed desktops, or to PCs enrolled in a managed AD environment.
>

Yes.

> Is there a general means for the enterprise to communicate it’s policy for
> any Firefox instance that runs in its network?
>

Not at present.
https://tools.ietf.org/html/draft-grover-add-policy-detection-00 is an
exploration of one possible avenue, but as has been discussed somewhat
extensively, it's not a secure signal, so we're not sure how useful it is.

-Ekr

---

From: Barry Greene <[email-masked]>
Date: Tue, 16 Jul 2019 12:25:11 -0700

> On Jul 16, 2019, at 12:02 PM, Paul Ebersman <[email-masked]> wrote:
> 

+1

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 12:28:13 -0700

> matter, but that seems to be the case being made here.

No. I'm not arguing that it's benevolent but that it's something the user
of the computer wanted.

> It's sort of like using a coffee cup as an umbrella--it will catch some

I'm not sure how relevant this is, but you seem to be assuming that people
are actively trying to evade these controls. Obviously that's true in some
cases, but if I point my DNS to Quad9, it's because I *want* them to do
malware and phishing detection [0], and so I have no interest in evading
that. I'm not aware of any inherent reason to believe that would be
ineffective. Note that Firefox and Chrome also use a domain-name based
technique for anti-phishing.

-Ekr

[0] The parental control case is more complicated, and so the level of
attempted evasion varies.

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Jul 2019 20:30:26 +0100

> On 16 Jul 2019, at 20:10, Rob Sayre <[email-masked]> wrote:
> 
> I don't dispute that people sell them [DNS blocking systems], but I do dispute that they work well.

How is this relevant to the discussion of the above draft? 

Whether or not these tools/services work well is another issue entirely. And IMO not something to discuss at the IETF.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 12:31:08 -0700

On Tue, Jul 16, 2019 at 11:55 AM Rob Sayre <[email-masked]> wrote:

>> I think the conflict is that the BCP states that the perceived
>> benevolence of an application (parental controls, malware blockers, etc)
>> doesn't matter, but that seems to be the case being made here.
>>
>> Aside from that seemingly obvious conflict, it doesn't seem like
>> DNS-based solutions would really work very well for these benevolent
>> applications. It's sort of like using a coffee cup as an umbrella--it will
>> catch some rain, yes.
>>
>

Well, sort of. But in this case, 7435 is a Consensus document, it just
doesn't have normative force. Thus, I think it's reasonably strong evidence
that opportunistic security isn't inconsistent with 7258. IIRC Stephen
Farrell was AD at the time, so perhaps he'd be willing to offer his
perspective.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 12:37:39 -0700

On Tue, Jul 16, 2019 at 12:28 PM Eric Rescorla <[email-masked]> wrote:

> are actively trying to evade these controls.
>

Well, they are, but your point about voluntary participation is different.

> Obviously that's true in some cases, but if I point my DNS to Quad9, it's
> because I *want* them to do malware and phishing detection [0], and so I
> have no interest in evading that. I'm not aware of any inherent reason to
> believe that would be ineffective.
>

Yeah, I think the question is whether a user would /also/ want that task to
be unencrypted. That doesn't make much sense to me.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 12:52:53 -0700

On Tue, Jul 16, 2019 at 12:37 PM Rob Sayre <[email-masked]> wrote:

>> I'm not sure how relevant this is, but you seem to be assuming that
>> people are actively trying to evade these controls.
>>
>

Some people are, some are not. In case it's not clear, my interest here is
in providing DoH/TRR for people who have not explicitly decided they want
some sort of non-transparent DNS service while avoiding changing the
experience of people who have decided they do want some sort of
non-transparent/filtered DNS service. What we are trying to do is figure
out who is who.

> Yeah, I think the question is whether a user would /also/ want that task
> to be unencrypted. That doesn't make much sense to me.
>

Ah, I think we are now converging on the relevant point.

Taking a TRR-style system out of the equation for a moment. Suppose that
what I want is for all devices on my network to use a filtering resolver. I
don't expect any evasion because they're all my devices, it's just a matter
of convenience to centrally configure it. So what I do here is I configure
my DHCP server to provide the IP address of that resolver. Now, those
devices do unencrypted DNS because that's what everyone does. Now, suppose
that resolver starts offering DoT. How do my devices learn that
information? The resolver could tell them over DNS but then we have a
straightforward downgrade attack from anyone on the network. Do you agree
with this so far? Do you have a proposed solution?

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 13:02:18 -0700

> with this so far? Do you have a proposed solution?

In fairness, I'm not sure I quite follow. But, if I worked at a browser
vendor, I would be worried about DoH rollout too. I think I'd gradually
ratchet up the security signals in the location bar with the end result of
marking sites insecure if their IP was fetched over DNS in the clear. This
is distinct from choosing a DNS vendor.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 13:10:53 -0700

On Tue, Jul 16, 2019 at 1:02 PM Rob Sayre <[email-masked]> wrote:

> marking sites insecure if their IP was fetched over DNS in the clear.
>

Ignoring the UI question, let me push a bit on "in the clear".

Currently, resolvers are configured by IP address, not domain name. So
absent mechanisms such as TRR, how does the DNS client form a secure
connection to the resolver? What domain name is in the certificate and how
does the client learn that domain name?

-Ekr

> This is distinct from choosing a DNS vendor.
>
> thanks,
> Rob
>
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Jul 2019 21:17:12 +0100

And there was me trying to stay out of this for a bit:-)

> Farrell was AD at the time, so perhaps he'd be willing to offer his

First, having been the AD at the time isn't IMO significant,
but I was involved in the discussions yes.

I don't think there's any contradiction between 7435 and 7258.
Different people do have different opinions when it comes to
opportunistic security, but I think many of the competing arguments
have some merit. Opportunistic security, for me, is generally a
step on the road to stricter security and is most useful where it's
not practical to move from little/no-security to strict security.
I guess the canonical argument for the utility of that relates
to SMTP/TLS between MTAs.

In terms of ADD, I guess there could be some scope for handling
signals as to the (non)-existence of a relevant policy in an
opportunistic manner, I'm not sure. But I don't see how that
might apply with the draft in the subject line, where an NXDOMAIN
indicates a policy exists somewhere between the stub and the
root zone.

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 13:17:28 -0700

> Ignoring the UI question, let me push a bit on "in the clear".

Sure, but I don't you should ignore the UI question. Having been on the
receiving end of a few "why is the lock broken on our site?" emails from a
CEO, I can tell you it is really effective.

>
> Currently, resolvers are configured by IP address, not domain name.
>

This is true, so companies go for stuff like 1.1.1.1 and 8.8.8.8.

> So absent mechanisms such as TRR, how does the DNS client form a secure

I agree that there's a bootstrapping problem, but I don't think this draft
helps with that.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 13:22:53 -0700

> This is true, so companies go for stuff like 1.1.1.1 and 8.8.8.8.

Right, but if you're getting that out of DHCP, that doesn't help, because
you can't trust that.

> I agree that there's a bootstrapping problem, but I don't think this draft

I'm not saying it does. I'm just trying to work through the entire problem.
What I'm arguing here is that absent external configuration (e.g.,
DoH/TRR), there's no real way to get encrypted DNS that is secure against
active attack.

-Ekr

---

From: Erik Kline <[email-masked]>
Date: Tue, 16 Jul 2019 13:37:16 -0700

On Tue, 16 Jul 2019 at 13:24, Eric Rescorla <[email-masked]> wrote:

>> I agree that there's a bootstrapping problem, but I don't think this
>> draft helps with that.
>>
>
> I'm not saying it does. I'm just trying to work through the entire
> problem. What I'm arguing here is that absent external configuration (e.g.,

When we did the DNS-over-TLS config for Android we chose it be
hostname-based, on the theory that you could bootstrap using the
network-provided nameservers, DNSSEC (which, admittedly, Android didn't
support), and TLS (including optional browser security measures on top,
perhaps cert pinning, etc.)

I couldn't see how to make it much better than that.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 13:47:48 -0700

On Tue, Jul 16, 2019 at 1:37 PM Erik Kline <[email-masked]> wrote:

>>>>> In fairness, I'm not sure I quite follow. But, if I worked at a
>>>>> browser vendor, I would be worried about DoH rollout too. I think I'd
>>>>> gradually ratchet up the security signals in the location bar with the end
>>>>> result of marking sites insecure if their IP was fetched over DNS in the
>>>>> clear.
>>>>>
>>>>

Yes, this is how Firefox works as well, but that requires someone to supply
Fx with the hostname.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 13:54:02 -0700

> DoH/TRR), there's no real way to get encrypted DNS that is secure against

I'm not arguing against DoH--it's great. I think browsers should enable it,
and then gradually start enforcing its use. I'm not sure what the best way
to solve the bootstrapping problem is, but installing some initial name
servers doesn't seem so bad. After all, it's already required that
autocomplete resolves to the right search engine, the update server is the
right one, etc. Of course, companies should be able install their own, etc.

I can't square that with a feature that automatically disables DoH in the
clear, as proposed. Bootstrapping secure DNS does change the power dynamics
of the internet a little bit (but not really that much... see VPNs etc), so
some people might get angry.

thanks,
Rob

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 16 Jul 2019 13:59:29 -0700

On 7/16/19 1:47 PM, Eric Rescorla wrote:

>     network-provided nameservers, DNSSEC (which, admittedly, Android
>     didn't support), and TLS (including optional browser security
>     measures on top, perhaps cert pinning, etc.)
> 
> Yes, this is how Firefox works as well, but that requires someone to 
> supply Fx with the hostname..

This may be getting into the weeds, but unbound (for example) has 
mechanisms for tagging a hostname to the forwarder IP address for 
cert-validation purposes.

Basically, the problem is solved in a similar way for DoT as in DoH. 
The format of the TRR is just a bit different...

michael

---

From: Erik Kline <[email-masked]>
Date: Tue, 16 Jul 2019 15:59:12 -0700

On Tue, 16 Jul 2019 at 12:23, Eric Rescorla <[email-masked]> wrote:

>> Is there a general means for the enterprise to communicate it’s policy
>> for any Firefox instance that runs in its network?
>>
>
> Not at present.
> https://tools.ietf..org/html/draft-grover-add-policy-detection-00
> <https://tools.ietf.org/html/draft-grover-add-policy-detection-00> is an

I was wondering about the possibility of having a signal in the intarea PVD
additional info
<https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-05#section-4>
JSON.

Simplest: a boolean that says "our DNS servers do/do not filter". Compliant
apps/OSes can observe and choose to comply.

Slightly more complicated: a field that contains a list of resolvers that
do filtering.  Again, compliant OSes/apps can know to use those.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 16 Jul 2019 22:01:11 -0700

On Tue, Jul 16, 2019 at 12:30 PM Jim Reid <[email-masked]> wrote:

>
> Whether or not these tools/services work well is another issue entirely.
> And IMO not something to discuss at the IETF.
>

Hi Jim,

I thought about this email a lot today.

I think the problem with its sentiment is that whether or not
tools/services work on the Internet might be fairly called "engineering",
and this is the Internet Engineering Task Force, right?

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 17 Jul 2019 10:06:42 +0200 (CEST)

Il 17 luglio 2019 07:01 Rob Sayre <[email-masked]> ha scritto:

On Tue, Jul 16, 2019 at 12:30 PM Jim Reid <
[email-masked]> wrote:

Hi Jim,

I think the problem with its sentiment is that whether or not tools/services work on the Internet might be fairly called "engineering", and this is the Internet Engineering Task Force, right?

But if you have tools that work well enough that millions of people rely on them and that they are encouraged or even mandated in many countries, and you decide to develop and implement technologies to prevent them from working, this (the decision, not the development and implementation) might fairly be called "policy", and this is not the Internet Policy Task Force.

This is why, when you move outside of this organization to other circles - policy, political, business and security circles that do not belong here -, there is a sentiment that ranges from surprise to outrage when they discover that the IETF is implementing a policy decision of significant global impact in which no one but the IETF was involved.

So it would be good if we could just have a productive discussion to advance the user's privacy and security for all use cases while keeping everyone's needs together, rather than repeatedly discussing whether the needs of the others are legitimate.

--

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 01:35:23 -0700

On Wed, Jul 17, 2019 at 1:06 AM Vittorio Bertola <
[email-masked]> wrote:

> But if you have tools that work well enough that millions of people rely
> on them and that they are encouraged or even mandated in many countries,
> and you decide to develop and implement technologies to prevent them from
> working, this (the decision, not the development and implementation) might
> fairly be called "policy", and this is not the Internet Policy Task Force.
>

That's a great point. Can't argue with that.

thanks,
Rob

---

From: tirumal reddy <[email-masked]>
Date: Wed, 17 Jul 2019 19:35:24 +0530

> does the client learn that domain name?

https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04
discusses
mechanism to automatically bootstrap endpoints to discover and authenticate
DoT/DoH servers provided by a local network. The client securely learns the
domain name and DNS server certificate.

Cheers,
-Tiru

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Jul 2019 08:25:17 -0700

Hi Vittorio,

On Wed, Jul 17, 2019 at 1:06 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> On Tue, Jul 16, 2019 at 12:30 PM Jim Reid < [email-masked]> wrote:
>
>
> working

The IETF builds building blocks that meet specific needs.  In building DNS
over TLS, DNS over DTLS, and DNS over HTTPS, it was adding the protocol
functionality to make DNS queries confidential from inspection by network
observers.  The energy for that work was the reaction to pervasive
surveillance, but it is clear that other attackers had been gathering data
for some time.  The IETF was not building these protocols to stop the use
of the DNS as a policy enforcement mechanism and it is entirely possible to
integrate them into a system which does this by offering the policy
enforcing resolver over one of these confidential protocols.

But, and this is the crux of the matter, that integration requires the
cooperation of the endpoint or its control by an organization's system
administrators.  If you do not have their cooperation or the right to
manage them by tools like those Eric mentions, it is difficult for the
endpoint to distinguish a network-level interception by a mandated policy
engine and by an attacker.

Rather than falling back to the state where the endpoint simple accepts
that its traffic is visible to all and possibly intercepted, this new work
is an effort to make it easier for you to gain the cooperation required.  I
hope you can see that this is in both the interest of policy enforcement
bodies and the end users.

best regards,

Ted

---

From: Neil Cook <[email-masked]>
Date: Wed, 17 Jul 2019 16:38:46 +0100

Hi Ted,

> But, and this is the crux of the matter, that integration requires the cooperation of the endpoint or its control by an organization's system administrators.  If you do not have their cooperation or the right to manage them by tools like those Eric mentions, it is difficult for the endpoint to distinguish a network-level interception by a mandated policy engine and by an attacker.  
> 
> Rather than falling back to the state where the endpoint simple accepts that its traffic is visible to all and possibly intercepted, this new work is an effort to make it easier for you to gain the cooperation required.  I hope you can see that this is in both the interest of policy enforcement bodies and the end users.

So I use DNS filtering in my own house (along with millions of other people as already stated on this thread), provided by my network operator (but it doesn’t have to be - I used to use OpenDNS for example, and I have the capability to run my own resolver if I so desired). I have malware filtering as well as parental controls enabled. I am the de-facto network administrator in my house,  but I don’t have the tools or software that enterprises use so I won’t benefit from the work being done to help enterprises control this. I also have other people coming into my house and using my network, and I also like to control what they can access when they are in my home. All of this works very well for me today. It doesn’t work for me when applications/endpoints start deciding that my network is an attacker because it does filtering, and bypassing that filtering "in the interest of end-users".

> I hope you can see that this is in both the interest of policy enforcement bodies and the end users.

I’d like to ask, ask an end-user, how is this in my interests?

Neil

> On 17 Jul 2019, at 16:25, Ted Hardie <[email-masked]> wrote:
> 
> Hi Vittorio,
> 
> On Wed, Jul 17, 2019 at 1:06 AM Vittorio Bertola <vittorio.bertola=[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Il 17 luglio 2019 07:01 Rob Sayre <[email-masked] <mailto:[email-masked]>> ha scritto:
>> 
>> 
>> On Tue, Jul 16, 2019 at 12:30 PM Jim Reid < [email-masked] <mailto:[email-masked]>> wrote: 
>> 
> But if you have tools that work well enough that millions of people rely on them and that they are encouraged or even mandated in many countries, and you decide to develop and implement technologies to prevent them from working
> 
> The IETF builds building blocks that meet specific needs.  In building DNS over TLS, DNS over DTLS, and DNS over HTTPS, it was adding the protocol functionality to make DNS queries confidential from inspection by network observers.  The energy for that work was the reaction to pervasive surveillance, but it is clear that other attackers had been gathering data for some time.  The IETF was not building these protocols to stop the use of the DNS as a policy enforcement mechanism and it is entirely possible to integrate them into a system which does this by offering the policy enforcing resolver over one of these confidential protocols.  
> 
> But, and this is the crux of the matter, that integration requires the cooperation of the endpoint or its control by an organization's system administrators.  If you do not have their cooperation or the right to manage them by tools like those Eric mentions, it is difficult for the endpoint to distinguish a network-level interception by a mandated policy engine and by an attacker.  
> 
> Rather than falling back to the state where the endpoint simple accepts that its traffic is visible to all and possibly intercepted, this new work is an effort to make it easier for you to gain the cooperation required.  I hope you can see that this is in both the interest of policy enforcement bodies and the end users.
> 
> best regards,
> 
> Ted
> 
> 
> -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

Neil Cook
[email-masked]

-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
Chairman of the Board: Richard Seibt

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2019 16:54:07 +0100

Hiya,

On 17/07/2019 16:38, Neil Cook wrote:
> So I use DNS filtering in my own house (along with millions of other
> people as already stated on this thread), provided by my network
> operator (but it doesn’t have to be - I used to use OpenDNS for
> example, and I have the capability to run my own resolver if I so
> desired). I have malware filtering as well as parental controls
> enabled. I am the de-facto network administrator in my house,  but I
> don’t have the tools or software that enterprises use so I won’t
> benefit from the work being done to help enterprises control this. I
> also have other people coming into my house and using my network, and
> I also like to control what they can access when they are in my home.
> All of this works very well for me today. It doesn’t work for me when
> applications/endpoints start deciding that my network is an attacker
> because it does filtering, and bypassing that filtering "in the
> interest of end-users".
I don't question your right to do as you do, but as an (I hope)
equally valid single data point, I don't do the above and would
be fine if visitors to my home network used DoH with an external
service without being under my control. Going further, were I to
enforce my DNS policy choices on visitors to my home network
without explaining those, (which is mostly impractical), I would
consider myself to be potentially attacking visitors to my home,
which is IMO inhospitable.

There are multiple valid conflicting setups here and the issue I
think is that the application doing DNS can't detect which are in
play, so the application developer has to try pick a safe default
I guess. Not an easy task.

S.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Jul 2019 08:57:39 -0700

Hi Neil,

> bodies and the end users.
So I use DNS filtering in my own house (along with millions of other people
> as already stated on this thread), provided by my network operator (but it
> doesn’t have to be - I used to use OpenDNS for example, and I have the
> capability to run my own resolver if I so desired). I have malware
> filtering as well as parental controls enabled. I am the de-facto network
> administrator in my house,  but I don’t have the tools or software that
> enterprises use so I won’t benefit from the work being done to help
> enterprises control this. I also have other people coming into my house and
> using my network, and I also like to control what they can access when they
> are in my home. All of this works very well for me today. It doesn’t work
> for me when applications/endpoints start deciding that my network is an
> attacker because it does filtering, and bypassing that filtering "in the
> interest of end-users".
>
I am sorry if I was not clear,  The point of the draft is to enable the
network operator to signal this:

   If the user agent can check for the presence of a policy, this could be
   used as a signal that the network operator wishes its resolver to be
   used as a condition of using the network, and that DoH or DoT should
   be disabled.

That permits your guests to know of your network policy and to abide by it
if they choose; presumably you would not provide network access if they
chose not to.

regards,

Ted Hardie

Neil

---

From: Neil Cook <[email-masked]>
Date: Wed, 17 Jul 2019 17:10:27 +0100

Hi Ted,

Thanks, I guess I misunderstood what you were trying to say regarding the draft,

Neil

> On 17 Jul 2019, at 16:57, Ted Hardie <[email-masked]> wrote:
> 
> Hi Neil,
> 
> I am sorry if I was not clear,  The point of the draft is to enable the network operator to signal this:
> That permits your guests to know of your network policy and to abide by it if they choose; presumably you would not provide network access if they chose not to. 
> 
> regards,
> 
> Ted Hardie
> 
> Neil
> 
>> On 17 Jul 2019, at 16:25, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Vittorio,
>> 
> [email-masked] <mailto:[email-masked]>
> 

Neil Cook

European Office: 

US Office:

---

From: Neil Cook <[email-masked]>
Date: Wed, 17 Jul 2019 17:17:46 +0100

Hi Stephen,

> On 17 Jul 2019, at 16:54, Stephen Farrell <[email-masked]> wrote:

Indeed, everyone has the right to their own viewpoint, and we should consider as many as possible when designing protocols, particularly when they differ from our own.

> I guess. Not an easy task.

Well I guess the draft under discussion is trying to make it such that cooperating endpoint don’t have to just pick a safe default (in a user population of two, at least one of us will be unhappy with that default!), and can ideally make a more informed decision.

> S.
> <0x5AB2FAF17B172BEA.asc>-- 
> Add mailing list
> [email-masked]

Neil Cook

European Office: 

US Office:

---

From: Alec Muffett <[email-masked]>
Date: Wed, 17 Jul 2019 18:00:28 +0100

> if they choose; presumably you would not provide network access if they

"Hello, my name is Totalitarian Dictator, welcome to my house, make
yourself comfortable - you may be here for some time. Feel free to use the
wifi, the password is on the fridge. Can I fix you a drink?"

- alec :-)

---

From: Neil Cook <[email-masked]>
Date: Wed, 17 Jul 2019 18:08:32 +0100

Well you say Totalitarian Dictator, bu usually my children call me dad :)

Neil

> On 17 Jul 2019, at 18:00, Alec Muffett <[email-masked]> wrote:
> 
> 
> 
> On Wed, 17 Jul 2019, 16:58 Ted Hardie, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> "Hello, my name is Totalitarian Dictator, welcome to my house, make yourself comfortable - you may be here for some time. Feel free to use the wifi, the password is on the fridge. Can I fix you a drink?" 
> 
> - alec :-)
> 
> 
> -- 
> Add mailing list
> [email-masked]

Neil Cook

European Office: 

US Office:

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jul 2019 10:24:11 -0700

On Wed, Jul 17, 2019 at 7:05 AM tirumal reddy <[email-masked]> wrote:

>>>> Taking a TRR-style system out of the equation for a moment. Suppose
>>>> that what I want is for all devices on my network to use a filtering
>>>> resolver. I don't expect any evasion because they're all my devices, it's
>>>> just a matter of convenience to centrally configure it. So what I do here
>>>> is I configure my DHCP server to provide the IP address of that resolver.
>>>> Now, those devices do unencrypted DNS because that's what everyone does.
>>>> Now, suppose that resolver starts offering DoT. How do my devices learn
>>>> that information? The resolver could tell them over DNS but then we have a
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04 discusses

This draft does not seem like it has the general applicability that would
be required in the scenarios that browsers often face.

-Ekr

---

From: Alec Muffett <[email-masked]>
Date: Wed, 17 Jul 2019 18:28:05 +0100

> Well you say Totalitarian Dictator, bu usually my children call me dad :)

...and there's the rub; of the two/more problem spaces, I see more
implementation opportunities in parental benificient oversight, than for
escape to a free web for oppressed peoples.

Put differently: you are a parent or guardian and you care for a small
population of children. Dictators oppress thousands to millions. A
utilitarian approach suggests that the latter are more important to enable,
than would be the cost of mildly inconveniencing or requiring the former to
change their protective approach.

- alec

---

From: Evan Hunt <[email-masked]>
Date: Wed, 17 Jul 2019 18:25:45 +0000

> change their protective approach.

On the other hand there are millions of parents, so the strict utilitarian
analysis might not be so clear-cut.

But I'm not sure why we get hung up on parental filtering per se.  My
worries are about botnet C&C and data exfiltration, and that's an issue
that applies to every network, with or without kids, and probably more to
businesses and governments than to families.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 11:31:04 -0700

> Well you say Totalitarian Dictator, bu usually my children call me dad :)

The thing is, your DNS policy won't actually work. It's security theater.

You'd really want a feature along the lines of

That way, the policy still applies if they use a cellular connection, or
the neighbor's wifi, or whatever.

thanks,
Rob

>> That permits your guests to know of your network policy and to abide by
>> it if they choose; presumably you would not provide network access if they
>> chose not to.
>>
>
>

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 17 Jul 2019 12:34:09 -0600

each> But I'm not sure why we get hung up on parental filtering per se.
each> My worries are about botnet C&C and data exfiltration, and that's
each> an issue that applies to every network, with or without kids, and
each> probably more to businesses and governments than to families.

Indeed. We seem to be spinning. Can we agree that:

  - there are multiple use cases where end users (or their employer)
    want to have and control DNS filtering
  - some of these use cases are not enterprises with an IT
    infrastructure that can do things like group policy, control of user
    apps, etc.

If that's the case, we either need solutions or verbage explaining how
close to this we can get and what won't be technically possible.

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 17 Jul 2019 12:37:13 -0600

sayrer> The thing is, your DNS policy won't actually work. It's security
sayrer> theater.

No. It's not. It's not 100% effective for all forms of badness but that
doesn't make it security theatre.

sayrer> You'd really want a feature along the lines of

sayrer> [[https://www.apple.com/families/]]

And I could call this security theatre if I'm not an apple owner but I
won't because that isn't true either. But it's also not effective for
everyone.

I would think our goal here is to make security tools that help enough
people to be worth doing and realize that security in depth and with
multiple techniques and use cases is as good as we can do right now.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 17 Jul 2019 11:40:34 -0700

On Wed, Jul 17, 2019 at 8:58 AM Ted Hardie <[email-masked]> wrote:

>> people as already stated on this thread), provided by my network operator
>> (but it doesn’t have to be - I used to use OpenDNS for example, and I have
>> the capability to run my own resolver if I so desired).. I have malware
So, as far as I can tell, there are some minor problems with the DoH
deployment scheme proposed by various vendors (on the client in an
"applications doing DNS" manner), which this draft is fundamentally unable
to overcome.

This draft would probably work just as well, with a bit of work, and
without those fundamental issues, for DoT.

The root of the problem is visible in "if they chose not to". The nature of
DoH, is that the network operator (regardless of who they are) is unable
either detect or prevent guests (or users or BYOD or whoever) from not
complying with your network policy.

In the current unencrypted DNS world, in some specific environments
(enterprise, etc), non-compliance is enforced at a port/protocol level
(ACLs denying port 53).

A similar model that enabled both discovery and enforcement, and if
appropriate bypass of enforcements, would look roughly like:
client -> obtain policy -> (comply with visibility into compliance by
network, e.g. via DoT port/protocol) | (no-comply with visibility and
blocking -> obtain explicit information about risks and informed consent
from user -> violate/bypass e.g. via DoH)

When only DoH is used, if there is no informed consent, this short circuits
completely to client-> obtain policy -> comply or no-comply.

This breaks all of the existing detection and enforcement for network-level
tools applicable to DNS-based systems.

Given that DoT provides everything that DoH provides, from a privacy
perspective, so long as DoT isn't blocked and/or so long as any existing
DNS resolver(s) have an upgrade to DoT, and so long as relevant clients
(system or application) have the corresponding upgrade for DoT, I don't
understand the non-use of DoT.

Reminder: DoT clients have to build wire-format DNS queries, and then send
them over TLS sessions. DoH clients haveh to build wire-format DNS queries,
encode them, add HTTP headers, and send them over TLS sessions. DoH
ALREADY, by definition, has all the necessary code paths to build the
wire-format DNS queries required by DoT. Adding DoT to a resolver involves
duplicating the DoH bits, and then removing the HTTP-handling bits, i.e.
almost entirely removing code.

I think the fundamental asymmetry, where the guest can know the network's
policy but the network cannot detect or enforce its own policy, is easy to
see and understand.

And, I think the issue where this asymmetry is fundamental to DoH, but is
not an attribute of DoT, is also clear to anyone who looks.

This is why many of us are advocating for replacing DoH with DoT.

The harm that DoH does in an intractable fashion, far outweighs (by many
orders of magnitude) the benefits to an admittedly important set of users
and use cases.

I may have said it before, but I think it bears repeating: the DoH
bypassing of network policy, SHOULD be restricted via several important
safeguards (in widely distributed software systems): Disable DoH by
default; restrict enabling DoH to admin-level accounts; restrict DoH usage
to certain modes (e.g. incognito or equivalent); restrict DoH usage to the
lifespan of a browser tab; restrict DoH usage/enabling via "informed
consent" that may be very complex to implement, but which is nonetheless
needed to ensure users are informed about their specific, concrete, literal
risks (e.g. company policy violations, geopolitical environments, operator
terms/conditions, etc.).

Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 11:42:57 -0700

>     want to have and control DNS filtering

Yes, they can install whatever software they want.

>     infrastructure that can do things like group policy, control of user

No. That's just a downgrade attack. No different than a clipper chip.

thanks,
Rob

---

From: Alec Muffett <[email-masked]>
Date: Wed, 17 Jul 2019 19:44:36 +0100

> analysis might not be so clear-cut.

That's true, fair point.

Would you care to run some numbers, or shall I?

> businesses and governments than to families.

That's okay; the botnets are all innovating in the network space and will
gradually bother less with / be impeded by, with censorable men in the
middle such as DNS.

The new hotness in malware C2 is rendezvous communications over existing[1]
social network channels, such as pop-star Instagram comments — not to
mention old workhorses like Tor, or even raw (horrors!) IP addresses.

Albeit there _have_ been some botnets which have been stopped by _creating_
a domain name, and then reinvigorated[2] when that domain name was blocked.

This is not an absolute statement; I freely admit that some malware C2 will
be stopped by DNS filters; but it is increasingly less relevant because DNS
bypass for C2 is a profitable evolutionary niche; so it is human beings who
will benefit from - or will suffer - DNS filters most of all.

[1]
https://www.businessinsider.com/russian-hackers-turla-communicate-malware-britney-spears-instagram-comment-2017-6

[2]
https://www.theguardian.com/technology/2017/may/13/accidental-hero-finds-kill-switch-to-stop-spread-of-ransomware-cyber-attack

Glossary: C2 = "command and control"

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 17 Jul 2019 12:49:33 -0600

ebersman> - some of these use cases are not enterprises with an IT
ebersman>   infrastructure that can do things like group policy, control
ebersman>   of user

sayrer> No. That's just a downgrade attack. No different than a clipper
sayrer> chip.

If a home or small business isn't setting up a firefox or AD group
policy to control browsers on their network, that's a downgrade attack? 
An attack on what? Their network? By whom?

Expain. This makes zero sense.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Jul 2019 11:56:02 -0700

On Wed, Jul 17, 2019 at 11:40 AM Brian Dickson <
[email-masked]> wrote:

>
> The root of the problem is visible in "if they chose not to". The nature
> of DoH, is that the network operator (regardless of who they are) is unable
I disagree.  It forces the existence of the network policy to be visible,
but it is entirely possible to deny network access to a system which is
non-compliant.  It is not as simple as blocking or intercepting all port 53
traffic, but that method never addressed the reality that cleartext traffic
on that port was available to an observer.  To get both confidentiality and
policy enforcement via this means, practice will need to change.  It will
need to be visible to the system consuming the DNS (be it a browser, an OS,
or some other application), and the enforcement mechanism will have to be
better integrated into reachability mechanics.  That is definitely new code
for most people, but it is not impossible.

regards,

Ted Hardie

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 12:17:25 -0700

>> complying with your network policy.
So, I thought we were designing the Internet here. There's no network
policy. People are perfectly welcome to have a policy for their house or
their company, but the IETF is not required to design for that purpose.

It doesn't make sense to call it "BYOD", use the word "policy", and insist
on insecure traffic.

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Wed, 17 Jul 2019 12:46:36 -0700

> for most people, but it is not impossible.

So, I'd like to use a fairly simple existence proof (i.e. demonstrate a
proof-of-concept model that would scale and work) on re-implementing the
port-53 model, using DoT.

Client attempts to contact random DoT server. Network monitoring systems
see new DoT traffic between new pair of hosts (on port 853), alerts if not
blocked, or perhaps the network already blocks such random connections on
port 853 (check.)
Client attempts to contact well-known DoT server (e.g. Quad9, CloudFlare,
Google, or similar). Network policy permits this (check). Or, network
policy does not permit this (check).
Client attempts to contact local DoT server (e.g. server on IP handed out
by DHCP or equivalent, or locally configured). Network policy permits this
(check). Network surveillance of DNS queries performed on local DoT server
(check).
Client attempts to contact random DNS/53 server. (Either allowed or denied,
i.e. same as today, including monitoring elements if allowed). No change
(check).
Yes, network surveillance of DNS queries on DoT requires operation of a DoT
server to facilitate that.
Use of DoT, exclusively, allows the enforcement of that policy at a network
level (ACLs with respect to port 853). The end result is a network policy
of, "use our DNS service, or none at all, or don't use our network".

None of the above *requires* host-level changes. The above certainly plays
nice with any host-level augmentations on other explicit ways of publishing
and consuming policy.

I don't see any way of achieving the same policy enforcement result,
without implementing strict host-level validation mechanisms, which is a
change over the DoT-only scheme above.

In the DoT world, the policy is inherently visible. If you try to use a
particular DoT provider, you know immediately whether that is possible or
not.

The issue of whether a particular DoT server is or is not providing a
certain level of privacy, is perhaps something that could be signaled, but
I don't see any way of validating that signaling beyond, at best, some kind
of contractual enforcement.
I.e. if you want to be sure the party you are talking to is or is not doing
what they say they are doing, pretty much the only way to be sure requires
the involvement of law enforcement and/or lawyers.

The difference between DoT and DoH are whether host-level mechanisms are
required, to achieve any meaningful assessment of compliance.
Host-level compromise defeats host-level mechanisms, so other than secure
ways of proving host non-compromise (like TPM things), it is provably less
secure than adding network-based detection/enforcement.

(None of the above applies to malware that does its own communication to
C&C systems, but it does apply to malware that leverages browser-based DoH
capabilities to make use of DNS for any of C&C, exfiltration, payload
acquisition, etc.)

Brian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Jul 2019 13:48:38 -0700

Hi Brian,

Some comments in-line.

> blocked, or perhaps the network already blocks such random connections on

If blocked, the client is dead in the water without an application or host
configuration change.

> policy does not permit this (check).

If blocked, the client is dead in the water without an application or host
configuration change, as above.

> (check). Network surveillance of DNS queries performed on local DoT server

Note that the client is not aware in this scenario of whether the local DOT
server is or is not blocking traffic, observing traffic, or anything else.
Your premise is apparently that by agreeing to use the local resolver they
have agreed to whatever is being done.  In fact, there are existing
scenarios (coffee shop with a portal page being the most prominent) where
the local system will permit specific names to go to the local resolver to
solicit those pages, but will forbid anything else.  So some more subtle
scenarios already exist.

> Client attempts to contact random DNS/53 server. (Either allowed or
> denied, i.e. same as today, including monitoring elements if allowed). No
> change (check).
>

And subject to observation or interference by on-path attackers, as has
been discussed.

> server to facilitate that.

If you run a local DoH service and the client attaches to it, the
situations are parallel.

> Use of DoT, exclusively, allows the enforcement of that policy at a
> network level (ACLs with respect to port 853). The end result is a network
> policy of, "use our DNS service, or none at all, or don't use our network".
>
> If you mean "only DoT allows this", then I continue to disagree.  If you
mean that only using DoT within this context allows this, I agree.

> None of the above *requires* host-level changes. The above certainly
> plays nice with any host-level augmentations on other explicit ways of
> publishing and consuming policy.
>
The theory that would go with this draft runs something like this:

* put up a signal that hosts and applications can check to see if non-local
DNS is permitted (and possibly, provide data on where the local secure DNS
resolver is, if provided).

* link the dns resolver to the reachability management system (e.g. a
firewall) and permit traffic to exit the network only to destinations which
have been resolved via the local DNS and which have passed whatever checks
you have instituted.

A non-compliant visitor will then only be able to reach destinations which
have already been whitelisted by previous resolutions; that means that they
likely will be able to reach various CDNs, popular services, and so on, but
won't be able to reach random hosts that have not already been vetted by
the checks you instituted.

Is this new code?  Absolutely.  But it is not a host-level change, and it
permits more without host re-configuration than the pure blocking mechanism
you outlined.*

> particular DoT provider, you know immediately whether that is possible or
It cannot distinguish between this policy imposition, a reachability
failure, and a service failure.  As a signal, it is pretty ambiguous.

> I.e. if you want to be sure the party you are talking to is or is not
> doing what they say they are doing, pretty much the only way to be sure
> requires the involvement of law enforcement and/or lawyers.
>
I'm afraid I must continue to disagree with your premise.  I have no issue
at all with increased deployments of DoT, but I do not agree that this
rules out the use of DoH.

regards,

Ted

*For those that outsource this, it may also require a new service that
allows the topology decisions and the resolution services to be linked.
There are several ways to accomplish this by using remote configuration, by
taking traffic out of the network to a service provider quarantine via VPN,
or by some combination of the two.  Again, this is new.  But it is not
impossible, as very similar systems have been built by organization which
centralize these operations; it requires that these be made available to
new customers.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 17 Jul 2019 23:35:26 +0200 (CEST)

Il 17 luglio 2019 17:25 Ted Hardie <[email-masked]> ha scritto:

The IETF was not building these protocols to stop the use of the DNS as a policy enforcement mechanism and it is entirely possible to integrate them into a system which does this by offering the policy enforcing resolver over one of these confidential protocols.

I agree on the second part of your sentence, but I do not fully agree on the first one. In late 2017, several people - including one author of RFC 8484 and one member of the IAB - went on record saying that DoH was being developed exactly to stop the use of DNS as a policy enforcement mechanism. See for example the "DOH" section in this article:

https://blog.apnic.net/2017/12/12/internet-protocols-changing/

Of course these were not statements made on behalf of "the IETF", nor they represent the objectives of everyone who took part in the work, yet the fact that the whole organization got DoH standardized so quickly is hard to interpret differently than a sign of support both for the technology and for its explicit purpose above.

Now, arguing over this is not very useful, but I wanted to show that the concerns over the IETF's past approach to this matter have some reasons, even if I concede that most issues derive from deployment choices and not from the standard in itself. But if the people making the deployment choices are the same people that wrote and approved the standard, drawing a line is almost impossible.

Yes, and this is why I was actually defending the spirit of the draft against claims that it would just facilitate downgrade attacks. I think this draft is a step forward, and in general Mozilla appear to be much more receptive to the concerns than they were months ago, and this goes to their merit. I see progress in this discussion and I am happy to continue it.

--

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 14:42:05 -0700

On Wed, Jul 17, 2019 at 2:35 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> Yes, and this is why I was actually defending the spirit of the draft
> against claims that it would just facilitate downgrade attacks.
>

Isn't that exactly what it does? It turns off DoH over clear text, and thus
doesn't comply with BCP 61 or BCP 188.

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 17 Jul 2019 23:54:04 +0200 (CEST)

Il 17 luglio 2019 19:28 Alec Muffett <[email-masked]> ha scritto:

...and there's the rub; of the two/more problem spaces, I see more implementation opportunities in parental benificient oversight, than for escape to a free web for oppressed peoples.

Put differently: you are a parent or guardian and you care for a small population of children. Dictators oppress thousands to millions. A utilitarian approach suggests that the latter are more important to enable, than would be the cost of mildly inconveniencing or requiring the former to change their protective approach.

Can I just ask you whether you really think that DoH makes a real difference to the proverbial dissident under a dictatorship? If I were one, I'd already be using stuff like Tor and VPNs. Encrypting the DNS query is nice, but if then there are packets going from my computer straight to the forbidden destination, it's also not very useful - and if there aren't, then I am possibly already using technologies that could transport my DNS queries securely as well.

I think that DoH is much more of value for people that do not need to hide their traces completely, but just don't want their DNS traffic tracked and monetized.

Also, this idea that the Internet will export democracy by providing "escape to a free web for oppressed peoples" is... so 90's. In most countries that have been mentioned as examples of dictatorships throughout this discussion, most people are actually quite happy about their regime and often even happy not to live in a Western democracy (though that's partly because of propaganda, but often it is also because of different cultural values). It takes much more to subvert an authoritarian system than the ability to connect to some websites. It's still worth providing people in these countries with additional protections, but the depiction of a sad, oppressed world that is just waiting for DoH to bloom into democracy is a bit too much :-)

--

---

From: Brian Dickson <[email-masked]>
Date: Wed, 17 Jul 2019 14:59:47 -0700

On Wed, Jul 17, 2019 at 1:49 PM Ted Hardie <[email-masked]> wrote:

>>>> The root of the problem is visible in "if they chose not to". The
>>>> nature of DoH, is that the network operator (regardless of who they are) is
>>>> unable either detect or prevent guests (or users or BYOD or whoever) from
>>>> not complying with your network policy.
>>>>
>>>>
>>> I disagree.  It forces the existence of the network policy to be
>>> visible, but it is entirely possible to deny network access to a system
>>> which is non-compliant.  It is not as simple as blocking or intercepting
>>> all port 53 traffic, but that method never addressed the reality that
>>> cleartext traffic on that port was available to an observer.  To get both
>>> confidentiality and policy enforcement via this means, practice will need
>>> to change.  It will need to be visible to the system consuming the DNS (be
>>> it a browser, an OS, or some other application), and the enforcement
>>> mechanism will have to be better integrated into reachability mechanics.
>>> That is definitely new code for most people, but it is not impossible.
>>>
>>

The "dead in the water" mode presumes a specific deployment model on both
the operator of DNS services, and on the implementer of the client.

Even the current "beta" deployments of DoH have configurations for
"fall-back" to other choices of protocol and/or server.

The "dead in the water" issue can very easily be handled via an
informational or BCP RFC, on how to deploy and/or migrate to DoT.

This very much looks like the deployment of IPv6, including the "happy
eyeballs" stuff.

> Note that the client is not aware in this scenario of whether the local
> DOT server is or is not blocking traffic, observing traffic, or anything
> else.  Your premise is apparently that by agreeing to use the local
> resolver they have agreed to whatever is being done.  In fact, there are
> existing scenarios (coffee shop with a portal page being the most
> prominent) where the local system will permit specific names to go to the
> local resolver to solicit those pages, but will forbid anything else.  So
> some more subtle scenarios already exist.
>
>
> Yes, network surveillance of DNS queries on DoT requires operation of a
>> DoT server to facilitate that.
>>
>

I don't understand how you can disagree on this.

Compare two scenarios:
- client connects (or attempts to connect) to a random DoT server (on port
853).
- client connects (or attempts to connect) to a random DoH server (on port
443 at a specified URL).

Since DoT uses 853 exclusively, detecting and blocking are possible (and I
assert, trivial).

How would either detection or prevention of *just* DoH be possible, as
distinct from random HTTPS traffic?
There are plenty of scenarios where a random host standing up a DoH service
(e.g. on a shared hosting site via any feasible attack vector) becomes an
undetectable DNS vector (for anything value of "bad").

This is the poster child case, IMHO.

> * put up a signal that hosts and applications can check to see if
> non-local DNS is permitted (and possibly, provide data on where the local
> secure DNS resolver is, if provided).
>

I would go further, and suggest some comments:

   - A lot of the perceived demand for DoX is in fact demand for public
   resolver availability, to handle the problem of "hotel/cafe DNS
   shenanigans".
   - Many of the common issues between "shenanigans" and DoX usage, would
   benefit from client-side DNSSEC validation.

In particular, the behavior of DNSSEC validation failure (returning
SERVFAIL) works well with the use of multiple resolver and protocol "lists"
(hierarchical structures).
E.g. try local port 53 server obtained by DHCP, with (one or more) DoT
server(s) (regardless of DoT server choice(s)) as a more-secure fall-back.
If DNSSEC is not available, fall back to something better.
If DNSSEC is available, validate.
Upon validation failures (including rewritten NXDOMAIN), fall back to
something better.
Performance on valid responses may be faster.
As long as some resolver answers with DNSSEC-valid responses, correct
responses are guaranteed.

For privacy-first, reverse the order of fallback, trying DoT first.
Possibly fail hard if no DoT answers are available.

> failure, and a service failure.  As a signal, it is pretty ambiguous.

I agree. By itself it is insufficient. I am not proposing *not* doing some
kind of publication of policy. I am proposing doing so via DoT, and
preferably also with DNSSEC client validation.

And perhaps DANE needs to be included in the discussion, particularly on
the secure bootstrap process.
(For DANE to work, you need DNSSEC, but you don't need privacy, and you
don't need any CAs. You need names, and signed zones for those names, and
TLSA records, but that's reasonably straightforward, IMHO.)

Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 15:00:44 -0700

On Wed, Jul 17, 2019 at 2:54 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> most people are actually quite happy about their regime and often even
> happy not to live in a Western democracy
>

Oh, interesting assertion.

It doesn't seem relevant, though. It's not like DoH will prevent or enable
oppression from a government.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2019 23:13:01 +0100

On 17/07/2019 22:54, Vittorio Bertola wrote:
> Also, this idea that the Internet will export democracy by providing "escape to 
> a free web for oppressed peoples" is... so 90's. In most countries that have 
> been mentioned as examples of dictatorships throughout this discussion, most 
> people are actually quite happy about their regime and often even happy not to 
> live in a Western democracy (though that's partly because of propaganda, but 
> often it is also because of different cultural values). It takes much more to 
> subvert an authoritarian system than the ability to connect to some websites. 
> It's still worth providing people in these countries with additional 
> protections, but the depiction of a sad, oppressed world that is just waiting 
> for DoH to bloom into democracy is a bit too much :-)

I don't think I've seen such a spectacularly off-topic
(frankly inappropriate) strawman proposed in many a year.
That's just not an argument for an IETF list IMO.

S.

---

From: Alec Muffett <[email-masked]>
Date: Thu, 18 Jul 2019 01:00:51 +0100

On Wed, 17 Jul 2019 at 22:54, Vittorio Bertola <
[email-masked]> wrote:

>
> Can I just ask you whether you really think that DoH makes a real
> difference to the proverbial dissident under a dictatorship?
>

Since this is a personal question, I shall answer in the first person.

Yes I do, because my 25+ years experience of trying to get people to use
advanced security tools — Signal, Tor, Briar, SSH, PGP — has led me to the
conclusion that although such tools have their place, the world is best
served by maximising the {privacy, tamperproofness, blocking-resistance}
which is available as-default to the absolute maximum number of people.

This perspective led, in part, why I was chosen as the lead engineer for
adding end-to-end encryption to Facebook Messenger:

https://www.wired.co.uk/article/messenger-secret-messages-end-to-end-encryption

...and in the process of which I had to defend the creation of the same
against the counterarguments made by proponents of the
monitoring-and-safety viewpoint:

https://parentzone.org.uk/secret-conversations-everything-you-need-know-about-facebooks-new-feature

If I were one, I'd already be using stuff like Tor and VPNs.

I am familiar with that perspective; to venture off-topic for a moment,
there is in the United Kingdom some legislation arriving, soon, which will
require everyone to verify that they are over 18 before viewing pornography:

https://www.openrightsgroup.org/campaigns/digital-economy-bill-hub/age-verification/

This regulation requires the collection of data which did not need to be
collected before, and ties it to real-world identities; unsurprisingly the
"geek" world falls into two camps, those who say "People should just use
Tor and VPNs" — which is true, but unhelpful at scale and which brings its
own risks of complicit VPN providers, etc — but also there are erudite
essays such as this one, extract:

https://www.girlonthenet.com/2016/10/17/get-round-a-porn-block/

*Do you know how to get round a porn block? If your immediate thought here
> involved something like a VPN or Tor, then congratulations: it sounds like
> should your government implement a porn block you’ll have a reasonable idea
> how to circumvent it. However, can I ask that you please please please stop
> telling me on Twitter that you how to get around a porn block? Allow me to
> explain why.*

...which goes on to explore the theme more usefully than I can in this
email.

Also, I can strongly recommend that you invest a few days of your life
attempting to lecture/teach "security tools" to actual dissidents, or even
just members of the public; to do so is a life-changing experience.

I can recommend "CryptoParties" as a starter in this space:
https://www.cryptoparty.in

> Encrypting the DNS query is nice, but if then there are packets going from
> my computer straight to the forbidden destination, it's also not very
> useful - and if there aren't, then I am possibly already using technologies
> that could transport my DNS queries securely as well.
>

Indeed - I am a (possibly the only?) proponent of DNS-over-HTTPS-over-Onion:

https://github.com/alecmuffett/test-dns-https-onion

...but I am not foolish enough to believe that that will ever benefit more
than a few thousand / tens-of-thousands of people, once implemented.

Whereas in my previous job I literally enabled secure communications for
more than 1 billion people — if they so choose, and I am not convinced that
enough of them chose.

Hence why I welcome seeing Facebook embrace E2E more broadly (
https://www.theverge.com/2019/1/25/18197222/facebook-messenger-instagram-end-to-end-encryption-feature-zuckerberg)
and also why I believe that DOH-BY-DEFAULT-ON-FIREFOX-AND-CHROME is the
only useful route forwards towards adoption and impact.

I think that DoH is much more of value for people that do not need to hide
> their traces completely, but just don't want their DNS traffic tracked and
> monetized.
>

Good security technology seeks to lift all boats:
https://medium.com/@alecmuffett/how-to-help-dissidents-with-technology-lift-all-boats-e6fcb72d0da1

Tor is good — I launched the Onion sites for both Facebook & the New York
Times — but it is not "at scale".

Firefox and Chrome, together, are "at scale" and present a tremendous
opportunity to "shift the needle" back towards
privacy-and-integrity-and-assurance-by-default.

Also, this idea that the Internet will export democracy by providing
> "escape to a free web for oppressed peoples" is... so 90's.
>

That's a strawman.  I am not trying to "export democracy".

I am, as Whitfield Diffie puts it, merely attempting to restore to people
the ability for people to have a private conversation, even with a foreign
webserver.

However, it has to be said that repressive regimes — and the safety-focused
— are communities both which have issues with that goal.

Alec Muffett
Formerly Facebook Security Infrastructure Engineering
Member: Board of Directors, Open Rights Group
Member: Cybersecurity Executive of the British Computer Society
Co-Author, RFC7686
Avid cyclist and chef
Have a good evening, everyone. Hugs.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 19:03:44 -0700

> (frankly inappropriate) strawman proposed in many a year.

I have seen many similar emails. It's basically part of dealing with the
IETF.

> That's just not an argument for an IETF list IMO.

 Unfortunately, it is.

thanks,
Rob

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 18 Jul 2019 09:13:15 +0200

Moin!

On 17 Jul 2019, at 20:56, Ted Hardie wrote:
>> nature
> visible,
Can you please explain how this could be done, and more precisely how 
this
draft would help in achieving that. If an application uses DoH
as resolution mechanism without telling the network this traffic can not
be distinguished from normal HTTPs traffic. So the only way to block 
this
is to block known endpoints, but that can be done with or without 
knowing
the policy.

So long
-Ralf
—--
Ralf Weber
Principal Architect, Carrier Division

Akamai Technologies GmbH
Parkring 20-22, 85748 Garching
phone: +49.89.9400.6174
mobile: +49.151.22659325

Geschäftsführer: David Matthew McDonald Aitken, Justyna Kalina 
Jankowska
Sitz der Gesellschaft: Garching
Amtsgericht München HRB 129886

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 22 Jul 2019 16:41:55 +0000

From: Add <[email-masked]> on behalf of Brian Dickson <[email-masked]>
> Many of the common issues between "shenanigans" and DoX usage, would benefit from client-side DNSSEC validation.
In particular, the behavior of DNSSEC validation failure (returning SERVFAIL) works well with the use of multiple resolver and protocol "lists" (hierarchical structures).
> I am proposing doing so via DoT, and preferably also with DNSSEC client validation..

[JL] It seems interesting to consider the question of whether a DoT or DoH resolver SHOULD or MUST also perform DNSSEC validation. As well, I wonder if many of the organizations that are currently working on deploying encrypted DNS or have already done so should also take steps to sign all of their key domains - because it certainly seems worthy goal is to achieve both channel and content security.