Subject: [Add] meeting hum: should the IETF take up this work?

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 15:09:20 -0700

Hi,

The IETF shouldn't take up work in reaction to non-technical (aka "policy")
concerns about imminent deployment of an approved RFC. In this case, it's
DoH (https://tools.ietf.org/html/rfc8484).

Mozilla's presentation accurately stated that DNS is no longer an effective
control surface. It can't be, given that HTTPS is ubiquitous, and one can
use it to tunnel any protocol.

thanks,
Rob

---

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

> On 23 Jul 2019, at 23:09, Rob Sayre <[email-masked]> wrote:
> 
> Mozilla's presentation accurately stated that DNS is no longer an effective control surface.

That statement will come as news to those in the multi-million (billion?) dollar business of using DNS to protect against malware, phishing, spam, botnets and so on. Like this:
https://www.nominet.uk/cyber-defence-invisible-but-pivotal

I quote from that article "our PDNS service has blocked over 30 million attempts by public sector organisations to access malicious domains since the service began. On average, the PDNS blocks over 10,000 malicious domains every month.". IMO those numbers meet any reasonable definition of effective.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 15:30:10 -0700

On Tue, Jul 23, 2019 at 3:25 PM Jim Reid <[email-masked]> wrote:

> That statement will come as news to those in the multi-million (billion?)
> dollar business of using DNS...
>

I think that's a fine position to hold. If adoption of DoH is harmful along
the lines you describe, it won't succeed. I don't think the IETF has a role
in deciding that preemptively, though.

thanks,
Rob

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 23 Jul 2019 15:35:36 -0700

On 7/23/19 3:09 PM, Rob Sayre wrote:
> Hi,
> 
> The IETF shouldn't take up work in reaction to non-technical (aka 
> "policy") concerns about imminent deployment of an approved RFC. In this 
> case, it's DoH (https://tools.ietf.org/html/rfc8484).
> 
> Mozilla's presentation accurately stated that DNS is no longer an 
> effective control surface. It can't be, given that HTTPS is ubiquitous, 
> and one can use it to tunnel any protocol.

1. A primary motivation, according to previous discussions on this and 
other mailing lists, for DoH is predicated on the *significant 
effectiveness* of DNS filtering by oppressive governments.

2. A number of us have pointed out that DNS filtering is commonly used, 
also quite effectively, by good guys, and that using DoH by default can 
create noticeable collateral damage.

3. You have stated that DNS filter was never that effective, which then 
calls into question the primary motivation for DoH.  See #1.

Such an argument--that DNS filtering works for bad uses but doesn't work 
for good uses--uncannily mirrors the argument for weakening encryption: 
Terrorists won't be able to use encryption, but law-abiding citizens can 
still rest assured that online banking and e-commerce will be *just as 
secure* as it was before encryption protocols were watered down with 
backdoors.

Neither argument holds much water.

michael

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 23 Jul 2019 22:41:56 +0000

> The IETF shouldn't take up work in reaction to non-technical (aka "policy") concerns about imminent deployment of an approved RFC

Those "non-technical" concerns have technical impact, so I fail to see why. DNS server feature discovery protocols, DoH enhancements, and DoH versus DoT preference are all technical topics in the IETF right now that would benefit from the "non-technical" perspective being brought up by many of us.

> Mozilla's presentation accurately stated that DNS is no longer an effective control surface. It can't be, given that HTTPS is ubiquitous, and one can use it to tunnel any protocol.

Michael summarizes my thoughts very well below. To that I'll add: DoH blocks middle boxes from exerting control, but changes nothing about how the RR the stub is reaching out to can exert control. For example, users of Quad9 and CleanBrowsing can use DoH today and are obviously still benefitting from DNS control via content filtering and malware avoidance. Nothing stops app-trusted DoH providers from doing the same thing.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Michael Sinatra <[email-masked]>
Sent: Tuesday, July 23, 2019 3:35 PM
To: Rob Sayre <[email-masked]>; [email-masked] <[email-masked]>; Barry Leiba <[email-masked]>
Subject: Re: [Add] meeting hum: should the IETF take up this work?

On 7/23/19 3:09 PM, Rob Sayre wrote:
> case, it's DoH (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8484&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C557e447caa8e4c0195c108d70fbe22b1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636995181625289666&amp;sdata=C13WKC4in7qwck%2BzNF3v3TJMreWx%2BiOAaYqI2KFkAHc%3D&amp;reserved=0).
>

michael

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

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Jul 2019 23:45:07 +0100

> On 23 Jul 2019, at 23:30, Rob Sayre <[email-masked]> wrote:
> 
> If adoption of DoH is harmful along the lines you describe, it won't succeed. I don't think the IETF has a role in deciding that preemptively, though.

You're badly, badly mistaken. AFAICT nobody is saying DoH adoption is harmful. I'm certainly not saying that. Is DoH deployment disruptive? - yes. Harmful? - no. Does it have impact on existing networks and IT infrastructure? Yes.

I hope the IETF is willing to document these impacts.

And FWIW the success of DoH deployment -- for some definition of success -- seems to rest solely in the hands of a very small number of dominant players. That's unhealthy. YMMV.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 23 Jul 2019 22:46:05 +0000

That’s like saying IETF should never have published BCP 38. What is BCP 38 (or any other BCP), if not policy?
IETF absolutely is the right place to discuss BCPs related to technology that has the ability to massively impact the traffic patterns of the Internet and impact (in a very negative way) the experience of all users of the Internet. I’m *not* saying that it *will* have such a negative impact. But it absolutely has the ability. And it’s this *potential* that has all the network operators very worried.

The Internet ecosystem is built on the idea that the various participants can generally trust one another to participate in a way that benefits the Internet and its users.
I don’t believe that any of the application developers participating in IETF want to damage the Internet or have a negative impact on users’ experiences.
And I very much trust and like the people from Mozilla and Google and Cloudflare. They’re all super nice people who are great fun to drink beer with.
But I don’t think they have the operational experience/knowledge to fully understand what might happen in various access networks (especially mobile networks) if they started defaulting all their application users to DNS servers outside the local (ISP, enterprise, university, etc.) network.
The IETF is a place where we can and must have this discussion, so all parties can participate in understanding and mitigating the potential harm.

I’m also trying to understand why there seems to be resistance to providing ISPs with advice on deploying DoH. Who does it hurt to provide such advice, and why should it be improper for IETF to provide advice on deploying a protocol it has published? [Advice on how to deploy is absolutely a form of “policy”.]
And why should an ISP DoH resolver or using regular DNS not be considered valid “choices” for a user to make?
Barbara

From: Add <[email-masked]> On Behalf Of Rob Sayre
Sent: Tuesday, July 23, 2019 6:09 PM
To: [email-masked]; Barry Leiba <[email-masked]>
Subject: [Add] meeting hum: should the IETF take up this work?

Hi,

The IETF shouldn't take up work in reaction to non-technical (aka "policy") concerns about imminent deployment of an approved RFC. In this case, it's DoH (https://tools.ietf.org/html/rfc8484<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8484&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=k1e1muHdqm-ONwR45wiuv8wXcq1yvfPjFbBIMZURbwM&s=JuF6FZ_JnOj3uIC39JSKJtDfgM-xXTh2hTl8LzaNwPY&e=>).

thanks,
Rob

---

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

On Tue, Jul 23, 2019 at 3:46 PM STARK, BARBARA H <[email-masked]> wrote:

> That’s like saying IETF should never have published BCP 38.
>

Is it?

> IETF absolutely is the right place to discuss
>

 Yes, it is. But that doesn't mean a WG or a BCP should result.

> But I don’t think they have the operational experience/knowledge to fully
> understand what might happen in various access networks (especially mobile
> networks) if they started defaulting all their application users to DNS
> servers outside the local (ISP, enterprise, university, etc.) network.
>

I don't think DoH implies this impending doom. Carriers can already control
networking in many ways (e.g. preventing/allowing tethering), so it just
seems like a new negotiation point in a business discussion (that I am in
no way part of).

The bottom line is this: the IETF has been unable to secure DNS in a
successful way for 31 years. I think people are losing patience.

thanks,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2019 19:49:24 -0400

Rob Sayre <[email-masked]> wrote:
    > I think that's a fine position to hold. If adoption of DoH is harmful
    > along the lines you describe, it won't succeed. I don't think the IETF
    > has a role in deciding that preemptively, though.

But, perhaps we can both.

---

From: "Reed, Jon" <[email-masked]>
Date: Wed, 24 Jul 2019 00:01:45 +0000

In addition to everything Barbara says, I’m not a fan of phrasing these concerns as “non-technical”.  They are a direct result of standards developed here.   I’m not placing a value judgement on the protocol itself, but the adoption thereof fundamentally changed what Barbara so accurate described as an ecosystem.   It’s fine to say that the ecosystem was “wrong” to begin with, and it’s fine to say that you believe the benefits outweigh the negative impacts, but I don’t think we can pretend nothing has changed.
But I’d also like to touch on a theme today I heard in the various presentations and mic comments:  the role of the end user.

There was considerable talk of user consent.  But it is impossible to consent to something you cannot understand, and we also continue assert that users need not understand the DNS (“the plumbing”) in order to use applications which make use of it.   So I think “consent” is inaccurate, and we should perhaps use “acquiescence” instead.

-Jon

From: "STARK, BARBARA H" <[email-masked]>
Date: Tuesday, July 23, 2019 at 6:46 PM
To: 'Rob Sayre' <[email-masked]>, "[email-masked]'" <[email-masked]>, 'Barry Leiba' <[email-masked]>
Subject: Re: [Add] meeting hum: should the IETF take up this work?

Hi,

thanks,
Rob

---

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

On Tue, Jul 23, 2019 at 5:02 PM Reed, Jon <[email-masked]> wrote:

> In addition to everything Barbara says, I’m not a fan of phrasing these
> concerns as “non-technical”.  They are a direct result of standards
> developed here.
>

That's a fine opinion. However, I'm not sure everyone is in sync on what
the IETF does.

For example, there was a presentation today that suggested requiring use of
the OS DNS stack might be an appropriate subject for an IETF WG. It isn't,
even though it is a technical topic.

DNS is insecure in a coffee shop, and that is going to be fixed.

thanks,
Rob

>
>
> *From: *"STARK, BARBARA H" <[email-masked]>
> *Date: *Tuesday, July 23, 2019 at 6:46 PM
> *To: *'Rob Sayre' <[email-masked]>, "[email-masked]'" <[email-masked]>,
> 'Barry Leiba' <[email-masked]>
> *Subject: *Re: [Add] meeting hum: should the IETF take up this work?
>
>
>
> IETF absolutely is the right place to discuss BCPs related to technology
> that has the ability to massively impact the traffic patterns of the
> Internet and impact (in a very negative way) the experience of all users of
> the Internet. I’m **not** saying that it **will** have such a negative
> impact. But it absolutely has the ability. And it’s this **potential**
> that has all the network operators very worried.
>
>
>
> The Internet ecosystem is built on the idea that the various participants
> can generally trust one another to participate in a way that benefits the
> Internet and its users.
>
> I don’t believe that any of the application developers participating in
> IETF want to damage the Internet or have a negative impact on users’
> experiences.
>
> And I very much trust and like the people from Mozilla and Google and
> Cloudflare. They’re all super nice people who are great fun to drink beer
> with.
>
> The IETF is a place where we can and must have this discussion, so all
> parties can participate in understanding and mitigating the potential harm.
>
>
>
> I’m also trying to understand why there seems to be resistance to
> providing ISPs with advice on deploying DoH. Who does it hurt to provide
> such advice, and why should it be improper for IETF to provide advice on
> deploying a protocol it has published? [Advice on how to deploy is
> absolutely a form of “policy”.]
>
> *From:* Add <[email-masked]> *On Behalf Of * Rob Sayre
> *Sent:* Tuesday, July 23, 2019 6:09 PM
> *To:* [email-masked]; Barry Leiba <[email-masked]>
> *Subject:* [Add] meeting hum: should the IETF take up this work?
>
>
>
> Hi,
>
>
>
> case, it's DoH (https://tools.ietf.org/html/rfc8484
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8484&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=k1e1muHdqm-ONwR45wiuv8wXcq1yvfPjFbBIMZURbwM&s=JuF6FZ_JnOj3uIC39JSKJtDfgM-xXTh2hTl8LzaNwPY&e=>
> ).
>
>
>
> effective control surface. It can't be, given that HTTPS is ubiquitous, and
> one can use it to tunnel any protocol.
>
>
>
> thanks,
>
> Rob
>

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 02:56:15 +0100

> On 24 Jul 2019, at 01:16, Rob Sayre <[email-masked]> wrote:
> 

It didn't/doesn't take or need DoH (or DoT) to fix that problem.

Though of course I'm glad we've got DoT and DoH as new weapons in the on-going security arms race.

BTW, using DoH or DoT in the above scenario doesn't necessarily make things "secure". It just changes the security landscape by swapping one set of concerns for another. A cynic (or realist) would say they'd just replaced one DNS resolver they probably didn't/shouldn't trust to another that isn't necessarily more trustworthy. Unless DNSSEC validation is used, a client can never tell if its resolving server is telling the truth or not -- irrespective of whether that answer got sent from port 53, port 443 or port 853.

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 22:05:06 -0400

I agree with Barbara.  Further, why is it so hard for us to acknowledge and document how this is going to impact operators and even give them some options?  What are we so afraid of?  Letting people know that we made a change that is going to impact them? 

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

> On Jul 23, 2019, at 6:46 PM, STARK, BARBARA H <[email-masked]> wrote:
> 
> The IETF shouldn't take up work in reaction to non-technical (aka "policy") concerns about imminent deployment of an approved RFC. In this case, it's DoH (https://tools.ietf.org/html/rfc8484 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8484&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=k1e1muHdqm-ONwR45wiuv8wXcq1yvfPjFbBIMZURbwM&s=JuF6FZ_JnOj3uIC39JSKJtDfgM-xXTh2hTl8LzaNwPY&e=>).
>  
> https://www.ietf.org/mailman/listinfo/add

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 19:07:53 -0700

> It didn't/doesn't take or need DoH (or DoT) to fix that problem.

DNS has had 31 years to fix the problem. It's still just unencrypted coffee
shop traffic, right?

> on-going security arms race.

That's not clear to me.

> BTW, using DoH or DoT in the above scenario doesn't necessarily make
> things "secure". It just changes the security landscape by swapping one set
> of concerns for another. A cynic (or realist) would say they'd just
> replaced one DNS resolver they probably didn't/shouldn't trust to another
> that isn't necessarily more trustworthy.

It does avoid a variety of local attacks.

> Unless DNSSEC validation is used
>

Uh, no.

thanks,
Rob

---

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

On Tue, Jul 23, 2019 at 7:05 PM Bret Jordan <[email-masked]> wrote:

> this is going to impact operators
>

Saying "this is going to impact operators" without specifics sounds more
like a business problem, rather than a technical issue.

thanks,
Rob

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 22:16:28 -0400

Well to use the argument that others have used, why not just use VPN in your coffee shop?

Thanks,
Bret

> On Jul 23, 2019, at 10:07 PM, Rob Sayre <[email-masked]> wrote:
> 
> On Tue, Jul 23, 2019 at 6:50 PM Jim Reid <[email-masked] <mailto:[email-masked]>> wrote:
> DNS has had 31 years to fix the problem. It's still just unencrypted coffee shop traffic, right?
>  
> BTW, using DoH or DoT in the above scenario doesn't necessarily make things "secure". It just changes the security landscape by swapping one set of concerns for another. A cynic (or realist) would say they'd just replaced one DNS resolver they probably didn't/shouldn't trust to another that isn't necessarily more trustworthy.
>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 19:19:38 -0700

On Tue, Jul 23, 2019 at 7:16 PM Bret Jordan <[email-masked]> wrote:
Well to use the argument that others have used, why not just use VPN in
your coffee shop?

It's a fair point. It seems like this isn't really about security.

Are people selling DNS logs to ad tech companies? Is that the ecosystem
being disrupted?

thanks,
Rob

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 24 Jul 2019 02:26:03 +0000

> Are people selling DNS logs to ad tech companies? Is that the ecosystem being disrupted?

Given how many valid points have been brought up in the last few weeks about the drawbacks of centralized app-configured DNS, I don’t think the glib tone is constructive.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Rob Sayre <[email-masked]>
Sent: Tuesday, July 23, 2019 7:19:38 PM
To: Bret Jordan <[email-masked]>
Cc: Jim Reid <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Add] fixing coffee shop brokenness with DoH

