Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request

From: Paul Ebersman <[email-masked]>
Date: Mon, 30 Sep 2019 11:12:01 -0600

ebersman> Expecting individual device users to be network admins and
ebersman> security experts is never going to scale. It's why real
ebersman> informed consent is so hard (if not a myth).

wjhns1> I actually think that it's more likely users will get their
wjhns1> policy bundled with some other software.  IE, they install an
wjhns1> anti-virus package and one of the things it does is configure
wjhns1> the local OS policy to request the anti-virus black list in
wjhns1> outgoing DNS requests.

I was thinking OS/network stack but sure. AV or similar shim in the
stack is close enough.

This also makes it more general purpose, since apps (including browsers)
would at least have the option of respecting the user's wishes and the
OS is in a better place to detect if some rogue app is trying to bypass
it.

wjhns1> Note that multiple TRR selections would already let users pick a
wjhns1> TRR with the right policy.  The point of my suggestion was to
wjhns1> try and stop tying part of the "trusted" with the "resolver" and
wjhns1> separate the functionality.

TRRs set by the browser vendor aren't real choice.

  "we have 3 ice cream flavors, hope you like liver, wood chips or soap
  flavors"

Now I have to vet every app (including browsers) and then vet all their
TRR choices. Again, doesn't scale, isn't a reasonable expectation of a
user.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Sep 2019 13:09:14 -0700

Will Hawkins <[email-masked]> writes:

> I agree with you both: users may not necessarily want to (or be able
> to) configure their resolver to use lists like this but the software
> that those users trust (e.g., AV software, as Mr. Hardaker said) may
> do so.

I could even see browser having a narrow selection of resolvers (because
it takes a *lot* of work to set up a globally viable resolving system),
and yet a significantly larger list of options for what filtering source
to use to marry with the resolution service (one of which, of course,
could be the default for the resolver) .

> In addition to offering this option as a way to point to filter lists,
> this option can be used to point to locations that will, in turn, set
> the filter lists? The benefit may be that the feature is easier for
> the end user to configure *and* the delegate organization can maintain
> an up-to-date list of filter lists on behalf of its users.

I'm not sure what you're describing, since my reading of the above is
that's exactly what the draft allows for: pointing at someone else's
list to maintain.
-- 
Wes Hardaker
USC/ISI

---

From: Eric Orth <[email-masked]>
Date: Mon, 30 Sep 2019 16:24:37 -0400

I don't think a filtering request like this makes sense completely
independently of the resolver selection because I assume most recursive
resolvers would never support such toggleable filtering.  If the user (or
some installed software acting on the user's behalf) decides that antivirus
filtering would be good, they can't just add an EDNS0 request and expect it
to happen.  They're going to have to first ensure all used resolvers
support it before requesting it.

That said, there are recursive resolvers out there that support
user-configurable behavior such as type of filtering.  The ones I know of
work based on setting configuration on the web with the provider and then
DNS requests are matched with either client IP or identifiers in DoH/DoT
domains/urls.  A proposal like this could be a good way to standardize such
ID-matching behavior or potentially move the configuration to client-side
if desired.  If enough recursive resolver providers are interested in such
a standard mechanism, it could make sense for applications or other stub
resolvers to implement support.

On Mon, Sep 30, 2019 at 12:27 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

>
>
> > Il 27 settembre 2019 23:12 Wes Hardaker <[email-masked]> ha
> scritto:
> >
> >
> > I spent some time trying to see what else we could do to better support
> > all parties in an ADD world.  I wrote up the following in an effort to
> > spur thinking in new directions.  You'll probably hate it :-)
> >
> >
> https://datatracker.ietf.org/doc/draft-hardaker-dprive-add-doh-dnsop-filter-request/
>
> Thanks for daring to do this :-)
>
> My feeling is also that standardization work in the field of expressing,
> communicating and implementing DNS filtering lists would help many use
> cases (by the way, there already is a de-facto standard for a good part of
> this, i.e. RPZ, so it should be part of the picture). However, we also know
> that some people here believe that DNS filtering is always wrong, even when
> requested by the user. We could still have a standard for those that want
> to use it, though.
>
> Also, you'd possibly need to flesh out a relatively complex architecture.
> For example, there are cases in which the compiler of the filtering list
> does not want to make it accessible to everyone, and there could be attacks
> based on forging/spoofing legitimate lists, so you would want to have
> authentication, channel security and access control.
>
> Then, there is the issue of which filters should be applied, which is a
> policy and regulatory one; resolver operators could honor the user's
> request for a given filter, but at the same time they might want to do
> their own malware filtering on top of it, or they might be required by law
> to block yet other stuff. So the communication of active filtering
> frameworks could go in both directions.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> [email-masked]
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Will Hawkins <[email-masked]>
Date: Mon, 30 Sep 2019 22:05:55 -0400

