Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

From: Rob Sayre <[email-masked]>
Date: Sun, 14 Jul 2019 16:09:00 -0700

Paul Vixie wrote:
> dns content filtering can be triggered by response data also, and not
just by
> the dns request (which itself might not be the initial request.) in
common use
> by dns firewalls, for example those using DNS RPZ, policy might be
triggered
> by the iteration through an authoritative name server address, or an
> authoritative name server name, or by the response (answer) address, or
even
> by the stub client's IP address.

Was DNS intentionally designed to be insecure?

thanks,
Rob

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jul 2019 01:34:23 +0000

On Sunday, 14 July 2019 23:09:00 UTC Rob Sayre wrote:
> > ...

no. nor ip itself, or ncp which preceded it, or tcp, or udp, or icmp, or smtp, 
ot http. it was insecure because it evolved in a safe, germ free academic 
bubble. absolutely none of it was designed with billions of people in mind, or 
the full cross section of humanity which would include criminals and national 
intelligence services. the world of the internet in 2019 would have been seen 
as a total freak show by the community who deployed dns  in the 1980's.

nothing that can be abused won't be. you may or may not believe this; it's 
considered controversial, and there are arguments being had about it today.

but noone considered that now-controversial near-truism at all when the core 
internet protocols were first designed and implemented. the idea of abuse was 
considered novel in the 1990's when commercialization and privatization 
brought abuse into the internet world and burst the academic bubble. a lot of 
old timers blamed AOL and MSN and even Usenet for the problems, but in 
actuality, it's what humans _always_ do at scale. putting the full spectrum of 
human culture atop a technology platform designed for academic and 
professional culture should have been understood to be a recipe for disaster.

-- 
Paul

---

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

Thank you for the elegant response. BCP 61 describes this issue well, too.

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

DNS seems like it still operates in the clear, and that doesn't seem good.

thanks,
Rob

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jul 2019 01:59:28 +0000

> DNS seems like it still operates in the clear, and that doesn't seem good.

first we signed transactions with asymmetric keys -- SIG(0).

then we signed them with symmetric keys -- TSIG.

then we signed data with assymetric keys -- DNSSEC.

then we encrypted transactions with assymetric keys -- DoT.

the the web community caught wind of it and threw a molatov cocktail into our 
movie theater -- DoH.

changing DNS isn't quick or easy or cheap -- it's the trifecta of "fast, good, 
or cheap, choose two" and you have to say "i choose none of the above."

and DNS is nowhere near as simple as the web community wants to believe.

we could use a lot more help pushing DNSSEC and DoT, for end to end 
authenticity and hop by hop secrecy+authenticity. we've done the parts of 
these that weren't quick and the parts that weren't easy and the parts that 
weren't cheap as well as the parts that weren't and can't be good. what we 
need now is a unified deployment effort on these technologies. help?

-- 
Paul

---

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

> or cheap, choose two" and you have to say "i choose none of the above."

I'm surprised that you seem to view DoH as a problem. I mean, everyone knows
that TLS and IPSEC are compromised by determined attackers, but I didn't
know
it was a continued sore spot. If you have more to say, I would like to hear
it.

thanks,
Rob

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Jul 2019 08:58:50 -0400

> Was DNS intentionally designed to be insecure?

What’s your definition of “secure”?

DNS had clear design elements for availability. DNSSEC added integrity. Confidentiality wasn’t a design goal.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jul 2019 15:14:35 +0000

On Monday, 15 July 2019 02:17:04 UTC Rob Sayre wrote:
> that TLS and IPSEC are compromised by determined attackers, ...

if you know a way that modern TLS 1.3 can be compromised by MiTM, i'd like to 
know more. a lot of us are moving from MiTM to explicit outbound proxy with an 
internally trusted key in order to fulfill our corporate or regulatory 
obligations.

> but I didn't know

the introduction of the DoH RFC explains that this protocol is designed to 
prevent interference by on-path actors in dns operations. i am a committed, 
determined on-path interferer, both for parental controls at home and 
corporate controls at $dayjob. see https://dnsrpz.info/ for background, but 
note that i am not the first to do something like RPZ at wide scale, nor is 
RPZ the only known way to use network-level DNS to protect end users and apps.