On Tue, Jul 23, 2019 at 7:16 PM Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
Well to use the argument that others have used, why not just use VPN in your coffee shop?

Are people selling DNS logs to ad tech companies? Is that the ecosystem being disrupted?

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 19:33:40 -0700

On Tue, Jul 23, 2019 at 7:26 PM Tommy Jensen <[email-masked]>
wrote:

> Given how many valid points have been brought up in the last few weeks
> about the drawbacks of centralized app-configured DNS
>

Valid points: 0. (see how easy it is to just claim points are valid or
invalid?)

> I don’t think the glib tone is constructive.
>

You just sent me an email that said your thoughts were very well
represented by an incoherent email about terrorists and encryption [0].

Spare me the tone policing.

thanks,
Rob

[0] https://mailarchive.ietf.org/arch/msg/add/8purz-Ks-d6sNAynV5jd5zE71-o

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 24 Jul 2019 02:57:56 +0000

I don’t agree that the email was “incoherent” as it pointed out the flaw in insisting that DNS filtering is a dead technology, the conflict being that DNS tampering is effective enough by bad actors to deserve work and attention but not effective enough by good actors to deserve consideration.

Thanks,
Tommy
________________________________
From: Rob Sayre <[email-masked]>
Sent: Tuesday, July 23, 2019 7:33:40 PM
To: Tommy Jensen <[email-masked]>
Cc: Bret Jordan <[email-masked]>; Jim Reid <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Add] fixing coffee shop brokenness with DoH

> Are people selling DNS logs to ad tech companies? Is that the ecosystem being disrupted?

Given how many valid points have been brought up in the last few weeks about the drawbacks of centralized app-configured DNS

Valid points: 0. (see how easy it is to just claim points are valid or invalid?)

You just sent me an email that said your thoughts were very well represented by an incoherent email about terrorists and encryption [0].

thanks,
Rob

[0] https://mailarchive.ietf.org/arch/msg/add/8purz-Ks-d6sNAynV5jd5zE71-o<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fadd%2F8purz-Ks-d6sNAynV5jd5zE71-o&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C3315a67662854808ec0a08d70fdf5e17%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636995324339560293&sdata=mxpwRGW%2FW6XtRmJUY77F2YsVq9zRnHULCSWrK5lWWzk%3D&reserved=0>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 20:02:42 -0700

On Tue, Jul 23, 2019 at 7:57 PM Tommy Jensen <[email-masked]>
wrote:

> I don’t agree that the email was “incoherent” as it pointed out the flaw
> in insisting that DNS filtering is a dead technology, the conflict being
> that DNS tampering is effective enough by bad actors to deserve work and
> attention but not effective enough by good actors to deserve consideration.
>

Ah, now this sounds like a good idea for an Internet-Draft. Why not write
up this idea? That way, it can be evaluated outside of a message thread.

thanks,
Rob

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 24 Jul 2019 03:17:23 +0000

I appreciate the feedback. If I bring an I-D it will be more broad than this particular point. The point of “DNS filtering isn’t dead” is small potatoes compared to the larger “how we can collaborate as ecosystem components on providing the most ideal DNS experience” I think we’re all trying to go for. I’m listening and participating on these threads to see if I can even convince myself of such a draft.

Thanks,
Tommy
Sent: Tuesday, July 23, 2019 8:02:42 PM

On Tue, Jul 23, 2019 at 7:57 PM Tommy Jensen <[email-masked]<mailto:[email-masked]>> wrote:
I don’t agree that the email was “incoherent” as it pointed out the flaw in insisting that DNS filtering is a dead technology, the conflict being that DNS tampering is effective enough by bad actors to deserve work and attention but not effective enough by good actors to deserve consideration.

Ah, now this sounds like a good idea for an Internet-Draft. Why not write up this idea? That way, it can be evaluated outside of a message thread.

thanks,
Rob

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 23:37:40 -0400

We need to calmly and completely document the issues, the risks, and the ramifications. We need to do a design where we take input from all sides.  Where we rationally understand the various use cases and work together.  

Bret 

Sent from my Commodore 128D

> On Jul 23, 2019, at 11:17 PM, Tommy Jensen <[email-masked]> wrote:
> 
> On Tue, Jul 23, 2019 at 7:57 PM Tommy Jensen <[email-masked]> wrote:

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 20:40:50 -0700

On Tue, Jul 23, 2019 at 8:37 PM Bret Jordan <[email-masked]> wrote:

> We need to calmly and completely document the issues, the risks, and the
> ramifications. We need to do a design where we take input from all sides.
> Where we rationally understand the various use cases and work together.
>

That's how the IETF works, right? The RFC is done:

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

I don't believe there is a special process for people who didn't like the
result, but I could be wrong. I don't know every last letter of each
process document.

thanks,
Rob

---

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

> Well to use the argument that others have used, why not just use VPN in

Because good privacy and integrity of DNS lookups should be by default and
should respect the choices of the user.

See also the essay referred to in:

https://mailarchive.ietf.org/arch/msg/add/LHDXjeYUwoSzzARloeywdo59Sew

... albeit that that is a rather long post.

- alec

---

From: [email-masked]
Date: Wed, 24 Jul 2019 07:34:02 +0200 (CEST)

> should respect the choices of the user.

I have chosen my resolvers carefully and configured my resolv.conf
accordingly. If Mozilla and/or Google "upgrade" my browsers to use
DoH, without asking me, they are not respecting my choices.

Steinar Haug, AS2116

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Jul 2019 22:36:33 -0700

On Tue, Jul 23, 2019 at 10:34 PM <[email-masked]> wrote:

> accordingly.

I don't think anyone would override that intentionally.

Which secure DNS protocol are you using?

thanks,
Rob

---

From: Brett Carr <[email-masked]>
Date: Wed, 24 Jul 2019 09:30:03 +0000

-----Original Message-----
From: Add <[email-masked]> on behalf of Jim Reid <[email-masked]>
Date: Tuesday, 23 July 2019 at 23:45
To: Rob Sayre <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Add] meeting hum: should the IETF take up this work?

    

  >  And FWIW the success of DoH deployment -- for some definition of success -- seems to rest solely in the hands of a very small number of dominant players. That's unhealthy. YMMV.
    
I completely agree with Jims position here. DOH/DOT are here to stay and good things but they are disruptive and hence I think operators would benefit from some guidance from the IETF.

I would like to see lots of operators running DOH/DOT in an interoperable standard way and not leave it to a few large organisations.

Brett

--
Brett Carr
Manager DNS and Network Engineering
Nominet UK

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 24 Jul 2019 06:19:09 -0400

On Tue, Jul 23, 2019 at 22:26 Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> about the drawbacks of centralized app-configured DNS, I don’t think the
> glib tone is constructive.
>

Tone aside, to some users, centralization is a benefit in that they don't
have a bunch of unknown privacy policies applying to the resolution of the
names they need. For example, the privacy policy of 1.1.1.1 is pretty
amazing from the perspective of data retention, secondary uses, etc. (e.g.,
I know my resolutions will be removed from their logs within 24 hours).

This may seem small but it seems to be lost in the centralization/choice
discussion.

Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Jul 2019 06:27:30 -0400

Rob,

> Spare me the tone policing.

second reminder to keep the discussion civil.

Lars

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2019 03:40:08 -0700

> It didn't/doesn't take or need DoH (or DoT) to fix that problem.

Can you expand on this point?  I'm guessing you're referring to DNSSEC, but
if so, DNSSEC does not address two security issues that we are concerned
with:

- Surveillance by actors on the user's network (including, perhaps, the
recursive resolver)
- Blocking by the recursive resolver. (see below)

Though of course I'm glad we've got DoT and DoH as new weapons in the
> on-going security arms race.
>
> that isn't necessarily more trustworthy. Unless DNSSEC validation is used,
> a client can never tell if its resolving server is telling the truth or not
> -- irrespective of whether that answer got sent from port 53, port 443 or
> port 853.
>

In many cases, whether you are being told the truth by your recursive
resolver is a less interesting property than whether you can get the
correct answer. For instance, if the recursive resolver replaces the A
record you want with NXDOMAIN even if you know that it's done so, you're
still blocked from going where you wanted to go.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 06:54:11 -0400

On Jul 24, 2019, at 6:40 AM, Eric Rescorla <[email-masked]> wrote:
>> In many cases, whether you are being told the truth by your recursive resolver is a less interesting property than whether you can get the correct answer. For instance, if the recursive resolver replaces the A record you want with NXDOMAIN even if you know that it's done so, you're still blocked from going where you wanted to go.

However, even if you are not blocked, without DNSSEC you do not know that the resolver gave you the right answer.  So ideally you want both: not to be blocked, and also to be able to validate the result you got. 

I know you already know this but I want to make it explicit because I’ve seen at least one person on this thread say that with DoH, DNSSEC isn’t needed.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 24 Jul 2019 10:58:15 +0000

Hi,

On 24/07/2019, 06:41, "Add on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Can you expand on this point?  I'm guessing you're referring to DNSSEC, but if so, DNSSEC does not address two security issues that we are concerned with:

- Surveillance by actors on the user's network (including, perhaps, the recursive resolver)
- Blocking by the recursive resolver. (see below)

As far as I can tell, both can be reduced to a trust issue (modulo the use of encryption to avoid surveillance on the wire), as it has to deal with how much you trust your resolver. DOH does not stop the resolver from recording or blocking queries, or providing whatever the kind of biased replies. My take from the discussion yesterday was that the gist of the discussion was not about DNS encryption but about resolver designation.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

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

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Bret Jordan <[email-masked]>
Date: Wed, 24 Jul 2019 07:33:48 -0400

If you are really worried about it, run your own.  I do, and have for 25+ years.  

Bret 

> On Jul 24, 2019, at 6:19 AM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> 
> 
>> On Tue, Jul 23, 2019 at 22:26 Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> Tone aside, to some users, centralization is a benefit in that they don't have a bunch of unknown privacy policies applying to the resolution of the names they need. For example, the privacy policy of 1.1.1.1 is pretty amazing from the perspective of data retention, secondary uses, etc. (e.g., I know my resolutions will be removed from their logs within 24 hours).
> 
> This may seem small but it seems to be lost in the centralization/choice discussion.
> -- 
> Joseph Lorenzo Hall

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 24 Jul 2019 07:36:29 -0400

I can do that but the user base we represent at CDT cannot. So not an
answer.

On Wed, Jul 24, 2019 at 07:33 Bret Jordan <[email-masked]> wrote:

> 1401 K ST NW STE 200, Washington DC 20005
> <https://www.google.com/maps/search/1401+K+ST+NW+STE+200,+Washington+DC+20005?entry=gmail&source=g>
> -3497
Joseph Lorenzo Hall

---

From: Bret Jordan <[email-masked]>
Date: Wed, 24 Jul 2019 07:42:01 -0400

My point is centralization of dns queries seems like a far larger potential problem.  Especially when the query is over http and can easily allow extra headers so the end user can be fully tracked.  

Bret

> On Jul 24, 2019, at 7:36 AM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> I can do that but the user base we represent at CDT cannot. So not an answer.
>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 24 Jul 2019 07:52:23 -0400

Sure, and there are countervailing considerations... e.g., that same
privacy policy (legally) limits what tracking that endpoint can do. Plus,
I'm not as confident in my own ability to protect that resolver and
associated data as I am about Cloudflare (or Google, etc.)

On Wed, Jul 24, 2019 at 07:42 Bret Jordan <[email-masked]> wrote:

> My point is centralization of dns queries seems like a far larger
> potential problem.  Especially when the query is over http and can easily
> allow extra headers so the end user can be fully tracked.
>
> Bret
>
Joseph Lorenzo Hall

---

From: <[email-masked]>
Date: Wed, 24 Jul 2019 11:52:57 +0000

This is a good point; there are valid reasons why 1.1.1.1 can be the right provider for some users. Please allow me to clarify some possible misunderstandings.

I’m not against DoH.
I’m not against privacy and security.
I’m not against user choice.

These are all valuable things we should strive for. Let’s do it in a way that works for everyone, by identifying and documenting best practice.

Chris

From: Add <[email-masked]> On Behalf Of Joseph Lorenzo Hall
Sent: 24 July 2019 06:19
To: Tommy Jensen <Jensen.Thomas=[email-masked]>
Cc: Jim Reid <[email-masked]>; [email-masked]; Bret Jordan <[email-masked]>; Rob Sayre <[email-masked]>
Subject: Re: [Add] fixing coffee shop brokenness with DoH

[snip]

e: [email-masked]<mailto:[email-masked]>, p: 202.407.8825, pgp: https://josephhall.org/gpg-key

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Jul 2019 15:05:38 +0200 (CEST)

Il 24 luglio 2019 12:19 Joseph Lorenzo Hall <[email-masked]> ha scritto:

What you seem to want above, however, is not made possible by centralization, but by user choice, i.e. the user being able to tell all the applications to use a specific resolver that has a privacy policy they like. Centralization might make your choice easier, since you have less privacy policies to compare, but might also make it impossible for you to find one that you actually like - the fewer they are, the easier it is for them to form a cartel and impose conditions that are only good for them.

Moreover, the above is already possible today over unencrypted DNS(*) - just enter "1.1.1.1" or whatever other IP address in the configuration of your operating system. And DoH could even make it go away, if applications started to tell you that you are "not technical enough" to even deserve a configuration option, and started sending your DNS queries to a resolver that you did not choose and that maybe does not have the privacy policy you want.

(I will also note that all this focus on privacy policies is a U.S. bias - in Europe, all resolvers have a pretty restrictive basic privacy policy which is mandated by the requirements of the GDPR, though of course there still are differences that deserve giving users a choice.)

(*) bar transparent proxying etc, which encrypted DNS will make impossible and I don't think anyone has objections to that, as long as in the overall we build a system that works for everyone.

--

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2019 06:14:37 -0700

On Wed, Jul 24, 2019 at 3:54 AM Ted Lemon <[email-masked]> wrote:

> However, even if you are not blocked, without DNSSEC you do not know that
> the resolver gave you the right answer.  So ideally you want both: not to
> be blocked, and also to be able to validate the result you got.
>

Well, this is true, but in the Web context, as we move towards 100% HTTPS,
the importance of getting the right IP starts to decrease quite a bit: if
you get the wrong IP address, then this turns into a connection failure.

-Ekr

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Jul 2019 15:20:35 +0200 (CEST)

Il 24 luglio 2019 00:58 Rob Sayre <[email-masked]> ha scritto:

The bottom line is this: the IETF has been unable to secure DNS in a successful way for 31 years. I think people are losing patience.

Well, if the Web and OTT industry is "losing patience" about a presumed lack of security in DNS, perhaps they could start by actually deploying DNSSEC and DANE in browsers, in their big email platforms and the likes, isn't it?

Rather than on a blame game, I think it would be much better if we could focus on imagining how the DNS should work in the future and be a great naming system for the 21st century. Both DNSSEC and encrypted transport are part of this, and possibly other pieces that still need to be developed, such as a way to discover and negotiate policies between the client and the network.

--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2019 06:33:02 -0700

On Wed, Jul 24, 2019 at 6:21 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> Well, if the Web and OTT industry is "losing patience" about a presumed
> lack of security in DNS, perhaps they could start by actually deploying
> DNSSEC and DANE in browsers, in their big email platforms and the likes,
> isn't it?
>

As I indicated in a previous message: DNSSEC does not address a number of
the security issues that we are concerned with. DANE is an orthogonal issue.

-Ekr

> Rather than on a blame game, I think it would be much better if we could
> focus on imagining how the DNS should work in the future and be a great
> naming system for the 21st century. Both DNSSEC and encrypted transport are
> part of this, and possibly other pieces that still need to be developed,
> such as a way to discover and negotiate policies between the client and the
> network.
>
> --
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 09:53:12 -0400

On Jul 24, 2019, at 9:14 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Well, this is true, but in the Web context, as we move towards 100% HTTPS, the importance of getting the right IP starts to decrease quite a bit: if you get the wrong IP address, then this turns into a connection failure.

Sort of like a fake NXDOMAIN, then?

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 24 Jul 2019 10:03:38 -0400

On Wed, Jul 24, 2019 at 9:05 AM Vittorio Bertola <
[email-masked]> wrote:

> 40microsoft.com@dmarc..ietf.org <[email-masked]>> wrote:
>
> What you seem to want above, however, is not made possible by
> centralization, but by user choice, i.e. the user being able to tell all
> the applications to use a specific resolver that has a privacy policy they
> like. Centralization might make your choice easier, since you have less
> privacy policies to compare, but might also make it impossible for you to
> find one that you actually like - the fewer they are, the easier it is for
> them to form a cartel and impose conditions that are only good for them.
>
>
These are good points... in the case I'm talking about it's definitely
having user choice, having understandable privacy policies (to people like
me, not end-users necessarily), and having usable ways of turning this on
(e.g., the 1.1.1.1 app from Cloudflare or the Intra app from Google for
older Android to use DoT).

> (I will also note that all this focus on privacy policies is a U.S. bias -
> in Europe, all resolvers have a pretty restrictive basic privacy policy
> which is mandated by the requirements of the GDPR, though of course there
> still are differences that deserve giving users a choice.)
>

So true... We're actively working on generic data protection laws in the
USA, wish us luck! best, Joe

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 10:15:33 -0400

On Jul 24, 2019, at 9:05 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> What you seem to want above, however, is not made possible by centralization, but by user choice, i.e. the user being able to tell all the applications to use a specific resolver that has a privacy policy they like.

I asked this question earlier and nobody answered, so I’ll ask it again.  How do we ensure that the user has a choice and that the choice is honored?   Or to put it differently, suppose a malicious app wants to funnel all user DNS requests to a tracker.   How can we detect that this is happening?   How can we prevent it?

I think there’s a tendency to not talk about this problem because I think it’s an extremely hard problem.   It pretty much boils down to this: who can the user trust?  Can the user even meaningfully evaluate their determination of trust?   At present, the trust model is “if I download the browser from Mozilla, I can trust it,” or some variation on that model.  This maybe works for something like Firefox, but, if pretty much any app is doing DoH, can we even tell that this is happening?

I can think of ways of making it hard for the app to misbehave in this way, but no way to completely prevent it.

This is important for two reasons.   First, we should not pretend that we can prevent what we can’t prevent.   Secondly, we should actually come up with a mitigation strategy.

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 15:21:03 +0100

> On 24 Jul 2019, at 03:19, Rob Sayre <[email-masked]> wrote:
> 

Earlier in this thread you said "DNS is insecure in a coffee shop, and that is going to be fixed.". Can you please explain this apparent contradiction?

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 24 Jul 2019 14:22:04 +0000

Just to wholeheartedly second Ted’s point. As I tried to express before, my take of the discussion yesterday is that we have to deal with a (quite serious) trust issue.

Dr Diego R. Lopez
Telefonica I+D

On 24/07/2019, 10:15, "Add on behalf of Ted Lemon" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Jul 24, 2019, at 9:05 AM, Vittorio Bertola <vittorio.bertola=[email-masked]<mailto:vittorio.bertola=[email-masked]>> wrote:
What you seem to want above, however, is not made possible by centralization, but by user choice, i.e. the user being able to tell all the applications to use a specific resolver that has a privacy policy they like.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Jul 2019 10:33:23 -0400

> you get the wrong IP address, then this turns into a connection failure.

This is an important assertion that requires refutation: this is incorrect.

The importance of the correct IP is essential, because of the relatively
weak system under which TLS certificates are (or can be) issued.
While individual CAs may be extremely trustworthy, there has been instances
of other CAs (retrospectively discovered as being untrustworthy) issuing
TLS certificates to parties other than the domain owner.

This is why DNSSEC, and DANE, are an important mechanism available for
strengthening certificate/browser security.

DANE allows domain owners to securely link a specific CA or specific
certificate to a domain name.

Only with DNSSEC and DANE, is it true that the IP address being wrong would
a connection failure be guaranteed to occur.

That is, in fact, one of the underpinnings for why bad actors have an
interest in altering DNS caches to provide forged IP addresses.

Thus, I assert that not only is DANE not strictly orthogonal, it is an
essential part of securing the web, along with DNSSEC.

This is true even in a 100% HTTPS environment. The security of DNS as
provided by DNSSEC is both orthogonal to, and more important than, the
privacy of DNS recursive queries, when it to achieving that 100% HTTPS
environment.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2019 07:37:05 -0700

On Wed, Jul 24, 2019 at 6:53 AM Ted Lemon <[email-masked]> wrote:

> > Well, this is true, but in the Web context, as we move towards 100%
> HTTPS, the importance of getting the right IP starts to decrease quite a
> bit: if you get the wrong IP address, then this turns into a connection
> failure.
>

Yes. But that need not be cryptographically verifiable because the client
really has no option but to abandon the connection at this point, even if
it is suspicious of the DNSSEC status.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 10:39:20 -0400

On Jul 24, 2019, at 10:37 AM, Eric Rescorla <[email-masked]> wrote:
> Yes. But that need not be cryptographically verifiable because the client really has no option but to abandon the connection at this point, even if it is suspicious of the DNSSEC status.

I think you reasoned a few steps faster than I am able to here, Eric.   Can you walk us through this step by step?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2019 07:42:54 -0700

On Wed, Jul 24, 2019 at 7:33 AM Brian Dickson <[email-masked]>
wrote:

>>> However, even if you are not blocked, without DNSSEC you do not know
>>> that the resolver gave you the right answer.  So ideally you want both: not
>>> to be blocked, and also to be able to validate the result you got.
>>>
>>

I think this is a topic on which we are going to have to agree to disagree.

-Ekr

> While individual CAs may be extremely trustworthy, there has been
> instances of other CAs (retrospectively discovered as being untrustworthy)
> issuing TLS certificates to parties other than the domain owner.
>
> Only with DNSSEC and DANE, is it true that the IP address being wrong
> would a connection failure be guaranteed to occur.
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Jul 2019 15:53:00 +0100

Eric Rescorla <[email-masked]> wrote:
>
> DNSSEC does not address two security issues that we are concerned with:
>
> - Blocking by the recursive resolver.

Whether these are problems or benefits is extremely context-dependent. In
some situations they might be an attack when done without the consent of
the end user; in others they might be part of the security infrastructure
of a managed network that the user willingly trusts. An application cannot
tell the difference.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: Cyclonic 3 to 5, becoming variable 2, then east 3 to 5
later. Moderate. Showers. Good occasionally poor.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Jul 2019 16:56:46 +0200 (CEST)

Il 24 luglio 2019 16:22 Diego R. Lopez <[email-masked]> ha scritto:

Trust in the Internet infrastructure is a hard problem because the trust relationships are different depending on subjective judgements and preferences. One user might trust the application and distrust the network, while another user might trust the network and distrust the application, and a third user might be uneducated and fail to make any decision or be easily fooled into trusting the wrong people. This last case leads to several parties claiming that they have to make decisions "on behalf of the users for their own good", but then a struggle between the application, the network and the government ensues, on who is actually entitled to do that, and to which extent.