> that's exactly what the draft allows for: pointing at someone else's

Sorry for not being clear. What I was attempting to suggest was adding
support for pointing to a provider of lists of lists. That would allow
client C to direct their ISP to contact entity E who will, in turn,
provide a list of filter lists. This would allow a separation where

entity A has domain-specific knowledge about malware-hosting domains
entity B has subject-matter expertise in adware-hosting domains
...

and entity E offers a service to its clients to vet those providers
and choose the lists that offer a "complete" solution. It is hardly
reasonable to expect a single entity to be knowledgeable about all the
possible things to filter in the same way that, e.g., stock analysts
focus on a specific company or sector and different BL operators
generate different lists.

I hope that a) that makes sense and b) it's not something possible per
the proposed spec and c) I am not wasting everyone's time.

Thanks again for the thought-provoking proposal!

Will

---

From: "John Levine" <[email-masked]>
Date: 1 Oct 2019 13:54:26 -0400

In article <CAMOjQcGkW1NkceLg6Lj7oNB=[email-masked]> you write:
>-=-=-=-=-=-
>resolvers would never support such toggleable filtering. 

Agreed.  The filter rules seem like a half hearted version of RPZ,
which is already painful enough to configure, and it's hard to imagine
why a network operator would want to go to all that hassle.  If it
were me, I'd say you get what you get, and if you want something else,
use 8.8.8.8 or someone with the same taste in filtering you have.

Also, as has been noted once or twice before, a lot of DNS filtering
is policy based, and the provider has no interest in making it easy
to substitute someone else's policy for its own.

R's,
John

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Oct 2019 13:36:26 -0700

Will Hawkins <[email-masked]> writes:

> support for pointing to a provider of lists of lists.
> That would allow client C to direct their ISP to contact entity E who
> will, in turn, provide a list of filter lists. This would allow a
> separation where

Ahh..  thanks for the breakdown, and I understand your point now.