i could go (and have gone) on at great length about the pratfalls of DoH, but 
instead i'll sum up by saying that DoH is designed to increase the costs of an 
activity i MUST pursue, and it ignorantly lumps together private networks like 
home or corporate, public networks like coffee shops or ISP's, and networks in 
authoritarian places like china and turkey. i despise this ignorance entirely.

see also: 

https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/a/d-id/1333088

my best imagined outcome is mozilla saying oops, DoT will be fine, we're 
taking DoH out. because internet communications has always relied on revocable 
cooperation, consisting both of the willingness to speak a protocol, and the 
willingness to permit it through gateways one operates. by deliberately 
denying network operators the ability to withhold permission, DoH is an attack 
on the cooperative substrate of the internet itself.

-- 
Paul

---

From: "Andrew M. Hettinger" <[email-masked]>
Date: Mon, 15 Jul 2019 11:54:14 -0500

"DNSOP" <[email-masked]> wrote on 07/14/2019 21:17:04:

> From: "Rob Sayre" <[email-masked]>
> To: "Paul Vixie" <[email-masked]>
> Cc: [email-masked]
> Date: 07/14/2019 21:17
> Subject: [External] Re: [DNSOP] Fwd: [Add] new draft: draft-grover-
> add-policy-detection-00
> Sent by: "DNSOP" <[email-masked]>
>
> the the web community caught wind of it and threw a molatov cocktailinto
our
know
> it was a continued sore spot. If you have more to say, I would like
> to hear it.
>
> thanks,
> Rob

I don't know how you could possibly be genuinely surprised by this. I've
been lurking on here for a year, and Paul's been railing on this the entire
time. As far as I can tell, his position has been the DoT strikes the right
balance between network management and security, while DoH abandons the
network management ability for no real gain in security.

Arguably there's actually a decrease in security over DoT as, rather then
your network provider being the one who knows what DNS lookups you're
doing, now some third party with whom you have no relationship. Let's be
clear, "some third party" is pronounced "Cloudflare." This isn't to bash on
Cloudflare, but everyone's DNS traffic going to ONE company? That's the
NSA's wet dream. Furthermore, it doesn't even achieve the goal; as Paul
points out, he's just going to require all TLS traffic go through his proxy
so he can do all the same DNS inspection/denial that he did before. Again,
decreased security.