The other face of this problem is the "control plan" discussion: DoH supporters claim that the DNS is not a proper control plan for the Internet, but then they do not provide alternatives to people that need one; they either say "do that at the endpoints" (which is generally cumbersome for non-technical users and even impossible in several legitimate cases, ranging from adversarial endpoints - e.g. a bot-infected device - to endpoints that won't have the necessary capabilities - e.g. IoT stuff), or "the Internet shall be free, go get lost!". This is likely to result in an "arms race" - if the protocol people do not provide a clear control plan, the operational people will just make one in some way, no matter how disruptive that will be.

While ADD already has more immediate points that deserve attention, such as the best practices for configuring Do* servers, it would be good if we could also have the architectural discussion above, which is broader and affects the Internet way beyond the DNS, though it comes up when discussing the DNS because that's where trust and control issues have been addressed until now. Perhaps this could be a separate working item or even a separate working group.

--

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 16:03:46 +0100

> On 24 Jul 2019, at 11:40, Eric Rescorla <[email-masked]> wrote:
> 

DNSSEC *does* deal with recursive resolver blocking - provided the blocked name is signed*. If the recursive resolver returns a lie -- fake RRs or an NXDOMAIN -- a validating client can detect that and act accordingly.

* Sadly, far too many zones are not signed yet - including yours and mine.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 11:05:06 -0400

On Jul 24, 2019, at 10:56 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> Trust in the Internet infrastructure is a hard problem because the trust relationships are different depending on subjective judgements and preferences. 

Vittorio, I think it’s important to make a distinction between “who you might choose to trust” and “who you are forced to trust.”

In order to run an app, if the app is able to make https connections, you are forced to trust the app.   This is true whether you are aware that you are trusting it or not, and regardless of your attitude toward your service provider.

This is what I am getting at.   This is completely orthogonal to the question of “whose resolver would I choose to trust?”

What DoH does, but what any app can do whether DoH is present or not, is to make it possible to trust someone other than your service provider.  Without some covert channel that the service provider can’t block, the user does not have this choice.

But really, the user doesn’t have this choice anyway.   It’s the app that has this choice.   The user may hope that the app does what the user wants, but the user probably can’t validate that leap of faith.

We in the IETF do not have the ability to prevent the app from bypassing the ISP’s resolver.   It’s totally pointless to talk about whether or not we should do this.

---

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

On Wed, Jul 24, 2019 at 7:39 AM Ted Lemon <[email-masked]> wrote:

> I think you reasoned a few steps faster than I am able to here, Eric.
> Can you walk us through this step by step?
>

Sure. The case of interest here is that you have a client which wants to
connect to domain A and the resolver (or a network attacker) wants to stop
them.

In the case where A is not DNSSEC signed, the attacker just sends NXDOMAIN,
which the client accepts and refuses to connect.

In the case where A *is* DNSSEC signed, the attacker can also inject an
NXDOMAIN. DNSSEC of course won't validate, but the client still doesn't
have an IP address to connect to, so it's only recourse is to error out.
Now, it can show the user a different error than it did for NXDOMAIN, but
these errors tend to be fairly generic anyway (Firefox, for instance, shows
"Hmm. We’re having trouble finding that site."), so from the user
perspective these aren't really very different.

That's actually the best case scenario. As a practical matter, endpoint
DNSSEC error rates are high enough that failure to validate DNSSEC records
isn't a reliable indicator of attack, so as a practical matter, you would
very likely just end up treating this as a simple resolution failure and
show the same error

-Ekr

---

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

On Wed, Jul 24, 2019 at 8:03 AM Jim Reid <[email-masked]> wrote:

> DNSSEC *does* deal with recursive resolver blocking - provided the blocked
> name is signed*. If the recursive resolver returns a lie -- fake RRs or an
> NXDOMAIN -- a validating client can detect that and act accordingly.
>

See my response to Ted. From the perspective of the client, acting
accordingly looks basically identical to how you behave with a valid
NXDOMAIN, and so DNSSEC doesn't change the situation very much.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 11:18:42 -0400

On Jul 24, 2019, at 11:10 AM, Eric Rescorla <[email-masked]> wrote:
> Sure. The case of interest here is that you have a client which wants to connect to domain A and the resolver (or a network attacker) wants to stop them.
> 
> In the case where A is not DNSSEC signed, the attacker just sends NXDOMAIN, which the client accepts and refuses to connect.
> 
> In the case where A *is* DNSSEC signed, the attacker can also inject an NXDOMAIN. DNSSEC of course won't validate, but the client still doesn't have an IP address to connect to, so it's only recourse is to error out. Now, it can show the user a different error than it did for NXDOMAIN, but these errors tend to be fairly generic anyway (Firefox, for instance, shows "Hmm. We’re having trouble finding that site."), so from the user perspective these aren't really very different.

Ah, I see where the disconnect is.   Yes, if the resolver and the network are controlled by the same entity, then DNSSEC doesn’t help you to get a connection.

However, if you are able to tunnel to a resolver that is not controlled by the network operator, then this equivalence no longer exists.   In this case, DNSSEC is useful for validating the NXDOMAIN, because the network operator is not cooperating with the resolver operator.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2019 08:20:18 -0700

On Wed, Jul 24, 2019 at 8:18 AM Ted Lemon <[email-masked]> wrote:

> In the case where A is not DNSSEC signed, the attacker just sends
> NXDOMAIN, which the client accepts and refuses to connect.
>
> Ah, I see where the disconnect is.   Yes, if the resolver and the network
> are controlled by the same entity, then DNSSEC doesn’t help you to get a
> connection.
>
> However, if you are able to tunnel to a resolver that is not controlled by
> the network operator, then this equivalence no longer exists.   In this
> case, DNSSEC is useful for validating the NXDOMAIN, because the network
> operator is not cooperating with the resolver operator.
>

I'm sorry, I think I'm confused. Where do you think the attacker is
positioned?

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 11:58:36 -0400

There are a variety of attack scenarios to account for. DNSSEC is not useful for countering a fake NXDOMAIN attack when the attacker also controls the path and can prevent connection establishment.

However, if the attacker is the resolver, and the resolver isn’t under the control of the path, then detecting a fake NXDOMAIN is useful. 

Sent from my iPhone

> On Jul 24, 2019, at 11:20 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I'm sorry, I think I'm confused. Where do you think the attacker is positioned?
> 
> -Ekr
>

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 17:05:50 +0100

> On 24 Jul 2019, at 16:11, Eric Rescorla <[email-masked]> wrote:
> 
> See my response to Ted. From the perspective of the client, acting accordingly looks basically identical to how you behave with a valid NXDOMAIN, and so DNSSEC doesn't change the situation very much.

Not really. A validation failure is a fairly strong indication that the resolver is lying to you. Or should be. So a security-aware application would know the current resolver can't be trusted (or is at the very least suspcious) and take suitable countermeasures. That's what I meant by "act accordingly".

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 17:26:21 +0100

> Can you expand on this point?  I'm guessing you're referring to DNSSEC.

Well DNSSEC is one option. There are others:
	using a VPN, IPec or some other encrypted tunnel
	pointing your (plaintext) queries at a resolver you consider trusted
	run a validating resolver on your device
	use a "special" DNS client like Cisco Anyconnect or IBM Endpoint Manager*
	
* These sorts of clients are very popular with roving enterprise users who *cannot and must not* trust the coffee shop resolver.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 12:59:51 -0400

On Tue, Jul 23, 2019 at 11:45:07PM +0100,
 Jim Reid <[email-masked]> wrote 
 a message of 16 lines which said:

> And FWIW the success of DoH deployment -- for some definition of
> success -- seems to rest solely in the hands of a very small number
> of dominant players.

It depends on us. Or, rather, on it depends on a more general group,
the group of people who write, install and manage DoH resolvers. The
more they will be, the less users will depend on a few servers.

My hope is we will see many DoH resolvers (not always public).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 13:03:02 -0400

On Wed, Jul 24, 2019 at 09:30:03AM +0000,
 Brett Carr <[email-masked]> wrote 
 a message of 27 lines which said:

> I would like to see lots of operators running DOH/DOT in an
> interoperable standard way and not leave it to a few large
> organisations.

I fully agree (the more, the better), but it does not completely
depend on IETF (we don't run network services). (See my paper at the
last IAB workshop
<https://www.iab.org/activities/workshops/dedr-workshop/position-papers/>)

---

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

On Wed, Jul 24, 2019 at 9:00 AM Jim Reid <[email-masked]> wrote:

> Not really. A validation failure is a fairly strong indication that the
> resolver is lying to you.

Not really, no. Our current belief is that there is going to be quite a
high rate of non-malicious validation failures.

Or should be. So a security-aware application would know the current
> resolver can't be trusted (or is at the very least suspcious) and take
> suitable countermeasures. That's what I meant by "act accordingly".
>

What do you believe those countermeasures are?

-Ekr

---

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

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

> There are a variety of attack scenarios to account for. DNSSEC is not
> useful for countering a fake NXDOMAIN attack when the attacker also
> controls the path and can prevent connection establishment.
>
> However, if the attacker is the resolver, and the resolver isn’t under the
> control of the path, then detecting a fake NXDOMAIN is useful.
>

How?

-Ekr

>> However, if you are able to tunnel to a resolver that is not controlled
>> by the network operator, then this equivalence no longer exists.   In this

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 13:15:49 -0400

On Tue, Jul 23, 2019 at 10:46:05PM +0000,
 STARK, BARBARA H <[email-masked]> wrote 
 a message of 183 lines which said:

> But I don’t think they have the operational experience/knowledge to
> fully understand what might happen in various access networks
> (especially mobile networks)

It is not just a matter of experience and knowledge. People (and
organisations) also have opinions and practical interests. Those in
power do not want to relinquish this power, those who have access to
data do not want to lose that access, etc. Framing the issue as "those
who know" vs. "the ignorants" is not the right way to go, IMHO.

> if they started defaulting all their application users to DNS

The IETF is certainy welcome to discuss that trend (although, as I
noted in a recent message
<https://mailarchive.ietf.org/arch/msg/add/yqQV8KAmVKaJG2YussbSlJOdB7E>,
it has nothing to do with "Applications Doing DNS") but with some
modesty: we design protocols, we can provide advices on how to use it,
but people can make deployment choices of their own. Using the access
network DNS resolver was never an IETF standard (or was it? Any
references?)

> The IETF is a place where we can and must have this discussion, so
> all parties can participate in understanding and mitigating the
> potential harm.

As I said above, people have different opinions. Some call "harm" what
some others call "privacy". Some people want to modify DNS requests
and responses, some does not want their requests and responses to be
modified. No amount of IETF discussion will solve this fundamental
tussle.

> providing ISPs with advice on deploying DoH.

I'm tempted to say that I don't see the point for an access network to
deploy DoH. If the network is safe, DoH is not really necessary
(paranoid may use DoT, since the access network can ensure that port
853 is clear). If it is not, for instance because the resolver
modifies the answers, then users will want to bypass it, anyway.

My guess is that DoH operators will be different from access network
operators.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Jul 2019 13:23:39 -0400

> I'm sorry, I think I'm confused. Where do you think the attacker is

This is actually an important question.
Apologies in advance for the length of this email.

There are basically four places an attacker can be positioned:

   1. on-path between the resolver and client
   2. off-path (attacking the resolver->client channel)
   3. on-path between an authority server and the resolver: DNS cache
   poisoning
   4. off-path (attacking the authority->resolver channel): DNS cache
   poisoning

Case 1 has already been discussed in this thread and/or is partially
addressable via encrypted communications, but is contingent on not being
impacted by cases 3 and 4.
Case 2 is mostly moot, since there is only a very limited window, no
predictability, and there is sufficient entropy to protect individual
query/answer pairs.
Case 3 turns NXDOMAIN injection into denial of service, IFF the resolver is
doing DNSSEC validation, but otherwise is basically impossible to defend
against.

Case 4 is the important one to understand and to consider the impact of use
of DNSSEC validation on both the resolver and on the client.

The ability to attack a resolver from off-path is largely a function of the
ability to send packets to that resolver, from both an apparent "client"
viewpoint and an apparent "authority" viewpoint.

This means that a public resolver is much more exposed to any poisoning
attack, unless it is defending against such attacks (e.g. by doing DNSSEC
validation).

The original Kaminsky attack was temporarily/partially mitigated by adding
more entropy (requiring more work, including number of packets which
translates to more bandwidth and CPU).

There are newer attacks which are substantially more effective (requiring
much less effort and potentially much larger "blast radius"), particularly
DNS fragmentation.

The only viable defense against Case 4 is DNSSEC.

It is important to understand the interaction between DNSSEC and a
resolver's cache, from the perspective of a client.
If the client validates but the resolver doesn't, the resolver might be
poisoned, and the client is effectively unable to reach hosts whose DNS
entry has been poisoned. (The poisoning is semi-permanent, for TTL length.)
If the client doesn't validate and the resolver doesn't validate, any
poisoned cache entries are used by the client, blindly.
If the client validates and the resolver validates, the cache will never
have any entries which fail validation by the client. The resolver will
reject responses that fail DNSSEC validation, and never cache them.

If the client does not validate, there is a conundrum: the client cannot
distinguish between a resolver that validates and one that does not. The
only way to detect a non-validating resolver is through the detection of
cache entries that fail DNSSEC validation.

The only logical position for a client with an arms-length relationship
with the resolver operator is: trust, but validate (always).

A validating resolver can only be blocked from getting valid responses by
an on-path attacker, where on-path is towards a particular authoritative
server. Authoritative zones served on disparate network paths, can
significantly reduce this risk.
A validating resolver cannot be blocked, and cannot be poisoned, by an
off-path adversary.

The only way to know a resolver is validating, demonstrably, is to have
client-side validation.

The interesting property of a validating resolver is, before it can return
an answer, it has to validate it, which requires chasing DNSSEC proofs
to/from the DNS root of trust.
This means, in turn, that when a validating resolver provides an answer, it
already has in its cache, everything required by a client for the client to
perform validation.
Performance optimization on obtaining all of that data is optional, but
certainly feasible.

Non-local, centralized DNS resolvers definitely should be doing validation.
Clients of those resolvers also should be validating the responses from
those resolvers.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 13:24:30 -0400

>> However, if the attacker is the resolver, and the resolver isn’t under the control of the path, then detecting a fake NXDOMAIN is useful. 

It allows me to notice that the resolver I have chosen is not trustworthy. If E.g. Firefox did this, it would make lying public DoH resolvers untenable.

I think there’s also a belief that PKI is so trustworthy that we need not backstop it. I think this is a mistake.

---

From: Andrew Campling <[email-masked]>
Date: Wed, 24 Jul 2019 17:26:53 +0000

>  Trust in the Internet infrastructure is a hard problem because the trust relationships are different depending on subjective judgements and preferences. One user might trust the application and di…

I think we should note that the third category, the “uneducated” user, is by far the largest, at least in the context of understanding matters such as DNS.  In addition, we should also note that, in the context of GDPR in Europe, DNS data is considered to be personal data and it will be possible for significant profiling to be carried out on the basis of this data; this may constrain what decisions can be made and by whom, at least without the knowledge and consent of the user.

>  The other face of this problem is the "control plan" discussion: DoH supporters claim that the DNS is not a proper control plan for the Internet, but then they do not provide alternatives to peopl…

It seems reasonable to assert that a control plane is required for operational purposes including, for example, to implement user choices and comply with local legislation.

>  While ADD already has more immediate points that deserve attention, such as the best practices for configuring Do* servers, it would be good if we could also have the architectural discussion abov…

I agree that the architectural discussion needs to be had too.

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Wed, 24 Jul 2019 17:28:23 +0000

>  In order to run an app, if the app is able to make https connections, you are forced to trust the app.   This is true whether you are aware that you are trusting it or not, and regardless of your…

Whilst not disputing the logic of being forced to trust the app, experience tells us that we are unwise to do so as there are sadly numerous instances where that trust is betrayed; I note for example the settlement today of the most recent Facebook privacy case in the US.  In a number (most?) cases where trust is betrayed, data monetisation appears to be a motivating factor and we should note that centralisation has the potential to magnify the data monetisation opportunity.

>  What DoH does, but what any app can do whether DoH is present or not, is to make it possible to trust someone other than your service provider.  Without some covert channel that the service provid…

The second sentence in this paragraph is incorrect – there are mechanisms that can provide the user with choice of DNS resolution without being covert, albeit also allowing the service provider to block the mechanism should it choose to do so.

>  We in the IETF do not have the ability to prevent the app from bypassing the ISP’s resolver.   It’s totally pointless to talk about whether or not we should do this.

Whilst the IETF might not have the ability to prevent abuses, I believe that it ought to avoid providing a standardised way of enabling these abuses if at all possible and, as a minimum, should ensure that it also provides mechanisms to allow the user (specifically the device administrator) to express their preferences and communicate those preferences to apps.  Published best practice should be that those preferences are respected by apps in all circumstances except where relevant regulations/legislation makes this impossible to do so legally.

Andrew

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Jul 2019 13:32:24 -0400

On Wed, Jul 24, 2019 at 1:15 PM Eric Rescorla <[email-masked]> wrote:

>> However, if the attacker is the resolver, and the resolver isn’t under
>> the control of the path, then detecting a fake NXDOMAIN is useful.
>>
>
> How?
>

Assumptions:

   1. One resolver is controlled by the attacker
   2. The path to the real endpoint is free from control by that same
   attacker
   3. Any other resolver, not controlled by that same attacker, is known

If the attacker's resolver supplies a fake NXDOMAIN, which the client
detects via DNSSEC, then the client sees the resolver's answer as a
SERVFAIL.
The client then consults a different resolver, and gets a non-NXDOMAIN
answer (validated by DNSSEC), and connects to the correct host.
Since the attacker does not control the data path to the correct host, the
client's connection succeeds.

QED (useful).

Brian

---

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

On Wed, Jul 24, 2019 at 10:32 AM Brian Dickson <
[email-masked]> wrote:

> This last possibility seems like a pretty narrow case. In the vast
majority of cases, clients have one path to the network.

It's a little surprising to be hearing resistance to local resolver
blocking being cited as a goal here, given that previously I've heard
complaints that DoH (which is effectively a separate path to another
resolver) is a mechanism for circumventing exactly this kind of blocking.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Jul 2019 13:56:27 -0400

> resolver) is a mechanism for circumventing exactly this kind of blocking.
I think you are misinterpreting the meaning of "controlled by". I.e.
"operated by", "subverted by", "poisoned by", "subverted by" (an attacker).

It has nothing to do with the path, to either the destination endpoint, or
to either resolver.

For example, suppose the client knew about 9.9.9.9 and 8.8.8.8, and
preferred 8.8.8.8.
If 8.8.8.8 was compromised and injecting (responding to queries with) false
NXDOMAIN answers in a DNSSEC-signed domain, the client would detect that,
and would then query 9.9.9.9.
Since (by the assumptions above) 9.9.9.9 is not compromised, it would
return a non-NXDOMAIN (legitimate, DNSSEC-signed) answer.

Brian

>> Since the attacker does not control the data path to the correct host,
>> the client's connection succeeds.
>>
>> QED (useful).
>>
>> Brian
>>
>>
>

---

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

On Wed, Jul 24, 2019 at 10:56 AM Brian Dickson <
[email-masked]> wrote:

> If 8.8.8.8 was compromised and injecting (responding to queries with)
> false NXDOMAIN answers in a DNSSEC-signed domain, the client would detect
> that, and would then query 9.9.9.9.

This also seems like an edge case. The vast majority of clients do not have
two independently controlled resolvers.

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 19:23:23 +0100

> On 24 Jul 2019, at 18:45, Eric Rescorla <[email-masked]> wrote:
> 
> I've heard complaints that DoH (which is effectively a separate path to another resolver) is a mechanism for circumventing exactly this kind of blocking.

I think those complaints are about the way one browser vendor has decided to deploy DoH, not the protocol itself.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2019 14:18:59 -0400

Eric Rescorla <[email-masked]> wrote:
    > NXDOMAIN, 

    > have an IP address to connect to, so it's only recourse is to error
    > out. Now, it can show the user a different error than it did for
    > NXDOMAIN, but these errors tend to be fairly generic anyway (Firefox,
    > for instance, shows "Hmm.  We’re having trouble finding that site."),
    > so from the user perspective these 
    > aren't really very different.

This needs to be an on-path attacker who can not only inject a fake NXDOMAIN,
but also suppress/delete the legitimate answers.

This means it is the "coffee" shop that is doing the attack.
When the coffee shop is a soveign country, then there are many things that
they can also do which DoH/DoT may or not help with.

When this is an off-path attacker, DNSSEC enables successful connections
(that HTTPS can validate) vs "Having trouble" dialogues.

-- 
]               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: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 14:20:55 -0400

On Jul 24, 2019, at 2:10 PM, Eric Rescorla <[email-masked]> wrote:
> This also seems like an edge case. The vast majority of clients do not have two independently controlled resolvers.

That sounds like a problem statement.

But it’s really easy to configure two resolvers.   Just put two IP addresses in the dialog box.   The stub resolver, if it is following the standard, will consult both, particularly when one fails.

---

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

On Wed, Jul 24, 2019 at 11:20 AM Ted Lemon <[email-masked]> wrote:

> This also seems like an edge case. The vast majority of clients do not
> have two independently controlled resolvers.
>
>
> But it’s really easy to configure two resolvers.   Just put two IP
> addresses in the dialog box.   The stub resolver, if it is following the
> standard, will consult both, particularly when one fails.
>

What dialog box? The case of interest here is when the client gets its
resolver via DHCP

-Ekr

---

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

> but also suppress/delete the legitimate answers.

Yes.

> they can also do which DoH/DoT may or not help with.

Sure.

> (that HTTPS can validate) vs "Having trouble" dialogues.

Yes. However, DoH/TRR also prevents these attacks.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 14:38:49 -0400

On Jul 24, 2019, at 2:36 PM, Eric Rescorla <[email-masked]> wrote:
> What dialog box? The case of interest here is when the client gets its resolver via DHCP

I must have missed something.   When was it stated that we were only considering this use case?

That said, if an ISP offers 8.8.8.8 and 1.1.1.1 as resolvers, and one is compromised while the other is not, DNSSEC validation will definitely detect this situation and mitigate it.

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 19:41:40 +0100

> On 24 Jul 2019, at 19:36, Eric Rescorla <[email-masked]> wrote:
> 
> What dialog box?

This one (MacOSX). I understand similar functionality is available on other platforms.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2019 14:51:23 -0400

Eric Rescorla <[email-masked]> wrote:
    mcr> This needs to be an on-path attacker who can not only inject a fake
    mcr> NXDOMAIN,
    mcr> but also suppress/delete the legitimate answers.
    
    ekr> Yes.

That seriously limits the threat model that is being defended against,
doesn't it?   I think that people are feeling hostile because I think
that the threat model that Mozilla really wishes to defend against
*is* soveign countries, not off-path attackers in a coffee shop.
I don't mind: I'm all for that actually, but it means that maybe the
coffee shop operator (or Enterprise infrastructure) might sometimes be
allies.

    mcr> This means it is the "coffee" shop that is doing the attack.
    mcr> When the coffee shop is a soveign country, then there are many things
    mcr> that
    mcr> they can also do which DoH/DoT may or not help with.
    
    eki> Sure.

    mcr> When this is an off-path attacker, DNSSEC enables successful
    mcr> connections 
    mcr> (that HTTPS can validate) vs "Having trouble" dialogues.
    
    > Yes. However, DoH/TRR also prevents these attacks.

DoH prevents the attack from occuring between the browser and
the DoH server.

It does not prevent it from the DoH server and the authoritative resolver,
unless the DoH server also does DNSSEC, and the authoritative resolver
runs DNSSEC.  Or the DoH server speaks DoH to the authoritative resolver,
(and the root name servers, and the com nameservers...)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2019 12:09:48 -0700

> This one (MacOSX). I understand similar functionality is available on
Yes. We're focusing on the common case in which people do not use this
dialog box.

-Ekr

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 16:17:08 -0400

On Wed, Jul 24, 2019 at 06:19:09AM -0400,
 Joseph Lorenzo Hall <[email-masked]> wrote 
 a message of 86 lines which said:

> For example, the privacy policy of 1.1.1.1 is pretty amazing from
> the perspective of data retention, secondary uses, etc. (e.g., I
> know my resolutions will be removed from their logs within 24
> hours).

I'm sure you know it but let's repeat anyway: promises are just
promises. There is no technical way to check they are enforced. (Same
thing for the ISP's promises.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 16:19:56 -0400

On Wed, Jul 24, 2019 at 07:42:01AM -0400,
 Bret Jordan <[email-masked]> wrote 
 a message of 171 lines which said:

> Especially when the query is over http and can easily allow extra
> headers so the end user can be fully tracked.

There is a draft about that, asking for a specific profile for DoH,
draft-dickinson-doh-dohpe.

I observe there was no real interest for it. Too bad, I would prefer
people work on concrete issues like this one.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 16:41:44 -0400

On Wed, Jul 24, 2019 at 02:56:15AM +0100,
 Jim Reid <[email-masked]> wrote 
 a message of 16 lines which said:

> things "secure". It just changes the security landscape by swapping
> one set of concerns for another. A cynic (or realist) would say
> they'd just replaced one DNS resolver they probably didn't/shouldn't
> trust to another that isn't necessarily more trustworthy.

On the Internet, we often have to make decisions about who to
trust. We decide to register a .com or a .cctld, we decide to use
Signal or Telegram, we decide to do searches at Google or at
DuckDuckGo, etc. Sometimes, we make wrong assessments but I disagree
with the nihilist view that "everything is rotten, there is no point
in choosing the provider".

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 21:48:21 +0100

> On 24 Jul 2019, at 21:41, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> I disagree with the nihilist view that "everything is rotten, there is no point

Nobody has expressed that view.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 24 Jul 2019 16:40:31 -0700

On Wed, Jul 24, 2019 at 4:53 AM <[email-masked]> wrote:

> This is a good point; there are valid reasons why 1.1.1.1 can be the right
> provider for some users. Please allow me to clarify some possible
> misunderstandings.
>
>
>
> I’m not against DoH.
>
> These are all valuable things we should strive for. Let’s do it in a way
> that works for everyone, by identifying and documenting best practice.
>

I think the issue is that this request for collaboration can be viewed as a
request to undermine DoH with follow-up RFCs.

I understand that people come to the IETF with many different viewpoints,
so I don't see this disconnect as a problem. But it is worth pointing out,
and trying to understand.

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Jul 2019 22:18:58 -0400

On Wed, Jul 24, 2019 at 7:40 PM Rob Sayre <[email-masked]> wrote:

>> This is a good point; there are valid reasons why 1.1.1.1 can be the
>> right provider for some users. Please allow me to clarify some possible
>> misunderstandings.
>>
>>
>>
>> I’m not against DoH.
>>
> I think the issue is that this request for collaboration can be viewed as
> a request to undermine DoH with follow-up RFCs.
>

I'll jump in ...

There are some generally positive benefits to having some (but certainly
not all) applications speak DNS natively.
(The precedent of mail transport software doing its own DNS is a good
example, including understanding why: mail software needs direct access to
e.g. MX, SPF, DMARC, and DKIM records, and to a lesser degree, PTR.)

In particular, having some applications be able to request record types
other than A/AAAA/PTR via POSIX interface (getaddrinfo/gethostby* calls) is
an important benefit; doing DNS more directly avoids having to address the
whole POSIX API thing. (That can be done at a later date, or not at all.)

Speaking "DNS" facilitates lots of very useful use cases to applications,
in particular to browsers, that are not otherwise feasible today. (E.g.
DNSSEC validation, DANE records, HTTPSVC, etc.)

However, there is no specific requirement that these applications "doing"
DNS need to bypass the ENTIRE host OS' DNS stack or avoid using other
host-local DNS services/mechanisms.
E.g. it would be reasonable to have a local forwarding-only caching server
(which forwards to a full-feature resolver, using an unspecified
transport), which better scaling attributes including cache hits, and
avoids divergent application-specific resolution including different
choices of full-feature resolver.

Also, privacy can be implemented on that caching server, by either of DoT
or DoH. There is approximately zero trade-off between the two (DoH vs DoT),
other than the larger issues (monitoring/filtering DNS resolver
destinations at a network level).

NB: the new DNS RFC for DNS stateful operations (DSO, DNS Stateful
Operations) covers a lot of the details on how clients and servers can
optimize their interactions, including (IIRC) some DoT guidance.

Some of the concerns regarding how to resolve the natural tension between
user choice, and client (host) administration, is probably better handled
by having the "user" choice be restricted (by design) to admin-priv
operations.

I would definitely prefer that DoT be the solution of choice for privacy,
primarily because it avoids almost all of the pitfalls of DoH when it comes
to any environment that relies on DNS-based security and monitoring.

There is a place for DoH, but I don't believe it should see wide deployment
in general-purpose browsers.

I have yet to see any use case other than the very specific "dissidents"
used to justify DoH.

All of the testing (which I've basically just glanced at as summary info)
suggests that DoH and DoT perform very similarly.

And, finally, from what I understand, all of the major public resolver
operators offer their services on both DoT and DoH (and v4 and v6, and in
many cases with or without filtered results).

So, in my version of a perfect world, the integrated browser DNS stack
would be:
browser <-> (local/internal loopback-type interface) <-> caching DNS
forwarder <-> (DoT) <-> {enterprise | home | public} full recursive resolver
And the browser would speak native DNS, with DNSSEC validation, DANE
support (natively, not plug-in), HTTPSSVC, CNAME/DNAME following, etc.
The caching DNS forwarder would have all the same stuff plus DNS cookies,
not do fragmentation, and potentially have multiple full resolvers
configured in a structured priority flow (not just round robin).

IMHO, this is what ADD is supposed to be about, discussion the what and the
how.

And, also IMHO, it does not preclude comparison of DoT and DoH on the
respective merits and risks/costs.

Brian
P.S. Any animosity towards DoH has very little to do with the process by
which it was developed, and everything to do with the incompatibility with
existing practices and ecosystems, especially unintended impacts. It isn't
the encapsulation of DoH that is the problem (it's slightly annoying), but
rather the re-use of port 443 instead using a dedicated port the way DoT
uses 853.

P.P.S. The responsible approach to adopting a flawed protocol, would be to
acknowledge the flaws, find a better solution, and kill it off, rather than
defend it or justify it based on sunk cost or other rationales. I would
advocate this approach even if it was my sacred cow that was being gored.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 24 Jul 2019 19:30:31 -0700

Hi Brian,

I'm not sure what you're trying to say.

thanks,
Rob

On Wed, Jul 24, 2019 at 7:19 PM Brian Dickson <[email-masked]>
wrote:

> There is a place for DoH, but I don't believe it should see wide
> deployment in general-purpose browsers.
>
> IMHO, this is what ADD is supposed to be about, discussion the what and
> the how.
>

---

From: <[email-masked]>
Date: Thu, 25 Jul 2019 02:38:05 +0000

This proposal has a lot going for it: no fragmentation of DNS configuration at the app level, just one lot of settings in the client device’s caching forwarder, with secure transport outside the device, and full validation.

Seems like a good start.

From: Brian Dickson <[email-masked]>
Sent: 24 July 2019 22:19
To: Rob Sayre <[email-masked]>
Cc: Box,C,Chris,TLW1 R <[email-masked]>; [email-masked]
Subject: Re: [Add] fixing coffee shop brokenness with DoH

[snip]

browser <-> (local/internal loopback-type interface) <-> caching DNS forwarder <-> (DoT) <-> {enterprise | home | public} full recursive resolver
And the browser would speak native DNS, with DNSSEC validation, DANE support (natively, not plug-in), HTTPSSVC, CNAME/DNAME following, etc.
The caching DNS forwarder would have all the same stuff plus DNS cookies, not do fragmentation, and potentially have multiple full resolvers configured in a structured priority flow (not just round robin).

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Jul 2019 03:40:41 +0100

> On 25 Jul 2019, at 00:40, Rob Sayre <[email-masked]> wrote:
> 
> I think the issue is that this request for collaboration can be viewed as a request to undermine DoH with follow-up RFCs.

I fail to understand how anyone could possibly hold that view.

The core DoH protocol is done. It's not going to be changed in the forseeable future. If the IETF decides to do further work, it's most likely to be on the operational and deployment aspects of DoH. Or maybe document the security/privacy trade-offs. That wouldn't "undermine DoH" because the effort should focus on how to make best use of DoH and deploy it effectively.

---

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

On Wed, Jul 24, 2019 at 7:38 PM <[email-masked]> wrote:

> This proposal has a lot going for it: no fragmentation of DNS
> configuration at the app level, just one lot of settings in the client
> device’s caching forwarder, with secure transport outside the device, and
> full validation.
>

Well, I'm still not sure why this is a good idea, but I have an open mind.
I do think like minds should focus their energies there.

One of the nice things about the Internet is that there are no limits. Just
go try that idea out. :)

thanks,
Rob

---

From: Petr Špaček <[email-masked]>
Date: Wed, 24 Jul 2019 23:35:09 -0400

On 24. 07. 19 13:14, Eric Rescorla wrote:
> 
> 
> On Wed, Jul 24, 2019 at 9:00 AM Jim Reid <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     > On 24 Jul 2019, at 16:11, Eric Rescorla <[email-masked]
>     <mailto:ekr@rtfm..com>> wrote:
>     >
>     Not really. A validation failure is a fairly strong indication that
>     the resolver is lying to you.
> 
> 

Could you please elaborate why you believe so?

According to APNIC measurements, any site which has DNSSEC-related
problem will become unreachable for > 20 % of Internet users [0]. In my
coutry (CZ), more than 60 % of users are behind a DNSSEC-validating
resolver [1].

As far as I can tell, telco support lines are not ringing because of DNSSEC.

What data indicate some DNSSEC-related breakage?

Thank you.

[0] https://stats.labs.apnic.net/dnssec/XA
[1] https://stats.labs.apnic.net/dnssec/CZ

Petr Špaček  @  CZ.NIC

>     resolver can't be trusted (or is at the very least suspcious) and
>     take suitable countermeasures. That's what I meant by "act accordingly".
> 
>

---

From: Neil Cook <[email-masked]>
Date: Thu, 25 Jul 2019 08:57:21 +0100

Stephane,

> On 24 Jul 2019, at 17:59, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Running a public resolver takes a large amount of money and time, with no monetary reward for your efforts. Very few companies can afford to do that. Thus it seems far more likely that we’ll end up with a small number of dominant players as Jim suggests.

But let’s say I decide to run my own non-public DoH  resolver on my network at home. Firefox won’t have it on their list of TRRs, and if as you suggest, the discovery drafts are pointless and so don’t proceed, no application will ever find out about it, unless I configure it manually on every single application and computer in my house (not even mentioning those IoT devices that I can’t configure). 

It is also possible that we end up with a large number of public DoH resolvers which mine your personal data for profit. Given the current business model of the internet that is entirely possible. 

Neil

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: Normen Kowalewski <[email-masked]>
Date: Thu, 25 Jul 2019 10:45:55 +0200

Hi Lorenzo,

AFAIK use of DoT - if found - is default used as DNS protocol choice in Android 9 (Pie) out of the box
https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html

Hint: Ideally that and implementation details are best confirmed by folks on this here list who coded this ;-) 

Google/Jigsaw INTRA was done to do purely DoH
https://github.com/Jigsaw-Code/Intra says: "An experimental tool that allows you to test new DNS-over-HTTPS services on Android “

Its most recent update added a user managed per application exception function for local apps that don’t like their DNS to be redirected through DoH 

BR, 
Normen

> On 24. Jul 2019, at 16:03, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> 
> 
> On Wed, Jul 24, 2019 at 9:05 AM Vittorio Bertola <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Il 24 luglio 2019 12:19 Joseph Lorenzo Hall <[email-masked] <mailto:[email-masked]>> ha scritto:
>> 
>> 
>> 
>> 
>> On Tue, Jul 23, 2019 at 22:26 Tommy Jensen <Jensen.Thomas= 40microsoft.com@dmarc..ietf.org <mailto:[email-masked]>> wrote: 
>> Tone aside, to some users, centralization is a benefit in that they don't have a bunch of unknown privacy policies applying to the resolution of the names they need. For example, the privacy policy of 1.1.1.1 is pretty amazing from the perspective of data retention, secondary uses, etc. (e..g., I know my resolutions will be removed from their logs within 24 hours)..
>> 
> These are good points.... in the case I'm talking about it's definitely having user choice, having understandable privacy policies (to people like me, not end-users necessarily), and having usable ways of turning this on (e.g., the 1.1.1.1 app from Cloudflare or the Intra app from Google for older Android to use DoT).
>  
> So true... We're actively working on generic data protection laws in the USA, wish us luck! best, Joe
> 
> -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Joe Abley <[email-masked]>
Date: Thu, 25 Jul 2019 01:49:59 -0700

On Jul 24, 2019, at 20:10, Eric Rescorla <[email-masked]> wrote:

> This also seems like an edge case. The vast majority of clients do not have two independently controlled resolvers..

Some experiments by APNIC Labs demonstrate a significant population of
stub resolvers that have google public DNS configured as one of
multiple independently-operated resolvers. It was more common than I
was expecting.

I don't know of any experiments that test the general case (I don't
*think* APNIC's experiment did, and maybe Google is special), but it
may make sense to support your statement above with data if it turns
out to be an important assumption.

Joe

---

From: Normen Kowalewski <[email-masked]>
Date: Thu, 25 Jul 2019 12:03:20 +0200

Hi Joe,

i am not surprised; I have seen many configs / resolv.conf contain dual “own policy rDNS” plus an extra one being public.

Basically, own rDNS preferred, since its local and fastest especially if the namespace i rather limited, and its hopefully also most secured from admin perspective,
but in case own is for some reason screwed, you will use public as the second best choice. 
So in this case, folks accept to relinquish local policies (and the privacy aspect of terminating their queries on a server whose policy they know and accept), in exchange for still being able to at least get to the internet.

I personally believe its wrong to blindly configure stuff like that, because i that policy is in many cases pretty important, ah, well… .

@Paul, can you possibly help me to understand some stats on this that your likely quite familiar with:  
i am looking at slide 6 of the IETF 104 presented measurement here: https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01 

Is that that is all dns as a whole i guess (IIUC this is a mix of large providers of Authoritative DNS, and large public rDNS)
How would this diagram change if zooming in purely on customer rDNS use? 

BR, Normen  

> On 25. Jul 2019, at 10:49, Joe Abley <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jul 2019 04:57:07 -0700

> What data indicate some DNSSEC-related breakage?

The concern isn't misconfigured zones but rather middleboxes that strip
RRSIGs or otherwise
invalidate the DNSSEC signatures, so these measurements, which primarily
measure whether
the recursive resolver has a clear path, are not really that relevant.

This hasn't been directly measured in some years, but here's AGL's post on
this from 2015
https://www.imperialviolet.org/2015/01/17/notdane.html

I'd certainly be interested in some evidence that this kind of problem has
gone away, but
it probably won't be us who takes it.

-Ekr

---

From: Paul Ebersman <[email-masked]>
Date: Thu, 25 Jul 2019 09:18:54 -0400

ekr> Well, this is true, but in the Web context, as we move towards 100%
ekr> HTTPS, the importance of getting the right IP starts to decrease
ekr> quite a bit: if you get the wrong IP address, then this turns into
ekr> a connection failure.

And the web is a significant use case/population, but DoT (and maybe
DoH) and DNSSEC are useful for server to server, IoT, etc. (or should be
used). And the trend is definitely to more connected devices that aren't
human but that we don't want BOT'ed or lied to or spied on.

Let's make sure that we're not conflating the web and the internet as
the same thing.

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Jul 2019 14:23:23 +0100

> On 25 Jul 2019, at 14:18, Paul Ebersman <[email-masked]> wrote:
> 

+1

---

From: Petr Špaček <[email-masked]>
Date: Thu, 25 Jul 2019 09:54:25 -0400

On 25. 07. 19 7:57, Eric Rescorla wrote:
> 
> 
> On Wed, Jul 24, 2019 at 8:33 PM Petr Špaček <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >
>     >
>     >     > On 24 Jul 2019, at 16:11, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>
>     >     <mailto:ekr@rtfm. <mailto:ekr@rtfm.>.com>> wrote:
>     >     >
>     >     > See my response to Ted. From the perspective of the client,
>     acting
> This hasn't been directly measured in some years, but here's AGL's post
> on this from 2015
> I'd certainly be interested in some evidence that this kind of problem
> has gone away, but

Understood, so it is worry about transport, which should be solved by
DoH, right?

What kind of non-clear path problem you are expecting in DoH channel
from Firefox to a recursive of your choice?

Petr Špaček  @  CZ.NIC

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Jul 2019 10:11:52 -0400

On 7/25/19 03:57, Neil Cook wrote:
> But let’s say I decide to run my own non-public DoH  resolver on my 
> network at home. Firefox won’t have it on their list of TRRs, and if 
> as you suggest, the discovery drafts are pointless and so don’t 
> proceed, no application will ever find out about it, unless I 
> configure it manually on every single application and computer in my 
> house (not even mentioning those IoT devices that I can’t configure).
>
> It is also possible that we end up with a large number of public DoH 
> resolvers which mine your personal data for profit. Given the current 
> business model of the internet that is entirely possible.

Since you mention Firefox's TRR list and then mention data mining (with 
an implied connection), I'd like to point out yet again that one of the 
key criteria for appearing on that list is an agreement to treat 
resolution data according to a strict set of privacy-protecting 
provisions. You can see, for example, Cloudflare's associated privacy 
policy at 
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