I considered a number of things, such as allowing a client to point to
two lists (the best of both worlds).  In the end, I didn't put it in
(not that it's a done or baked idea).  Your idea above could be similar,
and its a good point that either E could return A and B, or E could
actually do the aggregation themselves and return A|B directly.
-- 
Wes Hardaker
USC/ISI

---

From: Mat Ford <[email-masked]>
Date: Wed, 2 Oct 2019 08:13:00 +0000

Wes,

> On 27 Sep 2019, at 22:12, Wes Hardaker <[email-masked]> wrote:
> 
> 

Thanks for the thought-provoking proposal Wes. Is the expectation here that recursive resolvers would keep per-client state on which filter lists apply, and then check those filters against each query from the given client? Do we know that this can be done scalably and quickly? As a naiive non-implementer of recursive resolvers this sounds like a performance and scalability nightmare to me.

Mat

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Wed, 02 Oct 2019 12:31:05 +0000

Wes, on the same line as Vittorio, thank you for daring to put this proposition. It would actually fix many other things and this is really worth exploring further, this is encouraging.

Agreed that we still have a massive issue as to how users can operate on such capabilities but I think this is part of a much much bigger UX issue and Human Factor issue and we are not going to resolve that now.

Therefore your proposition is increasing the flexibility criteria of the potential future design. It is actually helping breaking the chicken and egg situation in which we are.

Keep doing

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday 30 September 2019 13:34, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:

> > Il 27 settembre 2019 23:12 Wes Hardaker [email-masked] ha scritto:
> My feeling is also that standardization work in the field of expressing, communicating and implementing DNS filtering lists would help many use cases (by the way, there already is a de-facto standard for a good part of this, i.e. RPZ, so it should be part of the picture). However, we also know that some people here believe that DNS filtering is always wrong, even when requested by the user. We could still have a standard for those that want to use it, though.
>
> Also, you'd possibly need to flesh out a relatively complex architecture. For example, there are cases in which the compiler of the filtering list does not want to make it accessible to everyone, and there could be attacks based on forging/spoofing legitimate lists, so you would want to have authentication, channel security and access control.
>
> Then, there is the issue of which filters should be applied, which is a policy and regulatory one; resolver operators could honor the user's request for a given filter, but at the same time they might want to do their own malware filtering on top of it, or they might be required by law to block yet other stuff. So the communication of active filtering frameworks could go in both directions.
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Add mailing list
> [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Oct 2019 14:53:21 -0700

Mat Ford <[email-masked]> writes:

> Thanks for the thought-provoking proposal Wes. Is the expectation here
> that recursive resolvers would keep per-client state on which filter
> lists apply, and then check those filters against each query from the
> given client? Do we know that this can be done scalably and quickly?
> As a naiive non-implementer of recursive resolvers this sounds like a
> performance and scalability nightmare to me.

There are certainly synchronization issues to work out, and as I
mentioned in another thread, RBL might be a better solution but requires
more at-the-time round trips.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Oct 2019 14:57:30 -0700

"John Levine" <[email-masked]> writes:

> If it were me, I'd say you get what you get, and if you want something
> else, use 8.8.8.8 or someone with the same taste in filtering you
> have.

And that's one option.  However, that forces resolvers to become good
filterers or filter experts to become good world-class resolvers.

> to substitute someone else's policy for its own.

That certainly may be true.  And certainly if there seems to be a market
for user-specified policies, but a resolver implementation says "nope,
our policy only", then that will be an interesting signal about their
intentions.

-- 
Wes Hardaker
USC/ISI

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 2 Oct 2019 20:01:51 -0400

Vittorio Bertola writes:
> However, we also know that some people here believe that DNS
> filtering is always wrong, even when requested by the user.

Any chance you remember enough about those messages to point to them
in the list archive?  It's such a remarkable position to take, the
"even when requested by the user" part, that I'm surprised I don't
remember them.

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 2 Oct 2019 20:14:27 -0400

Wes Hardaker writes:
> I actually think that it's more likely users will get their policy
> bundled with some other software.  IE, they install an anti-virus
> package and one of the things it does is configure the local OS policy
> to request the anti-virus black list in outgoing DNS requests.

What do you see as the difference vs the anti-virus software just
setting up the hooks for the device doing the filtering itself on the
DNS responses?  Sure, it can't see into an encrypted DNS request
stream from an application doing its own DNS, but it seems to me
(perhaps without enough vision, I realize) that how that's dealt with
is pretty much the same as determining whether those encrypting
applications are using the request-to-filter option with the external
resolver.

Basically I'm not really getting how pushing the implementation
requirement out to the external resolver improves things.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Oct 2019 16:17:03 -0700

> "even when requested by the user" part, that I'm surprised I don't

You're right that my statement was probably a bit extreme.  But taking
it up a bit higher, we know that the point of DoH is to bypass
filtering, rewriting, firewalling and snooping in general.  If we
weren't worried about firewalling, DoT would be sufficient.  If we
weren't worried about firewalling and snooping, DNSSEC would be
sufficient.

I think there is a high level of variation between what open resolvers
might filter, based on marketing needs, legal needs, etc.  In general, I
think the diversity is probably a good thing, but it does make it harder
for users to control.  If a resolver wants to optimize for speed, they
probably want to do less filtering.  If they want to offer filtering as
a service, they may not optimize for speed as much.

I doubt anyone, to correct my previous statement, is fully at either end
of that spectrum.  But it seems that there is a diverse set of opinions
about where the right spot on that spectrum is.  Two examples might
include google and opendns:

>From the google FAQ:

    Does Google Public DNS offer the ability to block or filter out
    unwanted sites?￼

    No. Google Public DNS is purely a DNS resolution and caching server;
    it does not perform any blocking or filtering of any kind, except
    that it may not resolve certain domains in extraordinary cases if we
    believe this is necessary to protect Google’s users from security
    threats. But we believe that blocking functionality is usually best
    performed by the client. If you are interested in enabling such
    functionality, you should consider installing a client-side
    application or browser add-on for this purpose.

OpenDNS is rather flexible and offers a 4 filtering options (I think) to
pick from for filtering, and more customization if you want it.

    OpenDNS solutions such as FamilyShield use preconfigured Web content
    filtering and blocking that is not adjustable. OpenDNS’s
    preconfigured solutions provide easy-to-implement protection for
    networks where manual configuration is not desired. To use a
    preconfigured OpenDNS solution, set your DNS parameters to the
    appropriate IP address.

But their priorities are clearly different, and studying things like
their speed or effectiveness at blocking what you don't like will
clearly get different results.  As an example of the speed differences,
I believe they have been studied extensively.  Here's a random
duck-duck-go search result:

https://hackernoon.com/dns-performance-comparison-google-quad9-opendns-norton-cleanbrowsing-and-yandex-d62d24e38f98

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Oct 2019 16:21:21 -0700

> > to request the anti-virus black list in outgoing DNS requests.

Your good question is below.  That being said, reminder that the point
of the draft was somewhat of a thought experiment...

> DNS responses?

I think there would some end-user complexity reduction in needing to
synchronize filtering, for example.  (Though users must do this now for
virus/malware detection of course).  I think that a resolver/filtering
combination would likely promote happier eyeballs as the filtering will
likely much more efficient generically and through the use of shared
response caching potentially.

-- 
Wes Hardaker
USC/ISI

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 4 Oct 2019 10:09:51 +0200 (CEST)

> Il 3 ottobre 2019 02:01 Dave Lawrence <[email-masked]> ha scritto:
>  
> Vittorio Bertola writes:

Sure: just go to Mozilla's presentation from the BoF in Montreal ( https://datatracker.ietf.org/meeting/105/materials/slides-105-add-dns-in-applications-one-applications-perspective-00.pdf ) where they say that DNS was a control surface but is not any more, and that "in the long term" DNS filtering won't work and "entities looking to exert control will have to engage with owners of endsystems". During the presentation they also made clear that their canary domain detection mechanism is a short-term fix to give people some time to adapt, and will go away in the future. Of course, if you act to change things so that DNS-as-a-control-surface will stop working, it won't be possible to provide filtering even when the user actually wants it.

But they are not the only ones with these views: I think Stephane Bortzmeyer shares them (but he can correct me if I'm wrong) and I received similar comments from a well-known digital rights coalition in Europe (not sure they are on this list though).

These are respectable views and I do see the risk that once DNS filtering is technically possible it can be used to violate human rights, which could be considered as a sufficient motivation for making it "tout court" illegal or technically impossible. I just think that it also has lots of positive uses and so it is better to continue using it under appropriate rules, much like more or less any other technology.

--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Oct 2019 08:30:13 -0700

On Fri, Oct 4, 2019 at 8:06 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> Sure: just go to Mozilla's presentation from the BoF in Montreal (
> https://datatracker.ietf.org/meeting/105/materials/slides-105-add-dns-in-applications-one-applications-perspective-00.pdf
> ) where they say that DNS was a control surface but is not any more, and
> that "in the long term" DNS filtering won't work and "entities looking to
> exert control will have to engage with owners of endsystems". During the
> presentation they also made clear that their canary domain detection
> mechanism is a short-term fix to give people some time to adapt, and will
> go away in the future. Of course, if you act to change things so that
> DNS-as-a-control-surface will stop working, it won't be possible to provide
> filtering even when the user actually wants it.
>

One of the problems with attempting to paraphrase people's views is
that you often don't do so accurately, and that seems to be the case
here.

Mozilla's position is not "that DNS filtering is always wrong, even
when requested by the user". Martin laid out our thinking in some
detail, but I'll try to summarize here.

1. In the long term, we do not believe that unilateral filtering by
network entities is viable. Without some engagement/consent by the
"owner of the endsystem" then filtering by parties which the owner
might perceive as legitimate is indistinguishable from attack.

2. If the owner of the endsystem consents, then DNS filtering is a
viable mechanism, though we don't think it's the best point to do
filtering at, in part because the granularity of filtering is quite
coarse (compare, for instance, Safe Browsing, which operates at a URL
prefix level). However, that seems like a reasonable set of
technological tradeoffs for people to make and Mozilla's TRR policies
explicitly state that "Resolvers may block or filter content with the
user’s explicit consent."

3. In the short term, we are aware that there is DNS filtering
(principally parental controls) which is performed with user consent
by non-TRR resolvers. To avoid breaking those environments, we have
implemented a set of mechanism (principally the canary) to attempt to
detect those cases and disable DoH. However, because this allows for
active downgrade attack, we do not consider the canary mechanism
viable in the long-term, and would expect to eventually require
some engagement with the endsystem to disable DoH.

-Ekr

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 04 Oct 2019 17:45:33 +0200

Moin!

> spur thinking in new directions.  You'll probably hate it :-)
Not sure I hate it. But having operated recursive services for large part
of my professional life it certainly doesn’t make me cheer. Let me give you
how I see that draft.

So I’m as an recursive resolver operator shall give some random guy on the
internet the power to define what I filter and I then have to filter this
probably different for different users.

I already thought of at least three attacks/denial of service scenarios
while writing this:
- App making browsing impossible by add . to the filter list
- Creating millions of different blocking scenarios
- Creating a huge list of blocked domains
two and three could also strike as a combination and might not be attacks
but normal usage instead.

I also have some experience in using DNS for blocking and other policy use
cases and I can tell you it is not uncommon for these list to be counted
gigabytes in memory, and now have lots of them and different ones for
different users is just something that will not fly or create huge complexity
in lookup chains.

DNS policy always has and has to be local. The resolver operator decides
what to do based on his use cases. Letting someone else decide that is
IMHO a bad idea.

So long
-Ralf
—--
Ralf Weber

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 4 Oct 2019 18:11:07 +0200 (CEST)

Il 4 ottobre 2019 17:30 Eric Rescorla <[email-masked]> ha scritto:

Of course you are authoritative for your own views, so thanks for clarifying them. So would it be more precise to say that in Mozilla's view DNS filtering is wrong when

a) it is done without the consent of the user, or

b) it is done with the consent of the user by non-TRR resolvers?