Andrew Hettinger
http://Prominic.NET
Tel: 866.339.3169 (toll free) -or- 1.217.356.2888 x. 110 (int'l)
Fax: 866.372.3356 (toll free) -or- 1.217.356.3356            (int'l)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Jul 2019 11:18:15 -0600

On 7/15/19 10:54 AM, Andrew M. Hettinger wrote:

> Arguably there's actually a decrease in security over DoT as, rather
> then your network provider being the one who knows what DNS lookups
> you're doing, now some third party with whom you have no relationship.

You, as a lone user, have zero leverage with your network provider.
Firefox or Chome or Safari (etc.), as the user agent for millions of
people, can exercise more leverage and also enter into contractual
agreements with trusted recursive resolvers. That seems like a promising
avenue to explore.

> Let's be clear, "some third party" is pronounced "Cloudflare." This
> isn't to bash on Cloudflare, but everyone's DNS traffic going to ONE
> company? 

Mozilla's intent is to deploy a set of trusted recursive resolvers, as
Ekr explained back in March on the DoH list:

https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw

But these topics might be more appropriate for the ADD list...

Peter

---

From: "Andrew M. Hettinger" <[email-masked]>
Date: Mon, 15 Jul 2019 12:43:08 -0500

"DNSOP" <[email-masked]> wrote on 07/15/2019 12:18:15:

> From: "Peter Saint-Andre" <[email-masked]>
> To: "Andrew M. Hettinger" <[email-masked]>, "Rob Sayre"
> <[email-masked]>
> Cc: [email-masked], "Paul Vixie" <[email-masked]>, "DNSOP" <dnsop-
> [email-masked]>
> Date: 07/15/2019 12:18
> Subject: [External] Re: [DNSOP] Re: Fwd: [Add] new draft: draft-
> grover-add-policy-detection-00
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

I, as a lone user have even LESS leverage over Cloudflare, or the Mozilla
Foundation, to whom I am not even a customer. More disturbingly, the
Mozilla Foundation is a US corporation, subject to (gagged) FISA warrants.
Considering one of the biggest surveillors in the world is the US
government, surely you can see how maybe concentrating all the DNS traffic
into the hands of a single US corporation (the Mozilla Foundation) might
not be the greatest plan.

Andrew Hettinger
http://Prominic.NET | Skype: AndrewProminic
Tel: 866.339.3169 (toll free) -or- 1.217.356.2888 x. 110 (int'l)
Fax: 866.372.3356 (toll free) -or- 1.217.356.3356            (int'l)

---

From: Rob Sayre <[email-masked]>
Date: Mon, 15 Jul 2019 20:21:38 -0700

> You, as a lone user, have zero leverage with your network provider.

It doesn't look like Mozilla has much leverage here. I can just pay $10 or
something for a VPN.

> agreements with trusted recursive resolvers. That seems like a promising

Is it promising?

> Ekr explained back in March on the DoH list:

And also to supply a domain name that disables everything? That's what
the draft does, right?

thanks,
Rob

---

From: Andy Grover <[email-masked]>
Date: Mon, 15 Jul 2019 20:52:01 -0700

> And also to supply a domain name that disables everything? That's what

Although the draft talks about policy a lot, it is actually pure
"mechanism". The draft makes it possible for the user (or user agent) to
know something it did not know before: whether the local DNS resolver
implements a policy.

A user agent may decide to do different things with that piece of
additional knowledge, but without the knowledge there's no opportunity
for a decision to be made. That's not saying everything's going to get
turned off, but everything always turned on isn't ideal either.

To speak more concretely, right now some existing filtering DNS
providers have ways for users to know if things are working as desired.
OpenDNS has internetbadguys.com for examplle, and other providers have
similar. These are useful, but would be more broadly useful if they
weren't provider-specific. That's basically all this draft is proposing
-- defining one canary domain to check instead of one for each provider.

-- Andy

---

From: Rob Sayre <[email-masked]>
Date: Mon, 15 Jul 2019 20:53:12 -0700

On Mon, Jul 15, 2019 at 8:14 AM Paul Vixie <[email-masked]> wrote:

> if you know a way that modern TLS 1.3 can be compromised by MiTM

I think some parties just ask for the certs, if they can't acquire them due
to negligence.

> , i'd like to
> corporate controls at $dayjob.
>

This response is disappointing to me, but I have to congratulate its
directness.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Mon, 15 Jul 2019 20:59:54 -0700

> -- defining one canary domain to check instead of one for each provider.

Isn't the issue that encrypted DNS might be served by popular providers?

So, if DNS and lots of the web are served by Azure or AWS or GCP, a
functioning
DoH protocol would make it hard to implement naive filtering.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 06:41:06 -0700

On Mon, Jul 15, 2019 at 8:53 PM Rob Sayre <[email-masked]> wrote:

> I think some parties just ask for the certs, if they can't acquire them
> due to negligence.
>

The certs are public information, so having the certs isn't useful. Can you
please be clearer about the attack you are describing?

-Ekr

---

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

On Tue, Jul 16, 2019 at 6:41 AM Eric Rescorla <[email-masked]> wrote:

>
>
> The certs are public information, so having the certs isn't useful. Can
> you please be clearer about the attack you are describing?
>

Sure, here's an article about it:
<
https://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/

Do you have any thoughts on that?

thanks,
Rob

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 16 Jul 2019 17:20:39 +0000

The link you shared indicates the problem is RC4, which was removed from TLS in 1.3 for this very reason. This doesn’t demonstrate TLS 1.3 is vulnerable; it demonstrates why adopting TLS 1.3 is so important.

Thanks,
Tommy
________________________________
From: DNSOP <[email-masked]> on behalf of Rob Sayre <[email-masked]>
Sent: Tuesday, July 16, 2019 8:46:42 AM
To: Eric Rescorla <[email-masked]>
Cc: dnsop WG <[email-masked]>; Paul Vixie <[email-masked]>
Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

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

The certs are public information, so having the certs isn't useful. Can you please be clearer about the attack you are describing?

Sure, here's an article about it:
<https://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.theregister.co.uk%2F2013%2F09%2F06%2Fnsa_cryptobreaking_bullrun_analysis%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C496a0b49339349ac921308d70a04e0de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636988888386522988&sdata=SbICd7%2FtkDlhh1zyusjw75CRgg6KHhbpzH0Efn%2BoBew%3D&reserved=0>>

thanks,
Rob

---

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

On Tue, Jul 16, 2019 at 10:20 AM Tommy Jensen <[email-masked]>
wrote:

> The link you shared indicates the problem is RC4, which was removed from
> TLS in 1.3 for this very reason. This doesn’t demonstrate TLS 1.3 is
> vulnerable; it demonstrates why adopting TLS 1.3 is so important.
>

Yeah, that's one part of it, but some of the other approaches described are
more general.

thanks,
Rob

>
> Thanks,
> Tommy
> ------------------------------
> *From:* DNSOP <[email-masked]> on behalf of Rob Sayre <
> [email-masked]>
> *Sent:* Tuesday, July 16, 2019 8:46:42 AM
> *To:* Eric Rescorla <[email-masked]>
> *Cc:* dnsop WG <[email-masked]>; Paul Vixie <[email-masked]>
> *Subject:* Re: [DNSOP] Fwd: [Add] new draft:
> draft-grover-add-policy-detection-00
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.theregister.co.uk%2F2013%2F09%2F06%2Fnsa_cryptobreaking_bullrun_analysis%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C496a0b49339349ac921308d70a04e0de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636988888386522988&sdata=SbICd7%2FtkDlhh1zyusjw75CRgg6KHhbpzH0Efn%2BoBew%3D&reserved=0>
> >
>

---

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

Hi Tommy,

I also noticed that your email client rewrote the link to "The Register", a
site that everyone knows, which then linked to NY Times, etc.

It used the domain "nam06.safelinks.protection.outlook.com". Why would that
domain be necessary if DNS-based security worked?

thanks,
Rob

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

> Yeah, that's one part of it, but some of the other approaches described
> are more general.
>
> thanks,
> Rob
>
>
>
>>
>> Thanks,
>> Tommy

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 17 Jul 2019 00:40:25 +0000

Some reasons I can think of off the top of my head:

  *   Because emails aren't always opened within the safety of corporate controlled networks (where DNS is controlled)
  *   Because security systems should always have fallbacks
  *   Because such a service can be sold to other companies who aren't otherwise interested in hosting their own DNS

I don't understand the point you're going for here, or how it relates to the draft in this thread's subject line.

Thanks,
Tommy
________________________________
From: Rob Sayre <[email-masked]>
Sent: Tuesday, July 16, 2019 5:10 PM
To: Tommy Jensen <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; dnsop WG <[email-masked]>; Paul Vixie <[email-masked]>
Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

Hi Tommy,

I also noticed that your email client rewrote the link to "The Register", a site that everyone knows, which then linked to NY Times, etc.

It used the domain "nam06.safelinks.protection.outlook.com<http://nam06.safelinks.protection.outlook.com>". Why would that domain be necessary if DNS-based security worked?

thanks,
Rob

On Tue, Jul 16, 2019 at 10:32 AM Rob Sayre <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 16, 2019 at 10:20 AM Tommy Jensen <[email-masked]<mailto:[email-masked]>> wrote:
The link you shared indicates the problem is RC4, which was removed from TLS in 1.3 for this very reason. This doesn’t demonstrate TLS 1.3 is vulnerable; it demonstrates why adopting TLS 1.3 is so important.

Yeah, that's one part of it, but some of the other approaches described are more general.

thanks,
Rob

Thanks,
Tommy
________________________________
From: DNSOP <[email-masked]<mailto:[email-masked]>> on behalf of Rob Sayre <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 16, 2019 8:46:42 AM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: dnsop WG <[email-masked]<mailto:[email-masked]>>; Paul Vixie <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

Sure, here's an article about it:
<https://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.theregister.co.uk%2F2013%2F09%2F06%2Fnsa_cryptobreaking_bullrun_analysis%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C51ca900221824198518208d70a4b34bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636989190436279112&sdata=5qVj7tNPQMSYuYKmPILW7Uws6JCtLXucxz3CbATL3Cs%3D&reserved=0>>

thanks,
Rob