I'm going to pre-reply to a frequent response that the lack of direct 
contractual relationship between users and Cloudflare is problematic. 
Even if you don't trust Mozilla's contractual agreement with Cloudflare 
to provide protection here, I would think that FTC v. Facebook (2019) 
[1] should serve as a pretty vivid illustration of what happens when a 
US company operates outside its published privacy policy.

/a

____
[1] 
https://www.ftc.gov/news-events/press-releases/2019/07/ftc-imposes-5-billion-penalty-sweeping-new-privacy-restrictions

---

From: Neil Cook <[email-masked]>
Date: Thu, 25 Jul 2019 15:16:16 +0100

Adam,

JFYI no connection was implied. I deliberately put the comment about data mining in a separate paragraph, and said “it is also possible”.

Neil

> On 25 Jul 2019, at 15:11, Adam Roach <[email-masked]> wrote:
> 
> Since you mention Firefox's TRR list and then mention data mining (with an implied connection), I'd like to point out yet again that one of the key criteria for appearing on that list is an agreement to treat resolution data according to a strict set of privacy-protecting provisions. You can see, for example, Cloudflare's associated privacy policy at https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/
> 
> I'm going to pre-reply to a frequent response that the lack of direct contractual relationship between users and Cloudflare is problematic. Even if you don't trust Mozilla's contractual agreement with Cloudflare to provide protection here, I would think that FTC v. Facebook (2019) [1] should serve as a pretty vivid illustration of what happens when a US company operates outside its published privacy policy.
> 
> /a
> 
> ____
> [1] https://www.ftc.gov/news-events/press-releases/2019/07/ftc-imposes-5-billion-penalty-sweeping-new-privacy-restrictions
> 

Neil Cook

European Office: 

US Office:

---

From: Paul Ebersman <[email-masked]>
Date: Thu, 25 Jul 2019 10:21:34 -0400

jreid> Not really. A validation failure is a fairly strong indication
jreid> that the resolver is lying to you.

ekr> Not really, no. Our current belief is that there is going to be
ekr> quite a high rate of non-malicious validation failures.

What's the basis of this belief?

When I was at comcast, query volumes on recursive were on order 500
billion q/day and hard/persistant DNSSEC failures were on order of
dozens per month, so that seems like a pretty high success rate.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jul 2019 07:29:05 -0700

> dozens per month, so that seems like a pretty high success rate.

See my previous message. This is about middleboxes interfering with the DNS
queries, which would not be visible to you from the vantage point of
comcast's recursive resolver.

-Ekr

---

From: Paul Ebersman <[email-masked]>
Date: Thu, 25 Jul 2019 10:40:38 -0400

ebersman> What's the basis of this belief?
     
ebersman> When I was at comcast, query volumes on recursive were on
ebersman> order 500 billion q/day and hard/persistant DNSSEC failures
ebersman> were on order of dozens per month, so that seems like a pretty
ebersman> high success rate.

ekr> See my previous message. This is about middleboxes interfering with
ekr> the DNS queries, which would not be visible to you from the vantage
ekr> point of comcast's recursive resolver.

Sorry. Volume of list has been a bit poisonous and my mail reader
threading is barely coping. ;)

So your assertion is that there will be enough middleware boxes breaking
DNSSEC and not handing a complete RRSET w/sigs, etc. that this will be
the prevalent case?

While I'd agree that many/most captive portal environments break DNSSEC
(and pretty much everything else), most other recursive servers tend to
honor the DO bit and send all records. I'm not so sure that most DNSSEC
responses will be broken.

While DNSSEC isn't a magic solution to everything, it is a useful
solution to some of the problem space. When it works, it gives clearly
secure answers.

I do agree with you that if you do get some failure that isn't a DNSSEC
validated success, just dropping the connecting is a reasonable action.

But while it may be the expectations in browsers that ultimately, fast
is more important than right, for non-web, right/secure is worth
pursuing even at the cost of a bit of latency in the response.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jul 2019 07:47:07 -0700

> DNSSEC and not handing a complete RRSET w/sigs, etc. that this will be

No. Rather that it will be sufficiently common that breakage is not a
reliable indicator of attack and that therefore it is not viable for mass
market end-user software to discard responses which are bogus according to
DNSSEC.

For context, our breakage budget here is very small: any change to clients
which causes connection error rates to increase by more than fractions of a
percent is not really something we can deploy.

-Ekr

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 25 Jul 2019 16:51:18 +0200 (CEST)

> Il 25 luglio 2019 16:11 Adam Roach <[email-masked]> ha scritto:
> 

However, privacy policies by private companies can be overridden by laws and other juridical instruments within the applicable jurisdiction, forcing the operator to give access to data to national law enforcement and security agencies (in the US, that is especially easy for non-US citizens). Same for other parts of your TRR clauses - you may commit not to block anything, but if President Trump shows up with an order that requires blocking DNS resolution for the domain name of a specific foreign company (a case that, honestly, does not seem so unlikely), you will be forced to implement it no matter what you think.

This is not meant to challenge your commitment to privacy, but it's just how it is, and it is the reason why people in other parts of the world - even the privacy activists that dislike their local network and would love to get an alternative - are not too happy with your declared approach of redirecting queries by default to a different jurisdiction that, in their view, offers less privacy protection than their own.

--

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Jul 2019 10:59:55 -0400 (EDT)

On Thu, 25 Jul 2019, Eric Rescorla wrote:

> For context, our breakage budget here is very small: any change to clients which causes connection error
> rates to increase by more than fractions of a percent is not really something we can deploy.

What percentage of hijacked connections due to maliciously modified DNS
is within your breakage budget? In other words, how do you balance security
versus user convenience? A certificate that has expired only two hours
ago seem to be fine to hard fail on. But a broken DNS transport is not?

There is a bit of interaction here. People messing (or neglecting)
their DNS of endusers might do this less if they get flagged in common
browsers for doing so. Of course I symphatize with you that you do not
want that to become your problem. But how long are we kicking this
can down the road?

Everything on the internet should be authenticated. We keep delaying
this as a hard requirement for DNS only, for increasingly less convincing
reasons.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2019 11:08:15 -0400

> ago seem to be fine to hard fail on. But a broken DNS transport is not?

I agree.
I wish it was Applications Doing DNSSEC, and DNSSEC-over-HTTPS/TLS.

It seems that once it's in the Application, that doing DNSSEC intelligently
is much easier.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 25 Jul 2019 11:16:22 -0400

On Thu, Jul 25, 2019 at 10:29 AM Eric Rescorla <[email-masked]> wrote:

> See my previous message. This is about middleboxes interfering with the
> DNS queries, which would not be visible to you from the vantage point of

I'm confused by this reference to middleboxes and DNS.

The presumed use case is Do* (DoH/DoT), where the middleboxes only see TLS
traffic, and absolutely have no ability to inspect or interfere with the
contents of DNS packets within those connections.

If we remove the middlebox from the equation, how then do you maintain the
belief that "there is going to be quite a high rate of non-malicious
validation failures"?

The other messages in this thread indicate an extremely low rate of DNSSEC
failures.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jul 2019 08:16:48 -0700

I think we're now entering territory that we've gone over before and that
is largely off topic for this list. so I'm going to opt not to revisit it.

-Ekr

---

From: Andrew Campling <[email-masked]>
Date: Thu, 25 Jul 2019 15:19:27 +0000

Adam
You rightly mention the protections offered by the Cloudflare privacy policy and Mozilla's contract with Cloudflare.  The topical reference to Facebook should serve as a timely reminder about the growing importance of privacy as well as a useful illustration that well-intentioned privacy policies can often be by-passed or undermined.

Given your comment to Neil, I think that it would be incredibly helpful to have your thoughts on the following points:

•       Will all resolvers accessible within Mozilla's TRR policy have a contractual relationship with the company to provide this additional layer of protection?
•       In Europe, DNS constitutes personal data and therefore needs to be processed in compliance with GDPR - I didn't notice a direct reference to this in the privacy policies, apologies if I've missed it;
•       For non-US citizens "reasonably believed to be outside the US", FISA Section 702 of course overrides the stated privacy policies of both Mozilla and Cloudflare (this is not a criticism, simply a clarification), has global reach when combined with the Cloud Act.

I think we should all bear in mind that DoH does of course have the potential to provide a contiguous, device level fingerprint to the DoH resolver, is a backward step for privacy in that regard vs both DoT and DNS53.  In my view this does helpfully illustrate that encryption and privacy are not synonymous – no doubt others will have their own views.

Andrew

-----Original Message-----
From: Adam Roach <[email-masked]>
Sent: 25 July 2019 15:12
To: Neil Cook <neil.cook=[email-masked]>; Stephane Bortzmeyer <[email-masked]>
Cc: Jim Reid <[email-masked]>; [email-masked]; Rob Sayre <[email-masked]>
Subject: Re: [Add] meeting hum: should the IETF take up this work?

I'm going to pre-reply to a frequent response that the lack of direct contractual relationship between users and Cloudflare is problematic.
Even if you don't trust Mozilla's contractual agreement with Cloudflare to provide protection here, I would think that FTC v. Facebook (2019) [1] should serve as a pretty vivid illustration of what happens when a US company operates outside its published privacy policy.

/a

____
[1]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jul 2019 08:20:32 -0700

> The other messages in this thread indicate an extremely low rate of DNSSEC

This thread has gotten quite long and hard to track. I was talking about
the case where DoH was not present, and my point was that DNSSEC is not a
replacement for DoH in the settings I am concerned with.

I agree that DoH potentially makes end-user software DNSSEC validation
viable, and that's something that at some point we might look at.

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Jul 2019 11:28:07 -0400

> This is not meant to challenge your commitment to privacy, but it's just how it is, and it is the reason why people in other parts of the world - even the privacy activists that dislike their local…
Sure. That's a different objection than the surveillance capitalism 
concern that I was responding to, and I'm not sure there's *any* 
jurisdiction on the planet that is immune from such concerns [1] [2] [3] 
[4].