(a use case which, as you say in #3, you are allowing temporarily but will disable in the long term, with the suggestion that either those resolvers become TRRs or get their users to actively disable DoH once you turn it on by default)

Also, is "wrong" the wrong word? Both in #1 and #3, you seem to say that your problem with the two use cases is not that filtering is wrong, but that it is not viable securely. So, if we devised a way to do it securely, would you consider those use cases legitimate and support them in Firefox?

--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Oct 2019 17:46:48 -0700

> Of course you are authoritative for your own views, so thanks for
> clarifying them. So would it be more precise to say that in Mozilla's
> view DNS filtering is wrong when
>
> b) it is done with the consent of the user by non-TRR resolvers?  (a
> use case which, as you say in #3, you are allowing temporarily but
> will disable in the long term, with the suggestion that either those
> resolvers become TRRs or get their users to actively disable DoH once
> you turn it on by default)
>
> Also, is "wrong" the wrong word? Both in #1 and #3, you seem to say
> that your problem with the two use cases is not that filtering is
> wrong, but that it is not viable securely. So, if we devised a way to
> do it securely, would you consider those use cases legitimate and
> support them in Firefox?

As I said in my previous message, I don't think having you try to
paraphrase our views is really helping.

I think our position is reasonably clear, but just to sharpen one
point: we already do support these use cases by allowing endsystem
owners to configure any DNS resolver of their choice, whether it
is part of the TRR program or not, and we intend to continue that
policy.

-Ekr

On Fri, Oct 4, 2019 at 9:11 AM Vittorio Bertola <
[email-masked]> wrote:

> Of course you are authoritative for your own views, so thanks for
> clarifying them. So would it be more precise to say that in Mozilla's view
> DNS filtering is wrong when
> (a use case which, as you say in #3, you are allowing temporarily but will
> disable in the long term, with the suggestion that either those resolvers
> become TRRs or get their users to actively disable DoH once you turn it on
> by default)
>
> Also, is "wrong" the wrong word? Both in #1 and #3, you seem to say that
> your problem with the two use cases is not that filtering is wrong, but
> that it is not viable securely. So, if we devised a way to do it securely,
> would you consider those use cases legitimate and support them in Firefox?
>
> --
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 5 Oct 2019 09:06:42 -0700

On Oct 4, 2019, at 8:30 AM, Eric Rescorla <[email-masked]> wrote:
> If the owner of the endsystem consents, then DNS filtering is a
> prefix level).

I completely agree with your appeal to clarity, but that said I wanted to point out an assumption embedded here, which makes sense for Mozilla but does not make sense in general.   The assumption is that the thing doing the filtering will get to see the URL.

This assumption doesn’t hold for the use case most people have been talking about here: stopping connections to botnet C&C servers.

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 5 Oct 2019 19:41:35 +0200 (CEST)

I am trying to paraphrase and repeat your views because it is the only possible way to make sure that I understood them correctly, which is necessary to figure out constructive proposals for the future. (It is actually the recommended method for moderators, negotiators and journalists doing interviews.)

For example, as pointed out in my last paragraph above, I have not understood whether Mozilla objects to in-network, non-consensual filtering on a principle basis (i.e., it is ethically and architecturally wrong because it can also be used for censorship) or on a practical basis (i.e., you do not support it because you think it does not work in a secure way). If your position were the latter, we could imagine of working together at the IETF to find secure ways to do it, while if it were the former, trying to do that with you would be a waste of time for everyone.

--

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Oct 2019 20:57:11 -0700

On Sat, Oct 5, 2019 at 9:07 AM Ted Lemon <[email-masked]> wrote:

> I completely agree with your appeal to clarity, but that said I wanted to
> point out an assumption embedded here, which makes sense for Mozilla but
> does not make sense in general.   The assumption is that the thing doing
> the filtering will get to see the URL.
>
> This assumption doesn’t hold for the use case most people have been
> talking about here: stopping connections to botnet C&C servers.
>

Right. Our position is that DNS filtering is not a long-term viable
strategy for filtering when the endpoint wishing to do the resolution is
adversarial.

-Ekr

---

From: S Moonesamy <[email-masked]>
Date: Sun, 06 Oct 2019 12:13:38 -0700