In terms of worries about queries from citizens of EU countries being 
sent to servers that are subject to US jurisdiction: we don't have 
immediate plans to implement DNS-over-HTTPS (DoH) in Firefox outside of 
North America. We are currently exploring potential DoH partners in 
Europe that would be employed for the benefit of European users.

/a ____ [1] 
https://edri.org/italy-anti-terrorism-decree-strengthen-government-surveillance/

[2] 
https://www.thetrumpet.com/17338-germany-can-legally-spy-on-its-own-citizens

[3] https://qz.com/92648/think-us-snooping-is-bad-try-italy-india-or-canada/

[4] 
https://www.justsecurity.org/36098/era-mass-surveillance-emerging-europe/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Jul 2019 16:28:39 +0100

Hiya,

On 25/07/2019 16:19, Andrew Campling wrote:
> In Europe, DNS constitutes personal data and therefore needs to be 
> processed in compliance with GDPR
Sorry, it's not clear to me what you mean there.

It's also not clear to me that the act of answering a DNS
query is something where there's a specific way to comply
with GDPR or not comply with GDPR.

Can you provide a pointer to something with more detail
as to GDPR requirements for DNS recursive resolvers?

Thanks,
S.

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Jul 2019 11:32:26 -0400

See my response to Vittorio, which I think addresses your points.

/a

On 7/25/19 11:19, Andrew Campling wrote:
> *Adam*
> You rightly mention the protections offered by the Cloudflare privacy 
> policy and Mozilla's contract with Cloudflare.  The topical reference 
> to Facebook should serve as a timely reminder about the growing 
> importance of privacy as well as a useful illustration that 
> well-intentioned privacy policies can often be by-passed or undermined.
> Given your comment to Neil, I think that it would be incredibly 
> helpful to have your thoughts on the following points:
>
>   * Will all resolvers accessible within Mozilla's TRR policy have a
>     contractual relationship with the company to provide this
>     additional layer of protection?
>   * In Europe, DNS constitutes personal data and therefore needs to be
>     processed in compliance with GDPR - I didn't notice a direct
>     reference to this in the privacy policies, apologies if I've
>     missed it;
>   * For non-US citizens "reasonably believed to be outside the US",
>     FISA Section 702 of course overrides the stated privacy policies
>     of both Mozilla and Cloudflare (this is _not_ a criticism, simply
>     a clarification), has global reach when combined with the Cloud Act.
>
> I think we should all bear in mind that DoH does of course have the 
> potential to provide a contiguous, device level fingerprint to the DoH 
> resolver, is a backward step for privacy in that regard vs both DoT 
> and DNS53.  In my view this does helpfully illustrate that encryption 
> and privacy are not synonymous – no doubt others will have their own 
> views.
> *Andrew *
> Since you mention Firefox's TRR list and then mention data mining 
> (with an implied connection), I'd like to point out yet again that one 
> of the key criteria for appearing on that list is an agreement to 
> treat resolution data according to a strict set of privacy-protecting 
> Even if you don't trust Mozilla's contractual agreement with 
> Cloudflare to provide protection here, I would think that FTC v. 
> Facebook (2019) [1] should serve as a pretty vivid illustration of 
> what happens when a US company operates outside its published privacy 
> policy.
> /a
> ____
> [1]

---

From: Andrew Campling <[email-masked]>
Date: Thu, 25 Jul 2019 15:39:30 +0000

On Thu, Jul 25, 2019 at 4:21 PM Eric Rescorla <ekr@rtfm..com<mailto:[email-masked]>> wrote:

> This thread has gotten quite long and hard to track. I was talking about the case where DoH was not present, and my point was that DNSSEC is not a replacement for DoH in the settings I am concerned with.

> I agree that DoH potentially makes end-user software DNSSEC validation viable, and that's something that at some point we might look at.

Presumably this applies do both DoT and DoH Eric?

As someone said during the DoH discussion at the ICANN conference in Marrakesh last month, “DoT and DoH give you a hardened pipe, don’t stop you drawing poisoned water from the lake; DNSSEC reassures you that the water is safe” (or something very close to that).  I thought that was a useful analogy to highlight why the combination of DoT/H and DNSSEC was beneficial.

Andrew

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jul 2019 08:40:25 -0700

On Thu, Jul 25, 2019 at 8:39 AM Andrew Campling
<[email-masked]> wrote:

> On Thu, Jul 25, 2019 at 4:21 PM Eric Rescorla <ekr@rtfm..com
> <[email-masked]>> wrote:
>
>
>

Yes.

-Ekr

>
> As someone said during the DoH discussion at the ICANN conference in
> Marrakesh last month, “DoT and DoH give you a hardened pipe, don’t stop you
> drawing poisoned water from the lake; DNSSEC reassures you that the water
> is safe” (or something very close to that).  I thought that was a useful
> analogy to highlight why the combination of DoT/H and DNSSEC was
> beneficial.
>
>
>
>
>
> *Andrew*
>

---

From: Andrew Campling <[email-masked]>
Date: Thu, 25 Jul 2019 16:01:55 +0000

> It's also not clear to me that the act of answering a DNS query is something where there's a specific way to comply with GDPR or not comply with GDPR.

> Can you provide a pointer to something with more detail as to GDPR requirements for DNS recursive resolvers?

Important health warning, for specific guidance please check with a privacy lawyer and/regulator, I'm neither!

It's the processing of DNS (data) that needs to be in compliance with GDPR, there's plenty of guidance out there regarding how personal data should be processed in a compliant manner.  The regulators have indicated that they view DNS as personal data, so in scope with regards GDPR.

For guidance regarding a specific implementation or application and how to ensure GDPR compliance, I'd suggest approaching the relevant national regulator as any such guidance will be case-specific.  In the UK this would be the Information Commissioner's Office - see https://ico.org.uk/for-organisations/guide-to-data-protection/ as a good place to start and  https://ico.org.uk/global/contact-us/ for contact information.

Andrew

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 25 Jul 2019 18:26:16 +0200 (CEST)

Il 25 luglio 2019 17:28 Adam Roach <[email-masked]> ha scritto:

Sure. That's a different objection than the surveillance capitalism concern that I was responding to, and I'm not sure there's *any* jurisdiction on the planet that is immune from such concerns [1] [2] [3] [4].

Sure, and that is why moving data across jurisdictions is not a reliable solution to the problem of providing more privacy or less censorship for everyone. But each of us generally (and excluding dictatorships) has better ways to defend him/herself in his/her own jurisdiction, than in a foreign one. At least, I know how to get a lawyer and go to court here, and I can vote for a different government and build a public opinion campaign against them.

Moreover, when it comes to law enforcement, the commonly accepted balance between privacy and security is also highly cultural. I have no problem with my government tracking what people do online in my country, if they do it selectively under proper processes, only use the information for security and protect it properly; I actually prefer that to a scenario in which law enforcement is completely blind on online activities. However, in the U.S. the mindset seems to be really different. This is another reason why you might want not to mess up jurisdictions.

But even if we come back to surveillance capitalism, I would prefer my DNS data to stay with companies that do not have surveillance capitalism as a business model, rather than with companies that have surveillance capitalism as a business model but commit to refrain from applying it to DNS data. While Mozilla does not belong to this latter category, many likely DoH operators do, and this explains a certain degree of skepticism on DoH's privacy properties outside the IETF community (see for example professor Bellovin's reply yesterday at the tech plenary, when asked about DoH).

In terms of worries about queries from citizens of EU countries being sent to servers that are subject to US jurisdiction: we don't have immediate plans to implement DNS-over-HTTPS (DoH) in Firefox outside of North America. We are currently exploring potential DoH partners in Europe that would be employed for the benefit of European users.

And that - as a Firefox user from Europe - will be much appreciated, as long as you do not change my resolver without my consent :-)

As a DNS vendor, we are encouraging the resolver operators we are in touch with to deploy DoH, we are happy to support them in this, and we would be delighted to see those resolvers in your trusted list, as an option for users that choose not to use their local resolver. Still, we think that in Europe you should prioritize the local resolver.

--

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2019 18:49:39 -0400

Adam Roach <[email-masked]> wrote:
    > Since you mention Firefox's TRR list and then mention data mining (with an
    > implied connection), I'd like to point out yet again that one of the key
    > criteria for appearing on that list is an agreement to treat resolution
    > data according to a strict set of privacy-protecting provisions. You
    > can see, for
    > example, Cloudflare's associated privacy policy at

Does Mozilla have a policy/proceedure to vet the privacy policy
of DoT/DoH providers?  Maybe Mozilla is considering this?

Would it be appropriate for this to go into
a certificate extension (perhaps signed by a Mozilla CA)?

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

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 26 Jul 2019 20:19:47 -0400

On Fri, Jul 26, 2019 at 6:49 PM Michael Richardson <[email-masked]>
wrote:

> (with an

Yes, they've published their minimum criteria here:
https://wiki.mozilla.org/Security/DOH-resolver-policy#Privacy_Requirements

---

From: Rob Sayre <[email-masked]>
Date: Fri, 26 Jul 2019 19:05:26 -0700

> https://wiki.mozilla.org/Security/DOH-resolver-policy#Privacy_Requirements

Without getting into specifics, many ISPs use their DNS traffic as fuel for
an ad network and/or sell the data on, and thus wouldn't meet those
requirements. Whether that's a good or bad thing is probably outside the
already-vague scope of this mailing list.

That's one reason I don't think the IETF should get involved at the moment,
and why terms like "policy" or "operational requirements" can be
problematic.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Jul 2019 06:08:44 -0700

> of DoT/DoH providers?  Maybe Mozilla is considering this?

Yes:
https://wiki.mozilla.org/Security/DOH-resolver-policy

> a certificate extension (perhaps signed by a Mozilla CA)?

I'm not sure what this would buy us over just having a list.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Jul 2019 10:49:02 -0400

>> https://wiki.mozilla.org/Security/DOH-resolver-policy#Privacy_Requirements

Does this result in an explicit pinning/listing of the TRR into a list, or
does it result in a certificate being issued?

    > already-vague scope of this mailing list.

Agreed, but if the enterprises and others have reasons (malware) to want
their own anchors, the question becomes what do they need to get on the
approved list.

    > and why terms like "policy" or "operational requirements" can be

In my mind, the IETF can have a standard way to express the policies of
a given DoH server is, without actually endorsing any specific policy.

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Jul 2019 10:52:30 -0400

mcr> Does Mozilla have a policy/proceedure to vet the privacy policy of
    mcr> DoT/DoH providers?  Maybe Mozilla is considering this?

    ekr> Yes: https://wiki.mozilla.org/Security/DOH-resolver-policy

    mcr> Would it be appropriate for this to go into
    mcr> a certificate extension (perhaps signed by a Mozilla CA)?

    > I'm not sure what this would buy us over just having a list.

I guess it buys Mozilla nothing.
But others could rely on the list in a distributed fashion.

If the extension said what the privacy was, rather than just that Mozilla had
vetted it, then perhaps there could be other levels of privacy.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Jul 2019 16:32:43 +0100

On 27/07/2019 03:05, Rob Sayre wrote:
> an ad network and/or sell the data on,

I think we would need some specific evidence of that before
we ought factor it into the discussion. Is there evidence of
this happening?

Thanks,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Jul 2019 08:55:31 -0700

> But others could rely on the list in a distributed fashion.

Well, we already have a worked example of a similar system, which is Root
Programs, and in that case we've found that having a list of trust anchors
that someone could download was adequate. Unless this list were to get very
large, this seems far simpler than creating a certificate extension.

If the extension said what the privacy was, rather than just that Mozilla
> had

It's not quite clear to me what you have in mind here, but one thing I
would like to emphasize is that the Mozilla TRR program is more than just a
self-assertion about privacy policy, in that we actively manage the list,
rather than just trusting people's self-assertions. If people were
interested in some other set of privacy policies, then it's not clear to me
who would be responsible for running such a program.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Sat, 27 Jul 2019 10:56:19 -0700

> we ought factor it into the discussion. Is there evidence of

https://arstechnica.com/tech-policy/2017/03/senate-votes-to-let-isps-sell-your-web-browsing-history-to-advertisers/

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Jul 2019 19:30:31 +0100

On 27/07/2019 18:56, Rob Sayre wrote:
> On Sat, Jul 27, 2019 at 8:32 AM Stephen Farrell
> <[email-masked]> wrote:
> 
>> 
>> I think we would need some specific evidence of that before we
>> ought factor it into the discussion. Is there evidence of this
>> happening?
>> 
> 

Assuming that regulation/law came into force, I read that as
saying that an ISP could sell DNS-access data legally in the
US, but it's always been the case that a network provider could
do that.

Evidence that it is really happening would be more interesting
as part of this discussion, as, should that be the case, it'd I
think provide a strong argument for the kind of TRR setup that
mozilla seem keen on.

Cheers,
S.

>  thanks, Rob

---

From: Rob Sayre <[email-masked]>
Date: Sat, 27 Jul 2019 12:04:44 -0700

> think provide a strong argument for the kind of TRR setup that

https://arstechnica.com/information-technology/2015/03/atts-plan-to-watch-your-web-browsing-and-what-you-can-do-about-it/

There's plenty of evidence that ISPs use DNS traffic to fuel their own ad
networks (again, no judgement). I also found some research that shows DNS
information being at least "shared":

https://blog.benjojo.co.uk/post/ISPs-sharing-DNS-query-data

In that context, I don't think a WG is going to be productive.

thanks,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Jul 2019 17:52:42 -0400

Eric Rescorla <[email-masked]> wrote:
    > had vetted it, then perhaps there could be other levels of privacy.

    > would like to emphasize is that the Mozilla TRR program is more than
    > just a self-assertion about privacy policy, in that we actively manage
    > the list, rather than just trusting people's self-assertions. If people
    > were interested in some other set of privacy policies, then it's not
    > clear to me who would be responsible for running such a program.

I'm not clear either at this point, because we don't have any feedback from
any other entities.  There seems to be significant interest in having TRRs
running internal to enterprises, for the benefit for BOYDs, which would do as
much as possible in that environment.

It might be that some TRR's are unable for local legal reasons to comply
to the exact same criteria as Mozilla would like for a TRR to be used by the
general public.   For instance, enterprises might be required by some other
local law to retain detailed data for 24 hours or something like that, but
not disclose it without judicial review. 

The fact that Mozilla is not just depending upon self-assertions is part of
what is of interest to end users, I think.  While a policy OID might work for
some things, I agree that it is probably a self-assertion.  It could be more
complex:  The CA signing might actively investigating before signing such
a policy OID, or a third party might be providing a separately signed
assertion that goes into a (new?) extension.

I will drop this here, as I think you've answered my query as to the degree
of interest Mozilla has.

---

From: Vittorio Bertola <[email-masked]>
Date: Sun, 28 Jul 2019 04:50:07 +0200 (CEST)

Il 27 luglio 2019 17:55 Eric Rescorla <[email-masked]> ha scritto:

On Sat, Jul 27, 2019 at 7:52 AM Michael Richardson <
[email-masked]> wrote:

It's not quite clear to me what you have in mind here, but one thing I would like to emphasize is that the Mozilla TRR program is more than just a self-assertion about privacy policy, in that we actively manage the list, rather than just trusting people's self-assertions. If people were interested in some other set of privacy policies, then it's not clear to me who would be responsible for running such a program.

I understand your viewpoint, but from the opposite one - the resolver operator's one - having to apply for membership to multiple lists of trusted resolvers, possibly with different or even contrasting requirements, just to be usable on any browser and any application, looks like a nightmare. Also, this would definitely be a push towards a smaller number of bigger and more centralized resolver operators, as smaller operators would have a harder time managing multiple accreditations.

So there would be merit in thinking of a joint industry program to evaluate and accredit resolvers, which could even foresee different levels of accreditation or different policies, so that applications could still pick different requirements, but at least the resolver could apply once and, if meeting all the requirements, be validated for all clients. All in all, it would not be too different from the CA machinery.

But your point on who would run it, and "is there actually anyone willing to work on this?", is also valid; and also, even the simplest resolver certification program would still be more restrictive, and thus more prone to centralization, than the current situation in which people can just deploy a DNS resolver without having to ask for permission and it becomes immediately available to everyone.

--

---

From: Valentin Gosu <[email-masked]>
Date: Sun, 28 Jul 2019 11:05:03 +0200

On Sun, Jul 28, 2019, 04:50 Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> On Sat, Jul 27, 2019 at 7:52 AM Michael Richardson < [email-masked]>
> wrote:
>
> I understand your viewpoint, but from the opposite one - the resolver
> operator's one - having to apply for membership to multiple lists of
> trusted resolvers, possibly with different or even contrasting
> requirements, just to be usable on any browser and any application, looks
> like a nightmare. Also, this would definitely be a push towards a smaller
> number of bigger and more centralized resolver operators, as smaller
> operators would have a harder time managing multiple accreditations.
>
> So there would be merit in thinking of a joint industry program to
> evaluate and accredit resolvers, which could even foresee different levels
> of accreditation or different policies, so that applications could still
> pick different requirements, but at least the resolver could apply once
> and, if meeting all the requirements, be validated for all clients. All in
> all, it would not be too different from the CA machinery.
>
> But your point on who would run it, and "is there actually anyone willing
> to work on this?", is also valid; and also, even the simplest resolver
> certification program would still be more restrictive, and thus more prone
> to centralization, than the current situation in which
>

people can just deploy a DNS resolver without having to ask for permission
> and it becomes immediately available to everyone.
>

It seems to me that for both DNS resolvers and DoH servers people still
need to go through the trouble of pointing their systems to it.

You can easily set up your DoH server, and share it with your friends...
Who then need to configure their browsers/stub resolvers to use it.

The question is which DoH servers are trustworthy enough to be a default -
which is where Mozilla's policies become important.

The problem with centralization also exists today with the bigger DNS
resolvers... I suspect quad8, quad1 and quad9 get the majority of traffic
(from people who switched the default DNS service, or ISPs that forward
such traffic) - which makes sense since they provide a globally available
reliable service.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Jul 2019 05:53:10 -0700

> all, it would not be too different from the CA machinery.

I agree that this is to some extent like a CA Root program, but I think
this points in the opposite direction from the way you are suggesting:
there isn't one WebPKI root program. Rather, the major OS vendors (Apple,
Microsoft, and Google) all maintain their own root lists, and Mozilla
operates its own. Other applications usually either rely on the OS list or
copy Mozilla's list. There's some degree of collaboration here (
https://www.ccadb.org/) and one could imagine collaboration in the TRR
space if there were other TRR users, but our approach here is to wait for
other TRR users to emerge and then see what makes sense.

-Ekr

> to centralization, than the current situation in which people can just
> deploy a DNS resolver without having to ask for permission and it becomes
> immediately available to everyone.
>
> --
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 30 Jul 2019 21:49:21 +0000

On 7/25/19, 10:12 AM, "Add on behalf of Adam Roach" <[email-masked] on behalf of [email-masked]> wrote:
> You can see, for example, Cloudflare's associated privacy 
    policy at https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ 
 
[JL] This speaks to the DNS query/response. But with DoH, this is contained inside of an HTTP envelope, so to speak, which has much more rich tracking - noted at https://www.cloudflare.com/privacypolicy/ under website visitors (which I presume applies to all HTTP transactions). So the confluence of DNS and HTTP here seems interesting to better understand and document as TRR-style policies evolve. Since there is an HTTP server involved in DoH, presumably all the normal HTTP log items are seen & processed and can be logged, like user agent, cookies, and so on.

[JL] In addition, I suspect a concern (for the very high scale centralised DoH platforms) is not just the per-user privacy policy but also what aggregated business intelligence a global scale platform would be able to develop (e.g. of a population of 500M users, how many have queried for *.netflix.com in the past N hours, by country, ASN, user agent, etc.), relative to competitors or potential competitors. So I suspect these concerns may arise, at least for platforms of very high scale / penetration.

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 30 Jul 2019 16:11:00 -0600

aroach> policy at https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ 
 
JLivingood> This speaks to the DNS query/response. But with DoH, this is
JLivingood> contained inside of an HTTP envelope, so to speak, which has
JLivingood> much more rich tracking - noted at
JLivingood> https://www.cloudflare.com/privacypolicy/ under website
JLivingood> visitors (which I presume applies to all HTTP
JLivingood> transactions). So the confluence of DNS and HTTP here seems
JLivingood> interesting to better understand and document as TRR-style
JLivingood> policies evolve. Since there is an HTTP server involved in
JLivingood> DoH, presumably all the normal HTTP log items are seen &
JLivingood> processed and can be logged, like user agent, cookies, and
JLivingood> so on.

Indeed. While things like java going away and more users trying to use
privacy badger and other things to make browser fingerprinting less
accurate, it's still scarily accurate. Being able to tie DNS queries and
individual browsers is yet another step down that slippery slope to
privacy loss.

  <https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-fingerprinting-how-it-changes-game-sneakiest-web-trackers>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 31 Jul 2019 00:56:27 -0700

On Tue, Jul 30, 2019 at 3:11 PM Paul Ebersman <[email-masked]> wrote:
> Being able to tie DNS queries and individual browsers is yet another step
down that slippery slope to privacy loss.

Well, browsers are actively working on fingerprinting.

Another situation to consider: maybe operating systems will start shipping
their own default DNS servers. It doesn't seem like that would be out of
bounds for ChromeOS or iOS, for example. They already rely on several
online services. It also seems like they would probably make
enterprise/parental controls available, since they already do that.

It looks like we're considering a legacy case, where the local network
provider runs an unencrypted DNS server. I don't think there's anything for
the IETF to do here, as I wrote at the very beginning of this thread.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 31 Jul 2019 07:24:19 -0700

On Tue, Jul 30, 2019 at 2:49 PM Livingood, Jason <
[email-masked]> wrote:

> [JL] This speaks to the DNS query/response. But with DoH, this is
> contained inside of an HTTP envelope, so to speak, which has much more rich
> tracking - noted at https://www.cloudflare.com/privacypolicy/ under
> website visitors (which I presume applies to all HTTP transactions).

No, this is not our understanding. Rather, the privacy policy for DoH
covers every aspect of DoH, including the HTTP portion. The Cloudflare
Privacy Policy is a separate policy for CF websites and does not govern the
resolver.

So the confluence of DNS and HTTP here seems interesting to better
> understand and document as TRR-style policies evolve. Since there is an
> HTTP server involved in DoH, presumably all the normal HTTP log items are
> seen & processed and can be logged, like user agent, cookies, and so on.
>

Firefox doesn't send cookies for DoH. We do send User-Agent, and we could
look at removing that, but given TLS ClientHello fingerprinting, that's
probably not adding a huge amount of additional information.

-Ekr

> [JL] In addition, I suspect a concern (for the very high scale centralised
> DoH platforms) is not just the per-user privacy policy but also what
> aggregated business intelligence a global scale platform would be able to
> develop (e.g. of a population of 500M users, how many have queried for *.
> netflix.com in the past N hours, by country, ASN, user agent, etc.),
> relative to competitors or potential competitors. So I suspect these
> concerns may arise, at least for platforms of very high scale /
> penetration.
>
> --
> Add mailing list
> [email-masked]

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 31 Jul 2019 15:25:46 +0000

On 31/07/2019, 16:25, "Add on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 30, 2019 at 2:49 PM Livingood, Jason <[email-masked]<mailto:[email-masked]>> wrote:

[JL] This speaks to the DNS query/response. But with DoH, this is contained inside of an HTTP envelope, so to speak, which has much more rich tracking - noted at https://www.cloudflare.com/privacypolicy/ under website visitors (which I presume applies to all HTTP transactions).

No, this is not our understanding. Rather, the privacy policy for DoH covers every aspect of DoH, including the HTTP portion. The Cloudflare Privacy Policy is a separate policy for CF websites and does not govern the resolver.

So the confluence of DNS and HTTP here seems interesting to better understand and document as TRR-style policies evolve. Since there is an HTTP server involved in DoH, presumably all the normal HTTP log items are seen & processed and can be logged, like user agent, cookies, and so on.

Firefox doesn't send cookies for DoH. We do send User-Agent, and we could look at removing that, but given TLS ClientHello fingerprinting, that's probably not adding a huge amount of additional information.

-Ekr

This implies the combination Firefox/Cloudflare does not pose a significant privacy risk. Fair enough. But the general case of whatever-the-app using a hardwired DOH resolver remains, much the same as the archetypal coffeeshop resolver compared to well-behaved, contract-bounded ISPs.

Dr Diego R. Lopez
Telefonica I+D

[JL] In addition, I suspect a concern (for the very high scale centralised DoH platforms) is not just the per-user privacy policy but also what aggregated business intelligence a global scale platform would be able to develop (e.g. of a population of 500M users, how many have queried for *.netflix.com<http://netflix.com> in the past N hours, by country, ASN, user agent, etc.), relative to competitors or potential competitors. So I suspect these concerns may arise, at least for platforms of very high scale / penetration.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 31 Jul 2019 08:54:39 -0700

On Wed, Jul 31, 2019 at 8:25 AM Diego R. Lopez <[email-masked]>
wrote:

> On 31/07/2019, 16:25, "Add on behalf of Eric Rescorla" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
>
>
>
>
> This implies the combination Firefox/Cloudflare does not pose a
> significant privacy risk. Fair enough. But the general case of
> whatever-the-app using a hardwired DOH resolver remains, much the same as
> the archetypal coffeeshop resolver compared to well-behaved,
> contract-bounded ISPs.
>

This seems to be assuming a number of facts about how ISPs behave that are
not in evidence.

-Ekr

> e-mail: [email-masked]
>
> Tel:         +34 913 129 041
>
> Mobile:  +34 682 051 091
>
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>

---

From: Eric Orth <[email-masked]>
Date: Wed, 31 Jul 2019 11:58:42 -0400

> probably not adding a huge amount of additional information.

Chrome has similar behavior.  DoH requests do not send or accept cookies
and are blocked from sharing sockets/connections/etc with any requests that
do.  Recent work has also minimized other standard headers, eg setting
user-agent to simply "Chrome" and accept-language to "*".

Similar privacy mitigations and considerations for DoH/DoT/etc may be
useful to document in an Informational or BCP.  Best if applications
implementing these protocols make informed decisions around privacy
practices.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 31 Jul 2019 16:04:50 +0000

On 31/07/2019, 17:55, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 31, 2019 at 8:25 AM Diego R. Lopez <[email-masked]<mailto:[email-masked]>> wrote:
On 31/07/2019, 16:25, "Add on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
On Tue, Jul 30, 2019 at 2:49 PM Livingood, Jason <[email-masked]<mailto:[email-masked]>> wrote:

This seems to be assuming a number of facts about how ISPs behave that are not in evidence.

-Ekr

I was not making any assumption on concrete behaviors (and far be it from me to start another semi-religious discussion on the behavior and/or motivations of different actors), just pointing that we must consider behaviors in all cases, including apps and devices in general, the same way we consider all kinds of access providers.

Dr Diego R. Lopez
Telefonica I+D

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 31 Jul 2019 17:12:28 +0100

I agree, and have been discussing the idea off-list of having a document 
that also covers DNS trust anchors and their role, particularly when the 
network is providing DoT/DoH services, and the considerations where 
clients need a Do53 bootstrap. Maybe it would make sense to cover all of 
these points in a single informational document, as I don't believe such 
considerations belong in a BCP?

Regards

On 31/07/2019 16:58, Eric Orth wrote:
> privacy mitigations and considerations for DoH/DoT/etc may be useful to 
> document in an Informational or BCP

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Jul 2019 17:51:49 +0100

> On 31 Jul 2019, at 17:12, Thomas Peterson <[email-masked]> wrote:
> 
> I agree, and have been discussing the idea off-list of having a document that also covers DNS trust anchors and their role, particularly when the network is providing DoT/DoH services, and the considerations where clients need a Do53 bootstrap. Maybe it would make sense to cover all of these points in a single informational document, as I don't believe such considerations belong in a BCP?

This is a badly needed document and I'll be happy to work on it. I think it could even end up as a BCP.

The big question is which WG would be the best place to develop this I-D. It seems to straddle the doh and dprive WGs and wouldn't be suitable for dnsop.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 31 Jul 2019 16:07:17 -0400

Jason,

On Tue, Jul 30, 2019 at 5:49 PM Livingood, Jason <
[email-masked]> wrote:

> website visitors (which I presume applies to all HTTP transactions). So the
> confluence of DNS and HTTP here seems interesting to better understand and
> document as TRR-style policies evolve. Since there is an HTTP server
> involved in DoH, presumably all the normal HTTP log items are seen &
> processed and can be logged, like user agent, cookies, and so on.
>

Cloudflare modified the HTTPS processing for DoH requests, we did this for
privacy, efficiency and speed reasons.
The overwriting goal was to be compliant with the our public policies and
commitments.
Anything that matches https://tools.ietf.org/html/rfc8484#section-4.1
definition
of DoH request is NOT logged by the HTTPS service, we will only respond to
DoH requests on a defined list of DoH service names/addresses.

Our DoH module only counts connections, no logging of content ( mainly to
verify we do not drop anything internally)
The DNS  resolver system is the only one that writes to the resolver logs,
it is unaware of any user agent and other HTTP things,

There is no setting or reading of cookies from our servers (you can confirm
this by doing a request on you own), like

curl --verbose -H 'accept: application/dns-json' '
https://cloudflare-dns.com/dns-query?name=comcast.com&type=AAAA'

> concerns may arise, at least for platforms of very high scale /
This is not unique to DoH in any way or shape!
This is common to all DNS queries and having access to query streams, so
every DNS provider should answer if they share any DNS query data and with
whom and for what purpose.
Anyone that has access to query stream from one of the top ISP's in a few
countries might have better view than large Public DNS Resolver.

Restating Cloudflare 1.1.1.1 data policy: Cloudflare will not share any
query data with anyone!! Per our agreement with Apnic; they have access to
subset Resolver of logs for the last 24 hours only data that arrived on the
1.x.x.1 addresses, they do not a have access to data sent by Firefox users
unless the user modified the URL to *"https://1.1.1.1/dns-query
<https://1.1.1.1/dns-query>".*
Cloudflare will not use the query data for anything other than to improve
the service. Cloudflare keeps traffic aggregations and may share those
publicly from time to time.

Cloudflare is fully compliant the policy that Firefox has published AND
they have NO access to query data
-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com