Hi Ted,
At 09:06 AM 05-10-2019, Ted Lemon wrote:
>I completely agree with your appeal to clarity, but that said I 
>wanted to point out an assumption embedded here, which makes sense 
>for Mozilla but does not make sense in general.   The assumption is 
>that the thing doing the filtering will get to see the URL.
>
>This assumption doesn't hold for the use case most people have been 

The application attempting to access the URL is not necessarily a web 
browser.  It may be another application which depends on the system 
to provide the DNS resolution service.  The "safe browsing" does not 
provide any protection for such cases.

Regards,
S. Moonesamy

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Oct 2019 12:30:49 -0700

On Sun, Oct 6, 2019 at 12:06 PM Ted Lemon <[email-masked]> wrote:

> On Oct 5, 2019, at 22:57, Eric Rescorla <[email-masked]> wrote:
> Do you think there’s some better strategy, or do you just see this as
> impossible?

As everything moves to being encrypted, generally strategies based on
examining the plaintext of messages in the network will become less
effective. This is one such mechanism.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Sun, 6 Oct 2019 14:06:55 -0500

On Oct 5, 2019, at 22:57, Eric Rescorla <[email-masked]> wrote:
> Right. Our position is that DNS filtering is not a long-term viable strategy for filtering when the endpoint wishing to do the resolution is adversarial.

Do you think there’s some better strategy, or do you just see this as impossible?  From what I’ve seen, botnet mitigation is always an adaptive strategy, and information collection and pattern recognition are key. So sure, dns filtering is not going to work automatically. But it is an attack surface to use against botnets and is useful as part of a larger strategy.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 6 Oct 2019 14:29:26 -0700

On Oct 6, 2019, at 12:30 PM, Eric Rescorla <[email-masked]> wrote:
> As everything moves to being encrypted, generally strategies based on examining the plaintext of messages in the network will become less effective. This is one such mechanism.

This is not actually true, because at some point there is an endpoint that sees the cleartext, and if that endpoint isn’t controlled by the botnet, then there’s an opportunity to intervene.  Even if it is in the control of the botnet, if an intermediary is being used (as in the Obliviated DNS proposal that was recently mentioned here) traffic analysis can produce useful intelligence and that intelligence can be used to block connections.   Why do you think botnets bother to use DNS to find C&C controllers, even though DNS has been being used as a way to mitigate malware for years?   If they could do it some other way, wouldn’t they have done so?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Oct 2019 16:54:03 +0200

Ted Lemon <[email-masked]> wrote:
    > This is not actually true, because at some point there is an endpoint
    > that sees the cleartext, and if that endpoint isn’t controlled by the
    > botnet, then there’s an opportunity to intervene.  Even if it is in the
    > control of the botnet, if an intermediary is being used (as in the
    > Obliviated DNS proposal that was recently mentioned here) traffic
    > analysis can produce useful intelligence and that intelligence can be
    > used to block connections.   Why do you think botnets bother to use DNS
    > to find C&C controllers, even though DNS has been being used as a way
    > to mitigate malware for years?   If they could do it some other way,
    > wouldn’t they have done so?

My understanding is that there has been lots of malware that used embedded IP
addresses, but they are less succesful.  The layer of indirection that DNS
provides allows them to scale their C&C and make it resilient. (Surprise,
that's why the rest of us it...)

Using names also lets them travel through system configured HTTP proxies.
There are still many "enterprises" that have only HTTP alg-proxies as their
"firewall", and no default route, for instance.  In my experience, such
places tend to be very ripe pickings, because they are overconfident in their
"firewall" 

Apparently quite a number of bots also attempt to resolve a few canary
domains that should not resolve, and if they do return answers, assume that
they are being observed, and stop.  Quite a few botnets have been shutdown by
simply registering the canary domain!..  If only the botnet guys would use
DNSSEC instead.

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 07 Oct 2019 12:03:34 -0700

Eric Rescorla <[email-masked]> writes:

>     I completely agree with your appeal to clarity, but that said I wanted to point
>     out an assumption embedded here, which makes sense for Mozilla but does not make
>     sense in general.   The assumption is that the thing doing the filtering will get
>     to see the URL.
>    
>     This assumption doesn’t hold for the use case most people have been talking about
>     here: stopping connections to botnet C&C servers.
> 
> Right. Our position is that DNS filtering is not a long-term viable strategy for
> filtering when the endpoint wishing to do the resolution is
> adversarial.

Two things: 

1) I find it interesting that you care at all about filtering itself, as I
think Mozilla's primary desire is to offer privacy protected resolution
to a resolver that is trustable (which I support whole-heartedly), and
the usage of DoH is the best way to accomplish that (which I also thing
is a good thing, though I had doubts at first due to the overhead...
but the IMC paper proves its not as bad as I was fearing it would be).

But...  if a resolver safebrowsing.example.com came along, got
registered in the TRR list, Mozilla wouldn't object to that right?  Or
If a TRR actually supported user-configurable browsing "in some way"
(where "in some way" could be as proposed in my draft, eg).

IE, as long as resolvers state their intentions, they can filter or not
as they please to protect the end-user, and (as you've said) the end
user selects the one they want.

2) I suspect that some of the push-back comes from the (perfectly valid)
stance that "DNS filtering is not a long-term viable strategy" when it's
combined with (me:) "IP address based filtering died ages ago", and no
one is offering a replacement.  Thus, I think most would agree that
they'd prefer something different than DNS filtering, but (very sadly)
there is no better alternative at the moment.  If only a solution
existed that could be proposed at the same time as the loss of a
moderately-useful control point is removed for good reason.

-- 
Wes Hardaker
USC/ISI

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 8 Oct 2019 14:48:15 -0400

Ted Lemon writes:
> Why do you think botnets bother to use DNS to find C&C controllers,
> even though DNS has been being used as a way to mitigate malware for
> years?   If they could do it some other way, wouldn’t they have done so? 

Certainly one other way of interpreting this state of affairs is that
they still do because the mitigations haven't been effective enough.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2019 09:30:06 -0400

IoW dns filtering is not sufficiently effective at stopping botnet controller lookups compared to other alternatives?  What other alternatives?  This isn’t an interesting clarification unless there is something else botnets could be using but aren’t because dns is better.  AFAIK botnets have no useful alternative. 

> On Oct 9, 2019, at 03:37, Dave Lawrence <[email-masked]> wrote:
> 
> Ted Lemon writes:

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 Oct 2019 09:36:54 -0400

> they still do because the mitigations haven't been effective enough.

Another way of interpreting that statement is that perhaps the only botnets we know about are the ones that use DNS to find C&C controllers; it could well be that there are significant numbers of botnets that do it some other way that we can't see.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2019 10:25:19 -0400

> Another way of interpreting that statement is that perhaps the only botnets we know about are the ones that use DNS to find C&C controllers; it could well be that there are significant numbers of b…

True.   However, such botnets would have to be pretty smart to be able to hide effectively: they would have to avoid operating on hosts on research networks, so that their traffic isn’t seen by researchers.   I’m not sure how they’d do that, but it’s an interesting question to investigate (sort of off-topic for ADD, of course!).

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 Oct 2019 10:27:54 -0400

On 9 Oct 2019, at 10:25, Ted Lemon <[email-masked]> wrote:

> On Oct 9, 2019, at 9:36 AM, Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
> True.   However, such botnets would have to be pretty smart to be able to hide effectively: they would have to avoid operating on hosts on research networks, so that their traffic isn’t seen by researchers.

Perhaps they tunnel everything over HTTPS to Cloudflare, hiding in plain sight :-)

Joe

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2019 10:30:30 -0400

I think this could still be noticed. You’d need intelligence on the device noticing that there are surreptitious connections being made. 

> On Oct 9, 2019, at 10:27, Joe Abley <[email-masked]> wrote:
>

---

From: Barry Greene <[email-masked]>
Date: Wed, 9 Oct 2019 09:22:32 -0700

>> years?   If they could do it some other way, wouldn’t they have done so?

The reaction by the security community is the core reason miscreants moved to DNS and DGA. We (security operators in ISPs around the world), can RTBH a malware C&C in minutes. From 2002 - 2006 we were whack-a-mole C&Cs all over the world. BGP was our #1 security tool.

Then the miscreants shifted their C&C to DGAs and Fast-Flux. This is when using the DNS resolver as a security tool was dusted off and deployed. We then had some malware shift to IPv6 C&C (around 2009ish). The Netflow tools were not set up to spot this activity. Then those were addressed. Then we started seeing malware systems using Peer-to-Peer. Mitigations where were a combination of policy, DNS resolver filters, and BGP are used on those.

The problem I have with this discussion is people thinking they know what they are talking about when it comes to battling malware, botnets, and miscreant activities. We need all the tools in our battle against the miscreants. The miscreant problem is NOT going away with technology. It is a Internation Justice issue which is outside of the IETF’s function.

---

From: Barry Greene <[email-masked]>
Date: Wed, 9 Oct 2019 09:24:24 -0700

> On Oct 9, 2019, at 7:30 AM, Ted Lemon <[email-masked]> wrote:
> 

Device oriented security works on a limited set of devices. It is not on my Nest, Cameras, other IoT devices in the home.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2019 12:27:59 -0400

> Device oriented security works on a limited set of devices. It is not on my Nest, Cameras, other IoT devices in the home.

You misunderstand my point.   I mean that a security researcher with one of these devices in their lab should be able to notice miscreants.   E.g., why is my Nest camera connecting to that server in East Agulfia?   Nest isn’t in East Agulfia.   For constrained devices this isn’t even a challenge.   The problem with these devices is that at present in most cases no such constraints are applied to them.  Mud does a pretty good job of solving this problem.

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 Oct 2019 09:41:28 -0700

On Oct 9, 2019, at 12:27, Ted Lemon <[email-masked]> wrote:

Device oriented security works on a limited set of devices. It is not on my
Nest, Cameras, other IoT devices in the home.

You misunderstand my point.   I mean that a security researcher with one of
these devices in their lab should be able to notice miscreants.   E.g., why
is my Nest camera connecting to that server in East Agulfia?   Nest isn’t
in East Agulfia.

Nest is google. I assume Google is everywhere.

My example was CloudFlare. CloudFlare IIS potentially the connection point
for everybody, and they were turning up new nodes at a high frequency even
before their IPO. I assume that CloudFlare is everywhere.

You get my point, I'm sure. I agree this is a bit of a tangent.

Joe

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 9 Oct 2019 15:25:31 -0400

Ted Lemon writes:
>> years? If they could do it some other way, wouldn t they have done so? 

Barry Greene writes:
> The reaction by the security community is the core reason miscreants
> moved to DNS and DGA [...] Then the miscreants shifted their C&C to
> DGAs and Fast-Flux.

Right, going back to my original statement about malware using DNS,
"they still do because the mitigations haven't been effective enough,"
this was what I was driving at.  

I didn't say DNS controls were completely ineffective, but they've not
been enough of an obstacle for the malware to stop using DNS.  With
necessity being the mother of invention, malware authors haven't had
enough compelling reason to develop widespread workarounds to DNS
controls because they can still get along well enough in the current
environment with the good guys doing clear-text DNS filtering.  It's
not because of a lack of possibilities that aren't the DNS.  I'm sure
a non-trivial number of people on this list could come up with some
non-DNS methods pretty quickly.

---

From: Barry Greene <[email-masked]>
Date: Wed, 9 Oct 2019 12:59:52 -0700

> On Oct 9, 2019, at 9:27 AM, Ted Lemon <[email-masked]> wrote:
> 

I understand your point. Good malware systems test for sandbox, honeypots, and other “lab” work. This defeats the average security researcher. Of course, the volume of bad malware with easy detection is the majority - overwhelming the industry to be able to spot, build IOC, and get the word out to the filtering tools (which include DNS resolvers).

The problem I’m having with this whole discussion is the small group pushing for the community to “throw away the screwdriver from my toolbox … a hammer is just as effective to hammer in screws.” Battling the miscreant threat should be expanding the security toolbox, not limiting it.

Irony - we did all this work in IETF for IPFIX - with security as the core driver - to give us detailed visibility into what is happening on the network. There is a bigger “security threat” from IETF’s IPFIX than there is from some “hypothetical DNS wiretap” between the Stub Resolver and the resolver.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 16:06:33 -0400 (EDT)

On Wed, 9 Oct 2019, Barry Greene wrote:

> The problem I’m having with this whole discussion is the small group pushing for the community to “throw away
> the screwdriver from my toolbox … a hammer is just as effective to hammer in screws.” Battling the miscreant
> threat should be expanding the security toolbox, not limiting it. 

It's not a "tool" that is taken away from you. It's a leaking water
pipe. And you are arguing that you cannot see if the water is contaminated
anymore because the pipe got fixed.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 16:10:48 -0400 (EDT)

> non-DNS methods pretty quickly.

But even if you want to keep using DNS, write a browser plugin that
people can optin to that sits in the DNS resolving path in the browser.
Note that this means it is optin, per-user and no one will be forced
this tool as a censorship tool. This tool could use the existing RPZ
infrastructure (and cache too so the latency cost should be low)

There is no need for the network to keep leaking clear DNS. The
application has access to the plain DNS.

Paul

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 10 Oct 2019 14:51:27 +0200 (CEST)

> Il 9 ottobre 2019 22:06 Paul Wouters <[email-masked]> ha scritto:
> 

I don't think anyone has a problem with fixing the leaks from the pipe. The problem is that the plumber that showed up to fix the pipe is also adding another stretch of pipe to divert the water into someone else's tank.

--