Subject: [Add] Validity of network administrator role

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 9 Aug 2019 12:25:26 +0000

> I'm not sure everyone views "network administrator" as a valid role, at least in contexts where the administrator does not also control the device.

Many enterprises and small businesses allow employees to attach personal devices to their networks. I think it's completely valid for businesses to administer their networks as they wish without banning personal devices or requiring employees to turn over control of personal devices.

Personally, I view my role as network administrator of my home network to be *extremely* valid -- including when I allow guests' devices (which I don't control) to attach to my network. And I often doubt that I really have "control" over my Smart TVs and Chromecast (which is why they get to be together on their own little subnet so they can't see or be seen by the rest of the home network -- I connect to the subnet Wi-Fi AP to use them). I don't have any Android devices, because I don't believe there's the remotest possibility of being in "control" of them. I flashed a Linux OS on my Lenovo laptop when I realized I didn't control the original OS that Lenovo had heavily "customized". I even firewall my ISP router by having my own router at the edge of *my* home network.

Applications and cloud services that try to take away from me the ability to control what goes on inside my personal home network will be added to my "do not trust" list.  

I'm thinking what I'd really like is for my home router to have a feature I can enable that lets me block all traffic to known public DNS services. I'm pretty sure that would go a long ways to restoring my ability to use DNS as a reasonably effective control surface. I'm not happy that some people are claiming I can't control DNS in my own home because they've succeeded in taking this control away from me. My home network belongs to me, and I'm going to do what I can to keep it that way. 

Just like it turned out to be good for everyone to have a good definition of NAT and DNS proxy, it would probably be good if this "public DNS blocking" functionality were thoughtfully designed to avoid unnecessary breakage. IETF may or may not be the right place to design it. Suggestions that people go elsewhere to design something like this may be correct. OTOH, if application and cloud providers wanted to have input to the design, IETF might indeed be the right place.

It wouldn't surprise me if coffee shops, hotels, and enterprises didn't also choose to enable such a feature. Regulators in some countries might even insist on it.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Aug 2019 06:14:31 -0700

For my part, I would rather have the option to use public DNS. DoH lets me do that when without it I would have no control, because the SP would be taking that control from me. 

True, on my home net, I can set up the resolver I want, and in that case I am better off if apps use my configured resolver. That’s the use case you’re talking about. But when I’m in a coffee shop, I have no reason to trust the local network administrator. In this case, DoH gives me the assurance that I am talking to the resolver I intended to use. 

IOW, the administrator role is a bit more nuanced than what you just said, even though I agree with your choice in that particular case.  

I guess the difference is where you think the edge of the administrative domain is...  :)

Sent from my iPhone

On Aug 9, 2019, at 5:25 AM, STARK, BARBARA H <[email-masked]> wrote:

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 9 Aug 2019 13:54:22 +0000

> For my part, I would rather have the option to use public DNS. DoH lets me
> do that when without it I would have no control, because the SP would be
> taking that control from me.
> 
> True, on my home net, I can set up the resolver I want, and in that case I am
> better off if apps use my configured resolver. That’s the use case you’re
> talking about. But when I’m in a coffee shop, I have no reason to trust the
> local network administrator. In this case, DoH gives me the assurance that I
> am talking to the resolver I intended to use.

Oh, I don't trust public Wi-Fi at all. I avoid using it unless I feel like I really need it. I avoid checking email or FB or financial apps (make sure they're all closed, and none allow notifications) if I do attach to one. BTW, I don't trust VPN providers either -- so I don't personally see that as a good alternative. I agree that if I were to use a public Wi-Fi, I would prefer to use something like DoH. But what I was saying, is I don't think there is anything I (or you) can do to prevent a coffee shop from blocking traffic to public DNS providers -- if they chose to do so. And it wouldn't surprise me if they did so choose.

I'm not advocating for this. I'm just a realist and I think it's an unavoidable response to what's going on.

Ultimately, network operators (especially operators of private networks -- and coffee shop hotspots, a lot of "public" Wi-Fi, and enterprises are still private networks) *do* still have control of their networks.
Barbara

> IOW, the administrator role is a bit more nuanced than what you just said,
> even though I agree with your choice in that particular case.
> 
> >> I'm not sure everyone views "network administrator" as a valid role, at
> least in contexts where the administrator does not also control the device.
> >
> > Many enterprises and small businesses allow employees to attach personal
> devices to their networks. I think it's completely valid for businesses to
> administer their networks as they wish without banning personal devices or
> requiring employees to turn over control of personal devices.
> >
> > Personally, I view my role as network administrator of my home network to
> be *extremely* valid -- including when I allow guests' devices (which I don't
> control) to attach to my network. And I often doubt that I really have
> "control" over my Smart TVs and Chromecast (which is why they get to be
> together on their own little subnet so they can't see or be seen by the rest of
> the home network -- I connect to the subnet Wi-Fi AP to use them). I don't
> have any Android devices, because I don't believe there's the remotest
> possibility of being in "control" of them. I flashed a Linux OS on my Lenovo
> laptop when I realized I didn't control the original OS that Lenovo had heavily
> "customized". I even firewall my ISP router by having my own router at the
> edge of *my* home network.
> >
> > Applications and cloud services that try to take away from me the ability to
> control what goes on inside my personal home network will be added to my
> "do not trust" list.
> >
> > I'm thinking what I'd really like is for my home router to have a feature I can
> enable that lets me block all traffic to known public DNS services. I'm pretty
> sure that would go a long ways to restoring my ability to use DNS as a
> reasonably effective control surface. I'm not happy that some people are
> claiming I can't control DNS in my own home because they've succeeded in
> taking this control away from me. My home network belongs to me, and I'm
> going to do what I can to keep it that way.
> >
> > Just like it turned out to be good for everyone to have a good definition of
> NAT and DNS proxy, it would probably be good if this "public DNS blocking"
> functionality were thoughtfully designed to avoid unnecessary breakage.
> IETF may or may not be the right place to design it. Suggestions that people
> go elsewhere to design something like this may be correct. OTOH, if
> application and cloud providers wanted to have input to the design, IETF
> might indeed be the right place.
> >
> > It wouldn't surprise me if coffee shops, hotels, and enterprises didn't also
> choose to enable such a feature. Regulators in some countries might even
> insist on it.
> > Barbara

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Aug 2019 07:00:47 -0700

The point is, with DoH, if that really turns out to be true, the escalation will continue. If you want to not have DoH go completely stealth, then as an operator the last thing you want to do is block well known DoH servers. 

Sent from my iPhone

> On Aug 9, 2019, at 6:54 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
>

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 Aug 2019 10:05:50 -0400

On 9 Aug 2019, at 09:54, STARK, BARBARA H <[email-masked]> wrote:

> Oh, I don't trust public Wi-Fi at all. I avoid using it unless I feel like I really need it.

Personally I think it's foolish to trust any network, regardless of who runs it. Assuming that all networks are hostile seems like a much better starting point. I have no real reason to believe that any particular WiFi network is better than any particular LTE network, either.

My preferred reaction to an end-user indicating that they trust the local network would be to raise the drawbridge and put the troops on high alert, since the indicated false sense of security probably means that the local network is filled with unpatched lightbulbs, printers, phones and laptops and is about the most unpleasant place to navigate that you could imagine. At least in a coffeeshop network or attached to a mobile carrier I have a reasonable expectation that there's just one person out to get me.

From my perspective, however, all networks have an administrator. You just can't tell who it is, even if it's your network and you think it's you.

Joe

---

From: Bret Jordan <[email-masked]>
Date: Fri, 9 Aug 2019 08:32:23 -0600

Just so I understand correctly.  You are upset that a company is allowing you to use _their_ network, probably for free, and they put controls on _their_ network? 

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

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

---

From: Bret Jordan <[email-masked]>
Date: Fri, 9 Aug 2019 08:36:19 -0600

Barbara,

I have done the same for years.  Different SSIDs and VLANs for every class of device on my network.  I have even run my own  Bind DNS server since the late 90s.  That way when I am remote I can always point back to my DNS.  I hate the idea of some quad X organization tracking all of my DNS queries. 

Thanks,
Bret

> On Aug 9, 2019, at 6:25 AM, STARK, BARBARA H <[email-masked]> wrote:
>

---

From: Bret Jordan <[email-masked]>
Date: Fri, 9 Aug 2019 08:40:02 -0600

The ideological view needs to be careful.  If we push to far one way, organizations may just go back to a no-default-route, and force all traffic through their full TLS inspection device.  They may do this because the regulator requires them to do so. Once a theory of harm document gets written for this, because we have backed them in to a corner, things will get much worse. 

Thanks,
Bret

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Aug 2019 08:26:05 -0700

Bret, I’m not upset.  Please don’t turn this into an emotional thing. It’s really hard to converge on understanding if we are talking about how we feel rather than about what works. 

What I am is aware of the trust relationship. If a network blocks services I want on order to force me to trust the operator (or for any other reason), I don’t use it.  It’s not emotional. I don’t hold it against the operator. I just respond appropriately to the situation.  

Sent from my iPhone

> On Aug 9, 2019, at 7:32 AM, Bret Jordan <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Aug 2019 08:28:55 -0700

Bret, that’s perfectly okay. Nobody will use that network, but that’s fine. If there is a statutory reason why some use case requires that degree of intercept, then that network will be used only for use cases that fall into that regime, and a different network and device will be used for all other traffic. This is a good outcome. Air gaps are also appropriate sometimes!  It just depends on the use case. I’m not going to air gap my phone!  :)

Sent from my iPhone

> On Aug 9, 2019, at 7:40 AM, Bret Jordan <[email-masked]> wrote:
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 9 Aug 2019 16:18:44 +0000

> The point is, with DoH, if that really turns out to be true, the escalation will
> continue. If you want to not have DoH go completely stealth, then as an
> operator the last thing you want to do is block well known DoH servers.

If DoH goes stealth, it will be harder for "average" people to use it (kind of like most people think of the "dark web" as some sort of mythical entity), and it will not be as disruptive to networks. 
The networks do not have absolute power, but neither do the applications and cloud services. 
Unless the 2 "sides" work together in an environment where there is a balance of power, the escalation will continue. And individuals will be the losers.
Neither "side" is evil. They are merely coming at it from different perspectives that aren't fully shared or understood (or accepted) by each other.
And most of the large network operators represented on this list aren't coming at this from the perspective of creating user profiles and doing ad insertion -- they really do see the potential for massive network disruption and harm to people.
If we have common goals of securing the Internet (against DDoS attacks, unauthorized interception of information, etc.), increasing the ability of users to manage their privacy (consistent with what they want and not what others want to impose on them), and maintaining the rights of private network administrators to manage their networks as they see fit (including enterprises and parents), then we should be able to work together to identify ways to improve all of these and not improve just one at the expense of the others. This is not a zero-sum game.
Barbara

> >> For my part, I would rather have the option to use public DNS. DoH
> >> lets me do that when without it I would have no control, because the
> >> SP would be taking that control from me.
> >>
> >> True, on my home net, I can set up the resolver I want, and in that
> >> case I am better off if apps use my configured resolver. That’s the
> >> use case you’re talking about. But when I’m in a coffee shop, I have
> >> no reason to trust the local network administrator. In this case, DoH
> >> gives me the assurance that I am talking to the resolver I intended to use.
> >
> > Oh, I don't trust public Wi-Fi at all. I avoid using it unless I feel like I really
> need it. I avoid checking email or FB or financial apps (make sure they're all
> closed, and none allow notifications) if I do attach to one. BTW, I don't trust
> VPN providers either -- so I don't personally see that as a good alternative. I
> agree that if I were to use a public Wi-Fi, I would prefer to use something like
> DoH. But what I was saying, is I don't think there is anything I (or you) can do
> to prevent a coffee shop from blocking traffic to public DNS providers -- if
> they chose to do so. And it wouldn't surprise me if they did so choose.
> >
> > Ultimately, network operators (especially operators of private networks --
> and coffee shop hotspots, a lot of "public" Wi-Fi, and enterprises are still
> private networks) *do* still have control of their networks.
> > Barbara
> >
> >> IOW, the administrator role is a bit more nuanced than what you just
> >> said, even though I agree with your choice in that particular case.
> >>
> >> devices to their networks. I think it's completely valid for
> >> businesses to administer their networks as they wish without banning
> >> personal devices or requiring employees to turn over control of personal
> devices.
> >>>
> >> control) to attach to my network. And I often doubt that I really
> >> have "control" over my Smart TVs and Chromecast (which is why they
> >> get to be together on their own little subnet so they can't see or be
> >> seen by the rest of the home network -- I connect to the subnet Wi-Fi
> >> AP to use them). I don't have any Android devices, because I don't
> >> believe there's the remotest possibility of being in "control" of
> >> them. I flashed a Linux OS on my Lenovo laptop when I realized I
> >> didn't control the original OS that Lenovo had heavily "customized".
> >> I even firewall my ISP router by having my own router at the edge of
> *my* home network.
> >>>
> >> control what goes on inside my personal home network will be added to
> >> my "do not trust" list.
> >>>
> >> enable that lets me block all traffic to known public DNS services.
> >> I'm pretty sure that would go a long ways to restoring my ability to
> >> use DNS as a reasonably effective control surface. I'm not happy that
> >> some people are claiming I can't control DNS in my own home because
> >> they've succeeded in taking this control away from me. My home
> >> network belongs to me, and I'm going to do what I can to keep it that way.
> >>>
> >> IETF may or may not be the right place to design it. Suggestions that
> >> people go elsewhere to design something like this may be correct.
> >> OTOH, if application and cloud providers wanted to have input to the
> >> design, IETF might indeed be the right place.
> >>>
> >> choose to enable such a feature. Regulators in some countries might
> >> even insist on it.
> >>> Barbara
> 
> --
> Add mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_add&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=757eoRUmrKc5JL6pGXjFV_eG55fa2pUimyXPpUepE40&
> s=aqtwMwuWcLDg3VxxWAaF83Oy2SGwZjsgn5rLrtRf10g&e=

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Aug 2019 18:38:44 +0100

Hiya,

On 09/08/2019 13:25, STARK, BARBARA H wrote:
> Applications and cloud services that try to take away from me the
> ability to control what goes on inside my personal home network will
> be added to my "do not trust" list.
I also like to manage my home n/w according to my own
wishes. My wishes include not eavesdropping on guest
or home user's traffic, except with their agreement,
e.g. if someone's device isn't working. (Just in case
someone goes there: when some of the home n/w users
were too young to agree, we used manage their access
to connected devices, not their n/w traffic, e.g. by
insisting they be in the same room as an adult, and
one of the people who most enforced that policy is
decidedly non-technical.)

For me, that means if a guest or other n/w user has
chosen an application that wants to do DoH with some
other recursive that's ok by me. I'd consider myself
inhospitable were I to want to control the DNS choices
of people in my home. In a similar vein, I do not
insist that people using my home n/w use any particular
OS, even though I have strong opinions on the relative
goodness of those.

So the important point here is "my network, my rules"
does *not* imply "DoH is problematic."

I think that also means that considering the n/w admin
as a valid role similarly does not imply that one has
a problem with DoH.

And lastly, liking DoH does not imply disparaging n/w
administration.

There are of course a bunch of specific policies that
some n/w admins do like for which DoH is problematic as
has been described already on this list. But we ought
not over-claim e.g. by asserting that liking DoH implies
disliking n/w administration.

Cheers,
S.

PS: Neither Barbara nor I are wearing our homenet WG
chair hats in this discussion, but I think it's fun that
we take different, reasonable, positions:-)

---

From: Bret Jordan <[email-masked]>
Date: Tue, 13 Aug 2019 15:46:33 -0600

My question is at what stage, level, organization type, or organization size,  does a network administrator care, or are forced to care by regulators?

Thanks,
Bret

> On Aug 13, 2019, at 11:38 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <0x5AB2FAF17B172BEA.asc>-- 
> Add mailing list
> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Aug 2019 14:48:33 -0700

> My question is at what stage, level, organization type, or organization size,  does a network administrator care, or are forced to care by regulators?

Is that a rhetorical question, or do you genuinely not know?

---

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

On Tue, Aug 13, 2019 at 2:48 PM Ted Lemon <[email-masked]> wrote:

> My question is at what stage, level, organization type, or organization
> size,  does a network administrator care, or are forced to care by
> regulators?
>
>

Rhetorical or not, regulators can just go to the endpoints if need be. For
example:

<https://help.twitter.com/en/rules-and-policies/tweet-withheld-by-country>

Last week, I sent an example of an attack that would not work over DoT/DoH:

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

It looks to me like that attack would be hard to mitigate if there were a
requirement that a certain resolver *must* be consulted, or if there were
some in-the-clear mechanism to disable encrypted DNS.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Aug 2019 00:59:49 +0100

Hi Bret,

On 13/08/2019 22:46, Bret Jordan wrote:
> My question is at what stage, level, organization type,
> or organization size,  does a network administrator care,
> or are forced to care by regulators?

It seems pretty clear to me that you have more than
one question related to ADD. Claiming otherwise is
odd, or perhaps just careless? ("My question" is a
clear assertion that only one question exists, for
you.)

I also do not see the relevance of this particular
question to the mail of mine to which you are
responding. Again that could be down to carelessness,
or perhaps is due to some other reason? I find it
hard to envisage that you really think comreg (the
relevant Irish regulator) ought tell me what I think
about DoH use in my home network. Or perhaps you
somehow consider that there may exist some metric
of network complexity that could differentiate
between networks where regulation is relevant and
where not? As an argument, that'd seem fairly
risible to me TBH.

So I'm left to conclude that your mail is in the
end an example of a pretty careless argument.

I do not think such careless arguments are useful in
what is a controversial and complex space such as this.
In fact, I think such are counterproductive. And FWIW,
I personally tend to more disregard the opinions of
people the more they make such apparently careless
arguments. I hope that others feel similarly, and that
that imposes a pressure on people to be more careful in
how and what they argue.

But maybe I'm wrong in the above. I'd be happy if that
were the case.

Cheers,
S.

> 
> 
> 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."
> 
>>> Applications and cloud services that try to take away from me
>>> the ability to control what goes on inside my personal home
>>> network will be added to my "do not trust" list.
>> I also like to manage my home n/w according to my own wishes. My
>> wishes include not eavesdropping on guest or home user's traffic,
>> except with their agreement, e.g. if someone's device isn't
>> working. (Just in case someone goes there: when some of the home
>> n/w users were too young to agree, we used manage their access to
>> connected devices, not their n/w traffic, e.g. by insisting they be
>> in the same room as an adult, and one of the people who most
>> enforced that policy is decidedly non-technical.)
>> 
>> For me, that means if a guest or other n/w user has chosen an
>> application that wants to do DoH with some other recursive that's
>> ok by me. I'd consider myself inhospitable were I to want to
>> control the DNS choices of people in my home. In a similar vein, I
>> do not insist that people using my home n/w use any particular OS,
>> even though I have strong opinions on the relative goodness of
>> those.
>> 
>> So the important point here is "my network, my rules" does *not*
>> imply "DoH is problematic."
>> 
>> I think that also means that considering the n/w admin as a valid
>> role similarly does not imply that one has a problem with DoH.
>> 
>> There are of course a bunch of specific policies that some n/w
>> admins do like for which DoH is problematic as has been described
>> already on this list. But we ought not over-claim e.g. by asserting
>> that liking DoH implies disliking n/w administration.
>> 
>> Cheers, S.
>> 
>> PS: Neither Barbara nor I are wearing our homenet WG chair hats in
>> this discussion, but I think it's fun that we take different,
>> reasonable, positions:-) <0x5AB2FAF17B172BEA.asc>-- Add mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/add
> 
>

---

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

Sent from my iPhone

> On Aug 13, 2019, at 7:59 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Bret,
> 

I disagree, as I read it as a single question where it is worded so as to ensure the question is applicable regardless of size and scope of network, allowing anyone to answer and provide any relevant provisos concerning their respective answer.

I’ll try to reword it to make a bit more clear, and show that is in fact directly related to your email.

Reworded question (with preamble):
The Internet is a network of networks, where a given host could be seen as “inside” of multiple networks depending only on scope.

E.g. a host attached to a WiFi access point which is connected to your home network, is clearly on the WiFi network, but may or may not be considered “part of” your home network. The same logic is applicable to devices directly connected to your home network, from the perspective of your immediate upstream ISP. Your ISP could have an upstream ISP. And the original host we were talking about could be doing “internet sharing” using any arbitrary network protocol, anything from Bluetooth to serial to Ethernet to satellite.

Each of the aforementioned networks has a nominal network administrator, whether that person takes an active role or not. Each has different scope. 

The question regarding regulators is, is whether the regulations on who is accountable and responsible for adherence to regulations and possibly enforcement of regulations make it clear as to whether the operator of a home network is obligated to enforce the DNS enforcement mechanism and use the mandated list of blocked names, and thusly required by law to prevent bypassing those mechanisms, i.e. to block DoH?

At least, that’s my interpretation of Brad’s question.

Even if it isn’t an accurate interpretation, I think I’d be interested in your opinion on the question, and if you are okay with the question, I’d be interested in your answer.

Related hair-splitting questions: is it always the case (at least in Ireland) that SOMEONE is obligated by the regulators? Do the regulations spell out who is, and whether it is the least specific scoped operator (highest level ISP), or the most specific scoped operator (home network operator), or does everyone have to independently enforce the regulations?

I.e. Does how the home network attach to the Internet fundamentally change the answer?

Brian

---

From: Rob Sayre <[email-masked]>
Date: Tue, 13 Aug 2019 19:36:17 -0700

On Tue, Aug 13, 2019 at 6:54 PM Brian Dickson <[email-masked]>
wrote:

>
> The question regarding regulators is, ...
>

It seems like it would be difficult to formulate this question if one were
not a regulator. Even if one were a regulator, the IETF's protocols span
several jurisdictions.

What is the IETF supposed to do with this message?

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Aug 2019 10:36:36 +0100

This seems to me off-topic for this thread but whatever...

On 14/08/2019 02:54, Brian Dickson wrote:
> The question regarding regulators is, is whether the regulations on
> who is accountable and responsible for adherence to regulations and
> possibly enforcement of regulations make it clear as to whether the
> operator of a home network is obligated to enforce the DNS
> enforcement mechanism and use the mandated list of blocked names, and
> thusly required by law to prevent bypassing those mechanisms, i.e. to
> block DoH?

No.

> Even if it isn’t an accurate interpretation, I think I’d be
> interested in your opinion on the question, and if you are okay with
> the question, I’d be interested in your answer.
> 
> Related hair-splitting questions: is it always the case (at least in
> Ireland) that SOMEONE is obligated by the regulators? Do the
> regulations spell out who is, and whether it is the least specific
> scoped operator (highest level ISP), or the most specific scoped
> operator (home network operator), or does everyone have to
> independently enforce the regulations?

I have no idea as IANAL:-) If someone were to claim that
my home n/w needs to adhere to the same regulations as
a commercial ISP or mobile n/w operator, then I would
be surprised and would disagree with them.

I am nonetheless happy with my policies for my n/w. I
would say Barbara is equally happy with her policies
for her n/w and that we're both entitled to do as we
do.

The point of my mail was to provide a counterexample
showing that one n/w admin's policy finding DoH problematic
is not sufficient reason to claim that DoH is problematic
for all n/w admins, nor that the existence of DoH somehow
calls into question the role of a n/w admin. Neither claim
stands up, and repeating such invalid claims does not
make then valid.

S.

---

From: Neil Cook <[email-masked]>
Date: Wed, 14 Aug 2019 10:47:35 +0100

> On 14 Aug 2019, at 10:36, Stephen Farrell <[email-masked]> wrote:
> 

Did someone say either of those things on this thread? I couldn’t find such assertions, but I agree that the existence DoH in itself isn’t the problem. Personally my problem is with applications/devices that choose to use a different DNS against my wishes as a network administrator, but that’s not the fault of DoH, even if that does seem to have been a catalyst for that behaviour in e.g. browsers. The Chromecast discussion is a good example of that, i.e. it is using regular DNS on port 53.

Neil

> https://www.ietf.org/mailman/listinfo/add

Neil Cook
[email-masked]

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

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

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

---

From: Andrew Campling <[email-masked]>
Date: Wed, 14 Aug 2019 09:53:06 +0000

On 14/08/2019 10:37, Stephen Farrell <[email-masked]> wrote:
> I am nonetheless happy with my policies for my n/w. I would say Barbara is equally happy 
> with her policies for her n/w and that we're both entitled to do as we do.

> The point of my mail was to provide a counterexample showing that one n/w admin's policy 
> finding DoH problematic is not sufficient reason to claim that DoH is problematic for all n/w 
> admins, nor that the existence of DoH somehow calls into question the role of a n/w admin. 
> Neither claim stands up, and repeating such invalid claims does not make then valid.

Surely this is a moot point as, unfortunately, the was the DoH standard has been defined, the network admin (and indeed the device admin if he/she is different) is not able to determine whether they wish to support the protocol.  Irrespective of your network policy, any application that implements DoH will run it across your network unless that application developer has voluntarily chosen to consult you - possible for device admins, harder for network admins except possibly in the home and enterprise.  

As a consequence of the above, it's possible that in future some regulators may instruct network admins (enterprise and ISP) to block DoH resolver IPs in some circumstances.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Aug 2019 11:12:19 +0100

Hiya,

On 14/08/2019 10:47, Neil Cook wrote:
> Did someone say either of those things on this thread? 

That's my interpretation yes. I think Andrew C's mail just
now reinforces that by assuming that the only sane n/w
admin policy is to be upset by DoH.

> I couldn’t
> find such assertions, but I agree that the existence DoH in itself
> isn’t the problem. Personally my problem is with applications/devices
> that choose to use a different DNS against my wishes as a network
> administrator, but that’s not the fault of DoH, even if that does
> seem to have been a catalyst for that behaviour in e.g. browsers. The
> Chromecast discussion is a good example of that, i.e. it is using
> regular DNS on port 53.

Right, that's a more precise statement of a problem for your
policy, but not really for mine.

In my n/w I would also prefer that my son's chromecast
used my DNS, but I'm not terribly upset that it does not, so
I can live with it. (IIRC, it doesn't make DNS queries related
to the content being "cast" but related to s/w update, though
it's quite a while since I looked at that traffic and I did
not spend much time looking at it so the device could be
behaving "worse" than I thought.)

In any case, I'd again compare ADD to choice of OS by people
on my n/w. Despite my strong personal opinions about OSes, my
policy is that the n/w is there for the users and if they've
chosen a crazy OS or application then that's ok as long as it
doesn't conflict with other policies. For example, I did
intercept an attempt to add a "smart speaker" device that
would send audio to a commercial provider and that doesn't
IMO provide adequate controls over that for people who make
noise:-) But a device or application using another DNS
recursive basically doesn't conflict in such a way, so is ok
by me.

Cheers,
S.

---

From: Alec Muffett <[email-masked]>
Date: Wed, 14 Aug 2019 11:33:04 +0100

On Wed, 14 Aug 2019, 10:47 Neil Cook, <neil.cook=
[email-masked]> wrote:

> Personally my problem is with applications/devices that choose to use a
> different DNS against my wishes as a network administrator
>

At risk of sounding flip or overly brief - but I hope this is a fairly
succinct question:

Does your problem extend to applications which use hardcoded IP addresses,
and/or which (eg: Tor, VPN) do not use make visible or make use of DNS at
all on your network?

If so, how do you mitigate, and if not, why not?  I am not asking this to
seek illustration, but to query, in a very concrete sense, whether your
"problem" is orthogonal with how you currently address extant tools which
bypass the controls that you're concerned about lacking.

I am aware of Network Intrusion Detection Solutions (NIDS) which flag the
presence of any IP address on the wire, where that IP has not previously
been returned in a DNS query response.  I am not aware that level of
control being commonly deployed, useful, or interesting.

- alec

---

From: Neil Cook <[email-masked]>
Date: Wed, 14 Aug 2019 12:08:40 +0100

I was talking about my role as network admin in my home, which I have discussed before on this list.

I won’t bore everyone with the details, but I mainly do it to stop my children (and indeed their friends and my extended family’s children) from accidentally accessing content on the internet that is not age appropriate. Hence my particular concern about browsers doing this. My wife also appreciates it as she has clicked on links in plausible-looking spam emails in the past and seen images she would rather not have seen.

If anyone on my network wants to bypass the controls, and they have the wherewithal to change their DNS settings, or setup a VPN, then I don’t attempt to stop them.

Neil

> On 14 Aug 2019, at 11:33, Alec Muffett <[email-masked]> wrote:
> 
> On Wed, 14 Aug 2019, 10:47 Neil Cook, <neil.cook=[email-masked]..org <mailto:[email-masked]>> wrote:
> Personally my problem is with applications/devices that choose to use a different DNS against my wishes as a network administrator
> 
> At risk of sounding flip or overly brief - but I hope this is a fairly succinct question:
> 
> Does your problem extend to applications which use hardcoded IP addresses, and/or which (eg: Tor, VPN) do not use make visible or make use of DNS at all on your network?
> 
> If so, how do you mitigate, and if not, why not?  I am not asking this to seek illustration, but to query, in a very concrete sense, whether your "problem" is orthogonal with how you currently address extant tools which bypass the controls that you're concerned about lacking.
> 
> I am aware of Network Intrusion Detection Solutions (NIDS) which flag the presence of any IP address on the wire, where that IP has not previously been returned in a DNS query response.  I am not aware that level of control being commonly deployed, useful, or interesting.
> 
> - alec
> 
> 
> 
> -- 
> Add mailing list
> [email-masked]

Neil Cook

European Office: 

US Office:

---

From: Joe Abley <[email-masked]>
Date: Wed, 14 Aug 2019 08:58:37 -0400

On 14 Aug 2019, at 05:53, Andrew Campling <[email-masked]> wrote:

> Surely this is a moot point as, unfortunately, the was the DoH standard has been defined, the network admin (and indeed the device admin if he/she is different) is not able to determine whether they wish to support the protocol.

"Wish to support the protocol" is a telling phrase.

The Internet architecture in the opinions of some (I am one) succeeded where other architectures had failed specifically because it did not incorporate access control in the network; it was, in David Isenberg's words, stupid. This was in stark contrast to the so-called intelligent networks of phone companies that sought to control the applications and services that could be provided over the pair of copper or synchronous timeslot made available to a user.

The Internet dispensed with centralised control over toplogy, routing, and (I think importantly) introduced layers that separated not just concepts but responsibility and freedom. The kind of innovation visible to end-users on the Internet happens on the edge, high up in the stack, not in the network.

When I hear network administrators (I am one) talk about the ability to constrain abuse in circumstances where they have responsibility for the devices that they forward packets for, I do not (until now) hear a general expectation of being able to support particular protocols. They are conceptually different, even though many implementations of the former today involve the latter. I think this is important.

If we lose sight of this core principle of the architecture of the network, history suggests it will be replaced by something else. What happened a short number of decades ago was that the phone network became a transport for a new network (leaving the voice network to be relegated to one of many applications that run on top). Perhaps, in microcosm, the idea that the network can contain and control one very specific service, that of name resolution, has spawned a very similar outcome.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Aug 2019 14:18:38 -0400

Sent from my iPhone

> On Aug 14, 2019, at 8:58 AM, Joe Abley <[email-masked]> wrote:
> 

One interesting observation about layers and protocols, is the difference between routing protocols that run on top of IP and those with their own protocol number. One example of the latter is ISIS, an IGP very similar to OSPF. The operational experience with the former (eg BGP and OSPF) and ISIS shows the benefits of having distinct substrates for the control plane, where it is possible. BGP and OSPF eventually had to add defense mechanisms against in-band attacks (eg MD5 and TTL mechanisms), while ISIS was unaffected (AFAIK at least).

It is interesting to consider what possible benefits there might have been or might be in separation of other control planes from the IP data plane, eg if DNS were properly considered a control plane rather than an application, even if only on the client-to-resolver side.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2019 11:26:32 -0700

Isn’t the big difference here that IS-IS is site-local and BGP is not?   Why would it be interesting to consider?  What does this actually have to do with DoH?

Sent from my iPhone

> On Aug 14, 2019, at 11:18 AM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
>

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Aug 2019 15:02:52 -0400

On Wed, Aug 14, 2019 at 2:26 PM Ted Lemon <[email-masked]> wrote:

> Isn’t the big difference here that IS-IS is site-local and BGP is not?
>  Why would it be interesting to consider?  What does this actually have to
> do with DoH?
>

I'm not sure why you reference BGP, when I specifically said, "... eg if
DNS were properly considered a control plane rather than an application,
even if only on the client-to-resolver side."

Also, IS-IS is more generalized as AS-local rather than site-local
(especially in two-level ISIS, where level-1 is typically the site-local
component.)

This is the ADD mailing list, not the DoH mailing list, i.e. applicable to
any applications doing DNS (not DoH exclusively). So, things about DNS that
may not be directly applicable to DoH, or to all DoH cases, could still be
relevant and interesting (e.g. DoH to local resolvers rather than to
centralized quad-X resolvers).

DNS client-to-resolver, when provided over DHCP, is frequently (but not
always) site-local or AS-local, and may also involve forwarders and
resolvers in RFC 1918 space. RFC 1918 is used specifically to avoid being
globally routable, but leads to potential conflicting addressing schemes.
This RFC 1918 usage might not be needed if another substrate is
substituted, which could be site-local or AS-local, but still globally
unique. I.e. fixes some of the issues on naming and discovery, which is an
entire topic area for ADD.

I.e. this might have the potential to actually solve some of the problems
that are being discussed here in ADD currently.

Brian

> >>> Surely this is a moot point as, unfortunately, the was the DoH
> standard has been defined, the network admin (and indeed the device admin
> if he/she is different) is not able to determine whether they wish to
> support the protocol.
> >>
> >> The Internet architecture in the opinions of some (I am one) succeeded
> where other architectures had failed specifically because it did not
> incorporate access control in the network; it was, in David Isenberg's
> words, stupid. This was in stark contrast to the so-called intelligent
> networks of phone companies that sought to control the applications and
> services that could be provided over the pair of copper or synchronous
> timeslot made available to a user.
> >>
> >> The Internet dispensed with centralised control over toplogy, routing,
> and (I think importantly) introduced layers that separated not just
> concepts but responsibility and freedom. The kind of innovation visible to
> end-users on the Internet happens on the edge, high up in the stack, not in
> the network.
> >>
> >> When I hear network administrators (I am one) talk about the ability to
> constrain abuse in circumstances where they have responsibility for the
> devices that they forward packets for, I do not (until now) hear a general
> expectation of being able to support particular protocols. They are
> conceptually different, even though many implementations of the former
> today involve the latter. I think this is important.
> >
> > One interesting observation about layers and protocols, is the
> difference between routing protocols that run on top of IP and those with
> their own protocol number. One example of the latter is ISIS, an IGP very
> similar to OSPF. The operational experience with the former (eg BGP and
> OSPF) and ISIS shows the benefits of having distinct substrates for the
> control plane, where it is possible. BGP and OSPF eventually had to add
> defense mechanisms against in-band attacks (eg MD5 and TTL mechanisms),
> while ISIS was unaffected (AFAIK at least).
> >
> > It is interesting to consider what possible benefits there might have
> been or might be in separation of other control planes from the IP data
> plane, eg if DNS were properly considered a control plane rather than an
> application, even if only on the client-to-resolver side.
> >
> > Brian
> >
> >>
> >> If we lose sight of this core principle of the architecture of the
> network, history suggests it will be replaced by something else. What
> happened a short number of decades ago was that the phone network became a
> transport for a new network (leaving the voice network to be relegated to
> one of many applications that run on top). Perhaps, in microcosm, the idea
> that the network can contain and control one very specific service, that of
> name resolution, has spawned a very similar outcome.
> >>
> >>
> >> Joe
> >
> > --
> > Add mailing list
> > [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2019 14:15:47 -0500

Okay, I think I see what you are saying. You are thinking of the DNS as being something that is really specific to an administrative domain rather than a global database?

Sent from my iPhone

> On Aug 14, 2019, at 2:03 PM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> 
> I'm not sure why you reference BGP, when I specifically said, "... eg if DNS were properly considered a control plane rather than an application, even if only on the client-to-resolver side."
> 
> Also, IS-IS is more generalized as AS-local rather than site-local (especially in two-level ISIS, where level-1 is typically the site-local component.)
> 
> This is the ADD mailing list, not the DoH mailing list, i.e. applicable to any applications doing DNS (not DoH exclusively). So, things about DNS that may not be directly applicable to DoH, or to all DoH cases, could still be relevant and interesting (e.g. DoH to local resolvers rather than to centralized quad-X resolvers).
> 
> DNS client-to-resolver, when provided over DHCP, is frequently (but not always) site-local or AS-local, and may also involve forwarders and resolvers in RFC 1918 space. RFC 1918 is used specifically to avoid being globally routable, but leads to potential conflicting addressing schemes. This RFC 1918 usage might not be needed if another substrate is substituted, which could be site-local or AS-local, but still globally unique. I.e. fixes some of the issues on naming and discovery, which is an entire topic area for ADD.
> 
> I.e. this might have the potential to actually solve some of the problems that are being discussed here in ADD currently.
> 
> Brian
>  
>> 
>> Sent from my iPhone
>>

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Aug 2019 15:38:28 -0400

On Wed, Aug 14, 2019 at 3:15 PM Ted Lemon <[email-masked]> wrote:

> Okay, I think I see what you are saying. You are thinking of the DNS as
> being something that is really specific to an administrative domain rather
> than a global database?
>

The DNS is both a distributed database (I'm not suggesting thinking of that
any differently), and a database look-up and caching system involving
recursive resolvers (necessary to achieve performance at scale).
I'm thinking specifically of the latter on the client-to-resolver piece as
being specific to an administrative domain when configured via an
appropriate mechanism (DHCP, or pushed via enterprise policy engines), and
not necessarily exclusively so.

In addition to the benefits previously mentioned, there are avenues of
attack for poisoning resolvers which rely on the stateless nature of UDP
for client-to-resolver. Those avenues would go away.

DNSSEC is great, but until it is more widely deployed on the authority
side, and validated on clients, there is a big gap, which will continue to
exist for a long time IMHO.

Brian

>> >> When I hear network administrators (I am one) talk about the ability
>> to constrain abuse in circumstances where they have responsibility for the

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2019 14:44:36 -0500

Okay, I hear what you are saying, but you don’t seem to be adding anything new. We’ve already talked about this model.  This is essentially what Joe was talking about a few messages ago: do you want a POTS-like network or a permissionless (dumb) network?

I get the sense that you kind of want both. That’s going to be hard. I don’t think we know how to do it. 

Sent from my iPhone

> On Aug 14, 2019, at 2:38 PM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> 
> The DNS is both a distributed database (I'm not suggesting thinking of that any differently), and a database look-up and caching system involving recursive resolvers (necessary to achieve performance at scale).
> I'm thinking specifically of the latter on the client-to-resolver piece as being specific to an administrative domain when configured via an appropriate mechanism (DHCP, or pushed via enterprise policy engines), and not necessarily exclusively so.
> 
> In addition to the benefits previously mentioned, there are avenues of attack for poisoning resolvers which rely on the stateless nature of UDP for client-to-resolver. Those avenues would go away.
> 
> DNSSEC is great, but until it is more widely deployed on the authority side, and validated on clients, there is a big gap, which will continue to exist for a long time IMHO.
> 
> Brian
>  
>> 
>> Sent from my iPhone
>>

---

From: Bret Jordan <[email-masked]>
Date: Wed, 14 Aug 2019 14:01:11 -0600

It is not just about adding something new to the discussion, but getting a feel for and understanding all of the use cases in and around this. I feel like Brian is doing a great job talking through these points and find his comments to be right on point. 

Thanks,
Bret

> On Aug 14, 2019, at 1:44 PM, Ted Lemon <[email-masked]> wrote:
> 
>> On Wed, Aug 14, 2019 at 3:15 PM Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Aug 14, 2019, at 2:03 PM, Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Aug 14, 2019 at 2:26 PM Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>> > On Aug 14, 2019, at 11:18 AM, Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
>>> > 
>>> > 
>>> > 
>>> > Sent from my iPhone
>>> > 
>>> >>> On Aug 14, 2019, at 8:58 AM, Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
>>> >>> 
>>> > [email-masked] <mailto:[email-masked]>
>>> > https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2019 15:32:03 -0500

> It is not just about adding something new to the discussion, but getting a feel for and understanding all of the use cases in and around this. I feel like Brian is doing a great job talking through…

Out would probably help to be explicit about what you mean by “this” above. I could theorize, but I’m asking all these obnoxious questions because I’m trying to get clarity.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Aug 2019 19:47:10 -0400

> does *not* imply "DoH is problematic."

Agreed.

    > disliking n/w administration.

"Daddy, why can't I print from my LeapFrog?"

--
]               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: Brian Dickson <[email-masked]>
Date: Wed, 14 Aug 2019 21:25:39 -0400

Sent from my iPhone

> On Aug 14, 2019, at 3:44 PM, Ted Lemon <[email-masked]> wrote:
> 

Nothing I was saying changes the nature of the networks in question, actually. It would still be UDP/$foo or TCP/$foo, for some value of $foo. The network is still connectionless, dumb, packet forwarding, just distinct from the full global Internet. It could be IPv6 ULA, or (I think?) ES-IS, or any other similarly behaved network.

At least some of the options for this are feasible for any network to deploy. Each operator would be free to do so with no issues of interoperability as long as client support is available. The ULA one might interesting to try.

> I get the sense that you kind of want both. That’s going to be hard. I don’t think we know how to do it. 

No, definitely not. I’m suggesting there would be value to operators, with no coordination required. The scope would necessarily be limited, and that is a feature rather than a bug. Preventing spoofed packets via transport limits rather than ACLs scales better, requires nearly no configuration, and if a distinct substrate is used across administrative boundaries, is foolproof.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Aug 2019 21:50:49 -0400

Sent from my iPhone

> On Aug 14, 2019, at 5:36 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> calls into question the role of a n/w admin.

I think you are misunderstanding the specific argument.

The argument is roughly as follows:
1. DoH is problematic for some network admins.
2. A protocol which was a priori known to be problematic for some network admins ought to have been opposed to by all network admins. 
3. In particular, a preexisting protocol that provides the same privacy qualities as DoH was available (DoT), which might have been a better option.

As far as I can tell from previous comments, I believe you would not oppose use of DoT on your network any more than you would DoH (which you seem to be fine with).

So, DoT would be fine for both Barbara and you, while DoH causes problems for Barbara but not for you.

I am saying collectively it makes sense to say DoH has problems for some network admins while DoT has none of those problems. This is strictly discussing network admins and not users.

As a network admin exclusively, and/or as a user with no upstream network which blocks DoT, would you be okay if only DoT were available for use in implementing DNS privacy? Eg if DoH were not available from your choice of browser or resolver?

Brian

> Neither claim
> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Aug 2019 02:54:53 +0100

On 15/08/2019 02:50, Brian Dickson wrote:
> 2. A protocol which was a priori known to be problematic for some
> network admins ought to have been opposed to by all network admins.
Yeah, that's nonsense. Again.

The pattern of nonsensical commentary sprinkled on this
list is by now, and sadly, well established.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Aug 2019 02:37:28 +0000

> 3. In particular, a preexisting protocol that provides the same privacy qualities as DoH was available (DoT), which might have been a better option.

This misses a large point. Browser implementers didn't need a standard for DoH: they could have done it without any standardization at all. In fact, Google already had a (IMHO significantly worse) DNS-over-HTTPS proposal that was already being implemented before the DoH WG even started up.

The fact that network operators don't want DNS-over-HTTPS, standardized or not, is relevant when they are speaking about the problems they face. Telling browser and app vendors that DoT is "a better option" indicates that you know their business better than they do, and that attitude sucks just as much as them telling you that they know more about your business than you do.

--Paul Hoffman

---

From: George Michaelson <[email-masked]>
Date: Thu, 15 Aug 2019 13:25:38 +1000

Thanks for saying this Paul.

This is substantively my point made (badly) at microphones: The DNS as
the single inherent reference for name:address mapping is only "true"
if you ignore the various approaches to HOSTS.TXT which a number of
people already encode into their .js and can use freely. As far as
"permissionless networks" go the cat is well and truly out of the bag
here. URL encoding and re-writing inside the browser and the web page,
is a "thing"

Where I would change my position, is that I was in a more lax,
permissive state of mind about DoH which I now realize was at fault:
the fracture lines in the *semantic intent* of a name, domain or
otherwise, and its binding to an IP address, this is a huge moment.

We're throwing out the window something integral to what we've done,
since we stopped cohering around HOSTS.TXT in the NIC model.  What I
think guardian.co.uk means, has to be semantically equivalent to what
you think guardian.co.uk means, or we cannot have a "real"
conversation about what lies there in the web, or any other service.
If we don't cohere to a single namespace, how is that going to be
possible?

-g

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 15 Aug 2019 13:55:02 +1000

I'm still struggling to find a way to make this discussion productive.  There's an end state I want to avoid where this whole thing escalates with various attempts at blocking on one side and increasingly horrible tunneling on the other.  The fact that people are willing to talk gives me a little hope here, but it's hard to get past the negativity.

>From the application side of this, considering deployment of a system with pre-selected resolvers, I'm motivated by understanding the consequences of that choice.  At this stage, it seems unlikely that some new understanding will cause me (or - to be correct - my organization) to completely reconsider plans, but that doesn't mean that those plans can't be changed.

I am reminded of a similar change starting about 6 years ago, right after I joined Mozilla.  At the time, the web had started to move more aggressively to HTTPS.  And browsers were pushing hard.  Some network operators were quite vocal in opposition to policy changes that would have accelerated the change.  

There was a complex set of use cases, as you might expect might arise from decades of development in an environment that had no effective security measures in place.  For instance, caching of HTTP was seen at the time as critical for network performance; many networks deployed transparent proxies to provide that capability.  There were also transcoding proxies and all sorts of amazing optimizations in place. The value of knowing that someone is about to watch a video - and how long that video is - has real benefits for network capacity planning.  That sort of privacy violation was hardly the worst thing going around either.

We started a process whereby we looked at the various use cases in some detail and worked through each in turn.  In doing so, we got better understanding of the problem space and identified a number of key areas of genuine pain.  

It required having someone sit down and produce a dispassionate assessment of each use case in turn, reaching agreement that the analysis was at least accurate, then deciding what was important enough to do something about.  I remember at least one face-to-face meeting and a good number of conference calls just to get to the point.  But it was worth it.  It resulted in new work being undertaken, some of which continues today in various places.  For me though, the most valuable outcome was a better shared understanding.

It doesn't take much squinting to see the similarities in the two situations.  If others are willing to participate in such a process, I'd be happy to be a part of that.

On Thu, Aug 15, 2019, at 12:37, Paul Hoffman wrote:
> The fact that network operators don't want DNS-over-HTTPS, standardized 
> or not, is relevant when they are speaking about the problems they 
> face. Telling browser and app vendors that DoT is "a better option" 
> indicates that you know their business better than they do, and that 
> attitude sucks just as much as them telling you that they know more 
> about your business than you do.

For my own part in that, I apologize.  I'm trying to do better at formulating arguments that are less combative, and still learning.

> list is by now, and sadly, well established.

A reminder to keep things civil.  We're all here to resolve our differences.  I can see that this was intended to ridicule an idea and not an individual, but I am certain that less emotive language would be effective.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 00:24:37 -0400

On Wed, Aug 14, 2019 at 10:37 PM Paul Hoffman <[email-masked]>
wrote:

> > 3. In particular, a preexisting protocol that provides the same privacy
> qualities as DoH was available (DoT), which might have been a better option.
>
> This misses a large point. Browser implementers didn't need a standard for
> DoH: they could have done it without any standardization at all. In fact,
> Google already had a (IMHO significantly worse) DNS-over-HTTPS proposal
> that was already being implemented before the DoH WG even started up.
>
> The fact that network operators don't want DNS-over-HTTPS, standardized or
> not, is relevant when they are speaking about the problems they face.
> Telling browser and app vendors that DoT is "a better option"

With respect, Paul, I *specifically* said "might have been" not "is", in
reference to a better option. It was not only intended to acknowledge that
I might be wrong in this, but also that the correct tense is, I think, past
imperfect or something to that effect. I.e. we are passed the point where
the issue has become moot, with the caveat that being a protocol thing, it
can always be un-mooted with varying amounts of difficulty.

The big issue I have with 8484 was the specification of the port number.
Everything else about DoH was fine, and would have been perfectly adequate.
Only the obfuscation of DNS within the regular HTTPS channel, was
contentious to me, and I believe to other network operators.

The benefits otherwise of using the HTTP encoding and all the other channel
sharing etc., got lost in the larger discussion, which I think is a big
shame.

If the browser implementers would ever have considered non-443 as the port
for the DoH binding, I think all of this could have been easily avoided.
While that is mostly 20/20 hindsight, it isn't entirely moot.

My perspective is, that a non-443 port is not too late to converge upon,
but would require engagement from the browser community, and I'm not sure
I'm the right one to raise the issue. In fact, I'm pretty sure I'm not.

So, I am leaving this as an opening for anyone else to step up, and see if
there is any possible path to explaining and justifying the prospect of
DoH!443 (DoH over not-443).

> attitude sucks just as much as them telling you that they know more about
> your business than you do.
>

I'm concerned about their implementation choices more than their protocol
selection.
But those aren't on topic for ADD, at least I don't think they are.

However, it may be the case that those concerns rise to the level of being
independent of which implementation, or which application, is doing DNS.
As such, I will probably try to raise that in a separate discussion
thread(s), with very specific Subject line(s).

It is not easy to make major changes to how DNS client communications work,
and the more experience from the DNS community (and to a lesser degree,
security architecture and systems administration communities) the better
the outcome for everyone.

I'm also trying to figure out ways of addressing the split-dns and the RPZ
issues, via technology, so that it might be possible to avoid the current
requirement that only a single DNS resolver be used. More on that later
(I'm on vacation and getting in trouble for spending time not on the beach.)

Sincerely,
Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Aug 2019 00:28:52 -0500

[as an individual]

On 8/14/19 11:24 PM, Brian Dickson wrote:
> My perspective is, that a non-443 port is not too late to converge 
> upon, but would require engagement from the browser community, and I'm 
> not sure I'm the right one to raise the issue. In fact, I'm pretty 
> sure I'm not.

I think there is a key point that is being broadly missed here.

I infer from your statements that you see the property that DoH cannot 
generally be distinguished from ordinary web traffic as a low-order 
protocol design decision that could be adjusted while still retaining 
the benefits that are driving DoH's adoption.

Having been rather deeply involved in many conversations from a browser 
perspective, I can comfortably state that that this *is* the singularly 
most important property of the protocol that is driving DoH's adoption. 
You don't have to agree with the reasons for this, or even to understand 
them, but this is the ground truth that can't really be worked around.

Martin's recent summary of the situation by way of analogy to HTTPS 
adoption is a good one, and I encourage you to re-read it with the 
foregoing assertion in mind. There are legitimate network operator 
interests here, and we are keenly interested in preserving them in the 
face of this change -- but the future will not look like the past, and 
we need to figure out new ways to solve old problems. It would be ideal 
if you and other operators were involved in coming up with these new 
solutions.

/a

---

From: Bret Jordan <[email-masked]>
Date: Wed, 14 Aug 2019 23:54:16 -0600

Martin,

While I agree with Brian and I think he makes a lot of great points, from my perspective the biggest problems are:

1) The potential for involuntary mass centralization of DNS data and the consistent erosion of privacy that comes from it 

2) Clients and apps not respecting the users’ or network admins’ preferred DNS / DoH server

3) The fact that the WG seemed to completely ignore the split DNS use case / requirement when they were designing this. IMO, this just shows that the process of review and due diligence failed at some level.

4) The potential lack of DNS optimization based on geolocation and optimized routes.  

5) I am also worried about performance at scale and would love to see some significantly relevant research and data that compares performance of DoH and D53 not just from home users but also from geo-diverse enterprises. 

6) Potential of leakage of private corporate information out to some DoH provider. 

Thanks,
Bret

> On Aug 14, 2019, at 9:55 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 09:20:34 +0200

> 2) Clients and apps not respecting the users’ or network admins’ preferred

Well, the user and the network admin are two very different things. I agree
that applications should respect the user's preferred server to the extent
to which that is discernible, which is why Firefox will the user to disable
DoH or select their own provider, even in cases where we have enabled DoH
by default. However, in the vast majority of cases, the resolver that the
machine is using does not reflect the user's conscious choice, but rather
invisible network configuration, and I don't believe that it's necessarily
desirable to respect that.

As for respecting the network admin's preferred server, the basic
assumption of DoH/TRR is that given the current information available to
the client about the network's preferences, the user is better served by
selecting a different resolver. If it becomes possible to determine that
the network prefers a resolver with acceptable policies, that might change,
but that's presently not the case.

>
> 3) The fact that the WG seemed to completely ignore the split DNS use case
> / requirement when they were designing this. IMO, this just shows that the
> process of review and due diligence failed at some level.
>

Well, I can't speak for "seems", but DoH works just fine with split DNS use
cases if the resolver that is selected is the split resolver. And since DoH
takes no position on how the resolver is selected, I don't think that was
ignored so much as out of scope.

4) The potential lack of DNS optimization based on geolocation and
> optimized routes.

Our measurements indicate that to the effect there is a difference, the
effect is relatively modest.  See:
https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/.
I'm not aware of any other measurements, but I'd be interested to see them
if they exist.

> 5) I am also worried about performance at scale and would love to see some
> significantly relevant research and data that compares performance of DoH
> and D53 not just from home users but also from geo-diverse enterprises.
>

Our measurements were taken from Firefox users generally, not specifically
from home users. With that said, enterprises often disable Firefox
experiments, so those measurements probably overweight home users. I'd
certainly be interested in hearing experimental proposals for how to target
enterprises specifically.

6) Potential of leakage of private corporate information out to some DoH
> provider.

I agree that this is a potential issue, which is why I think it's
worthwhile to develop mechanisms for administrators to disable DoH.
However, at the end of the day, those mechanisms will need to rely on
control of the computer for the reasons mentioned above.

-Ekr

> I'm still struggling to find a way to make this discussion productive.
> There's an end state I want to avoid where this whole thing escalates with
> various attempts at blocking on one side and increasingly horrible
> tunneling on the other.  The fact that people are willing to talk gives me
> a little hope here, but it's hard to get past the negativity.
>
> From the application side of this, considering deployment of a system with
> pre-selected resolvers, I'm motivated by understanding the consequences of
> that choice.  At this stage, it seems unlikely that some new understanding
> will cause me (or - to be correct - my organization) to completely
> reconsider plans, but that doesn't mean that those plans can't be changed.
>
>
> I am reminded of a similar change starting about 6 years ago, right after
> I joined Mozilla.  At the time, the web had started to move more
> aggressively to HTTPS.  And browsers were pushing hard.  Some network
> operators were quite vocal in opposition to policy changes that would have
> accelerated the change.
>
> There was a complex set of use cases, as you might expect might arise from
> decades of development in an environment that had no effective security
> measures in place.  For instance, caching of HTTP was seen at the time as
> critical for network performance; many networks deployed transparent
> proxies to provide that capability.  There were also transcoding proxies
> and all sorts of amazing optimizations in place. The value of knowing that
> someone is about to watch a video - and how long that video is - has real
> benefits for network capacity planning.  That sort of privacy violation was
> hardly the worst thing going around either.
>
> We started a process whereby we looked at the various use cases in some
> detail and worked through each in turn.  In doing so, we got better
> understanding of the problem space and identified a number of key areas of
> genuine pain.
>
> It required having someone sit down and produce a dispassionate assessment
> of each use case in turn, reaching agreement that the analysis was at least
> accurate, then deciding what was important enough to do something about.  I
> remember at least one face-to-face meeting and a good number of conference
> calls just to get to the point.  But it was worth it.  It resulted in new
> work being undertaken, some of which continues today in various places.
> For me though, the most valuable outcome was a better shared understanding.
>
> It doesn't take much squinting to see the similarities in the two
> situations.  If others are willing to participate in such a process, I'd be
> happy to be a part of that.
>
> For my own part in that, I apologize.  I'm trying to do better at
> formulating arguments that are less combative, and still learning.
>
> A reminder to keep things civil.  We're all here to resolve our
> differences.  I can see that this was intended to ridicule an idea and not
> an individual, but I am certain that less emotive language would be
> effective.
>
> --
> Add mailing list
> [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 09:25:58 +0200 (CEST)

> desirable to respect that.

If a DoH-to-the-cloud-enabled browser stops working because of DoH related 
problems, who do you think the customer will call first? The browser 
support service, or the ISP/network customer support service?

If you say they'll call the ISP/network admin, then your entire line of 
reasoning above falls flat.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 09:45:36 +0200

On Thu, Aug 15, 2019 at 9:25 AM Mikael Abrahamsson <[email-masked]> wrote:

> >> 2) Clients and apps not respecting the users’ or network admins’
> preferred
> >> DNS / DoH server
> >>
> >

Misdirected customer service complaints are a fact of life. We not
infrequently get bug reports on Firefox for defects in sites, servers, etc.

I regularly hear complaints that if Facebook stops working for any reason,
people call their ISP, so this case doesn't seem that different to me.

-Ekr

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 15 Aug 2019 09:51:27 +0200

On 15 Aug 2019, at 9:20, Eric Rescorla wrote:

> However, in the vast majority of cases, the resolver that the machine is using does not reflect the user's conscious choice, but rather invisible network configuration, and I don't believe that it's necessarily desirable to respect that.

If the user == the network administrator, for example behind a CPE at a persons home, then respecting the user is to respect the network administrator definitions.

   Patrik

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 15 Aug 2019 10:08:47 +0200 (CEST)

On Thu, 15 Aug 2019, Brian Dickson wrote:

> for the DoH binding

"browser implementers" allow the DoH server to be specified as a URL 
(template), which contains a port number. You're free to use a non-443 port 
there. HTTPS does however use 443 by default and it would be highly strange 
for DoH to try to change that...

> I think all of this could have been easily avoided.

I disagree. It would make DoH a whole lot less useful in my view as then 
coffere shop operators can easily take away my ability to chose to use DoH, 
for example.

-- 

  / daniel.haxx.se

---

From: Rob Sayre <[email-masked]>
Date: Thu, 15 Aug 2019 01:34:34 -0700

> an individual, but I am certain that less emotive language would be

It's not clear to me why you would be certain.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Aug 2019 10:34:53 +0100

Hi Martin,

On 15/08/2019 04:55, Martin Thomson wrote:
>> The pattern of nonsensical commentary sprinkled on this list is by
>> now, and sadly, well established.
> differences.  I can see that this was intended to ridicule an idea
> and not an individual, but I am certain that less emotive language
> would be effective.

Hmm. Well I don't think calling out a nonsensical argument
is uncivil, nor was I ridiculing anything or anyone. In fact,
treating such an argument as if it were not nonsensical
would seem to me more likely ridiculous and likely to lead
to emotive language and ridicule, especially if there's a
pattern of such careless statements, which I think is the
case.

I do get that all may make it harder to establish the
kind of conversation you're trying to have, but ISTM that
the problem is not with calling out nonsense, but rather
with emitting nonsense. The people who have problems with
DoH do have good arguments to make but sprinkling bad
arguments amongst those is a big part of what makes the
discussion harder IMO.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Aug 2019 10:58:34 +0100

Hi Patrik,

On 15/08/2019 08:51, Patrik Fältström wrote:
>> However, in the vast majority of cases, the resolver that the
>> machine is using does not reflect the user's conscious choice, but
>> rather invisible network configuration, and I don't believe that
>> it's necessarily desirable to respect that.
> 
> If the user == the network administrator, for example behind a CPE at
> a persons home, then respecting the user is to respect the network
> administrator definitions.

I'm not sure its that simple.

In the case of Barbara's home n/w I think your point applies
as she stated. In my home n/w it doesn't as I've no problem
with a browser using DoH in the way Mozilla have planned.

I could still have problems with other ADD setups, e.g. if
some other application was (ab)using DNS traffic for profit
or tracking or was using a DNS recursive that was flakey.
But that's more a problem with that application than with
DoH, for me.

But I would guess for the vast majority of home networks, the
user is not really the n/w administrator, but rather their
current ISP is really performing that role, for DNS. And in
those cases, I would say most people don't care as they don't
even know DNS exists. Of those who do care, I have no idea
how many might prefer to keep with their ISP's chosen DNS
settings and how many might be ok with Mozilla's plans.

I would guess many would be unhappy if their DNS server
were flakey or abusive, and while that could happen in any
scenario, presumably many home network users are ok with
their ISP controlling DNS as they'd change ISP. There
are of course some places where there's little choice of
ISP, but I'm not sure if flakey DNS is or is not a real
problem in those places.

I guess (but don't know), that for a home network user,
ADD being used by many applications is perhaps more risky
than the status quo ante, where the ISP provides DNS for
basically all applications, as the probability of a flakey
or abusive DNS server being used by some application could
be high.

OTOH of course, if the same application install is used
in the home but also in multiple other n/w contexts, (like
a browser on a mobile device) then the risk/benefit
balance can change, so that the benefit of DNS privacy
via DoH is more substantial.

All that said though, I'm not sure what the IETF could
or should do about the risks and benefits here, other
than perhaps analyse and document them in what may
have to be a fairly abstract manner, in the hope that
that helps n/w admins and application developers do
better than would otherwise be the case.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 12:13:53 +0200

On Thu, Aug 15, 2019 at 9:51 AM Patrik Fältström <[email-masked]> wrote:

> > However, in the vast majority of cases, the resolver that the machine is
> using does not reflect the user's conscious choice, but rather invisible
> network configuration, and I don't believe that it's necessarily desirable
> to respect that.
>
> If the user == the network administrator, for example behind a CPE at a
> persons home, then respecting the user is to respect the network

Well, maybe.  For instance, if I am at friend's house, they're the network
administrator and I am the user. However, in cases where they are one and
the same, yes, it would be great to have a way to mechanically determine
that that was the case. However, the current technical mechanisms we have
do not in fact provide that.

-Ekr

---

From: Neil Cook <[email-masked]>
Date: Thu, 15 Aug 2019 11:22:13 +0100

> On 15 Aug 2019, at 10:58, Stephen Farrell <[email-masked]> wrote:
> 

One very real use case, which we have discussed on this list multiple times, is that of people using an ISP’s parental control (and indeed malware detection) products which are based on DNS. In the UK that is a lot of households (over a million if I’m not mistaken). 

So I do know that all those people, who almost certainly know nothing about DNS, will be unhappy with Mozilla (or whomever) if it means that their parental controls stop working.

Neil Cook

European Office: 

US Office:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 12:28:13 +0200 (CEST)

On Thu, 15 Aug 2019, Eric Rescorla wrote:

> Well, maybe.  For instance, if I am at friend's house, they're the 
> network administrator and I am the user. However, in cases where they 
> are one and the same, yes, it would be great to have a way to 
> mechanically determine that that was the case. However, the current 
> technical mechanisms we have do not in fact provide that.

There is no mechanical way to test this unless you ask the user. There is 
no way anyone can come up with a heuristic for "who does the user trust".

If an application vendor wants this information from the OS/connection 
manager, then we should make sure this information is available via some 
mechanism/API.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Aug 2019 11:28:47 +0100

On 15/08/2019 11:22, Neil Cook wrote:
> One very real use case, which we have discussed on this list multiple
> times, is that of people using an ISP’s parental control (and indeed
> malware detection) products which are based on DNS. In the UK that is
> a lot of households (over a million if I’m not mistaken).
> 
> So I do know that all those people, who almost certainly know nothing
> about DNS, will be unhappy with Mozilla (or whomever) if it means
> that their parental controls stop working.
That's a fair point. Not that I believe in such controls
nor their efficacy, but I do accept that surprising some
of those people will not be universally welcomed. So if we
did document the risks/benefits, that element of surprise
ought be in the risk column I guess.

S.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 12:30:23 +0200 (CEST)

On Thu, 15 Aug 2019, Neil Cook wrote:

> about DNS, will be unhappy with Mozilla (or whomever) if it means that 
> their parental controls stop working.

This is indeed true and relevant:

https://www.zdnet.com/article/mozilla-no-plans-to-enable-dns-over-https-by-default-in-the-uk/

The weird thing is that we're still having the discussion like the above 
never happened.

---

From: Neil Cook <[email-masked]>
Date: Thu, 15 Aug 2019 11:33:46 +0100

>  So if we did document the risks/benefits, that element of surprise

Indeed, it is irrelevant what any of us think about the efficacy of such solutions, they are very real, and many people use them. And it is exactly the kind of thing that we should be documenting, along with the other use-cases such as CDNs, split-horizon etc.

Neil

> On 15 Aug 2019, at 11:28, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Neil Cook

European Office: 

US Office:

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 12:38:00 +0200

On Thu, Aug 15, 2019 at 12:22 PM Neil Cook <[email-masked]>
wrote:

> malware detection) products which are based on DNS. In the UK that is a lot
> of households (over a million if I’m not mistaken).
>

Agreed.This is why we are working to develop mechanisms to detect this
case. See
https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-https-doh-update-detecting-managed-networks-and-user-choice/
for more details.

-Ekr

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 15 Aug 2019 13:42:49 +0200

> do not in fact provide that.

I just wanted to bring up the fact things is not as white and black which some arguments on this discussion is. This is hard.

I use this as an argument to yes bring in DoT and standardise how DoH works but let the default setting continue to be set per operating system and by the network administrator (i.e. using the zeroconf mechanisms we have developed at the IETF).

I like for example the DNSSEC-Trigger program provided by NLNetLabs:

<https://nlnetlabs.nl/projects/dnssec-trigger/about/>

It uses the default setting, tries and checks if a local resolver "works", and let me know if it doesn't (so I can choose what measures I want to use, which normally is to faster start a VPN, and THEN a local resolver). If it does, it changes the resolver to 127.0.0.1 in my laptop and do all queries by itself. I.e. overrides what the network administrator gave me as a default. But, I expect all my applications to use the setting I set.

So the real discussion I think include questions of:

- Where do the default setting come from?
- Is The DNS Setting same for a computer or per application?
- Are the DNS queries identifiable by the network administrator or not?

And not even those have black and white answers. For example, if I open a VPN the DNS queries inside the tunnel will not be visible. And sure, my favourite answers to those questions are most certainly different than your answers Eric.

The IETF dilemma :-)

Best,

   Patrik

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Aug 2019 12:29:25 +0000

> Agreed. This is why we are working to develop mechanisms to detect this case. See <url> for more details.

It appears from this that you're also doing lots of tests and experiments. That's great. I'd like to suggest the following experiment:
How often will a DNS query for CDN content to Cloudflare (e.g., via DoH, but what DNS goes over isn't important) provide a different IP address than the same query to the ISP resolver? Of particular interest are mobile networks. One of the fears is lots of high-bandwidth content (video streams) being shifted to take paths that hadn't been engineered to handle the shifted traffic. The experiment probably needs to be more nuanced (maybe different IP address isn’t the right thing to look for), but you get the idea.

It's more than just performance of the query or receipt of the first website packet. We need to understand if large amounts of CDN content will come at access networks using different paths and links.
Thx,
Barbara

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 15 Aug 2019 15:20:05 +0200

Moin!

On 15 Aug 2019, at 14:29, STARK, BARBARA H wrote:

> It appears from this that you're also doing lots of tests and 
> experiments. That's great. I'd like to suggest the following 
> experiment:
> How often will a DNS query for CDN content to Cloudflare (e.g., via 
> DoH, but what DNS goes over isn't important) provide a different IP 
> address than the same query to the ISP resolver? Of particular 
> interest are mobile networks. One of the fears is lots of 
> high-bandwidth content (video streams) being shifted to take paths 
> that hadn't been engineered to handle the shifted traffic. The 
> experiment probably needs to be more nuanced (maybe different IP 
> address isn’t the right thing to look for), but you get the idea.
>
> It's more than just performance of the query or receipt of the first 
> website packet. We need to understand if large amounts of CDN content 
> will come at access networks using different paths and links.
While this study is not exactly what you envision, but comes close and 
is a clear indicator that there will be a shift if we don’t use on 
network resolvers or ECS:
	https://www.samknows.com/blog/dns-over-https-performance

So long
-Ralf
—--
Ralf Weber

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 15:20:00 +0200

On Thu, Aug 15, 2019 at 2:29 PM STARK, BARBARA H <[email-masked]> wrote:

> It appears from this that you're also doing lots of tests and experiments.
> That's great. I'd like to suggest the following experiment:
> How often will a DNS query for CDN content to Cloudflare (e.g., via DoH,
> but what DNS goes over isn't important) provide a different IP address than
> the same query to the ISP resolver? Of particular interest are mobile
> networks. One of the fears is lots of high-bandwidth content (video
> streams) being shifted to take paths that hadn't been engineered to handle
> the shifted traffic. The experiment probably needs to be more nuanced
> (maybe different IP address isn’t the right thing to look for), but you get
> the idea.
>

We'd certainly be happy to talk to CDNs who have ideas for further research.

-Ekr

> website packet. We need to understand if large amounts of CDN content will
> come at access networks using different paths and links.
> Thx,
> Barbara
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 09:28:16 -0400

A non-443 port won’t work because it will enable filtering by malicious resolvers on path. The problem is we have no way to determine what is malicious intercept and what is authorized. 

Sent from my iPhone

> On Aug 15, 2019, at 00:25, Brian Dickson <[email-masked]> wrote:
> 
> My perspective is, that a non-443 port is not too late to converge upon, but would require engagement from the browser community, and I'm not sure I'm the right one to raise the issue. In fact, I'm pretty sure I'm not.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 15:49:33 +0200

>         https://www.samknows.com/blog/dns-over-https-performance

Bottom lining this, it seems like the results are broadly consistent with
ours: when DoH/TRR through Cloudflare is used, different CDN nodes are
used, but there's no significant performance difference.

-Ekr

---

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

Silly question. We’re talking about how it would be nice to document the issues that will come up as a result of DoH being in the wild, and perhaps the solutions people propose, whether they are recommended by the IETF or not.

Is anyone in fact writing that document?

Sent from my iPhone

> On Aug 15, 2019, at 09:50, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> 
> Bottom lining this, it seems like the results are broadly consistent with ours: when DoH/TRR through Cloudflare is used, different CDN nodes are used, but there's no significant performance difference.
> 
> -Ekr
> 
>> 
>> 
>> So long
>> -Ralf
>> —--
>> Ralf Weber
> -- 
> Add mailing list
> [email-masked]

---

From: Neil Cook <[email-masked]>
Date: Thu, 15 Aug 2019 15:08:35 +0100

> On 15 Aug 2019, at 14:49, Eric Rescorla <[email-masked]> wrote:
> 
> 
From the study:

> Whilst the BBC uses Akamai extensively, none of the assets on the BBC News homepage were served from 
> on-prem Akamai caches within ISP networks at the time of testing (the on-prem caches are certainly used for 
> other BBC services though, such as videos on iPlayer).

Which means that it’s not a true comparison of the performance difference experienced for things like streaming video, which is one of the primary motivations for on-premise caching for CDNs. So it would be more accurate to say that the study shows that there’s no significant performance difference for content served from off-net CDN nodes.

Neil Cook

European Office: 

US Office:

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 16:11:44 +0200

On Thu, Aug 15, 2019 at 4:08 PM Neil Cook <[email-masked]>
wrote:

> Which means that it’s not a true comparison of the performance difference
> experienced for things like streaming video, which is one of the primary
> motivations for on-premise caching for CDNs. So it would be more accurate
> to say that the study shows that there’s no significant performance
> difference for content served from off-net CDN nodes.
>

As I said, I'm certainly interested in any data that someone would like to
share.

-Ekr

Neil Cook

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 15 Aug 2019 16:42:46 +0200

Moin!

> used, but there's no significant performance difference.
There is no performance difference, because no one is using it. The fact
that different nodes are used has a big impact both performance and
commercial if there was a large population that had to get something
from a location that was not designed to handle its load over links that
were not sized to handle this load.

And ISP and content/CDN providers would have to bear the cost of that
traffic that otherwise would flow at much lower cost inside the provider
network, often not leaving the POP where the user connects.

So long
-Ralf
—--
Ralf Weber

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 15 Aug 2019 16:52:27 +0200

Moin!

On 15 Aug 2019, at 15:57, Ted Lemon wrote:

> Silly question. We’re talking about how it would be nice to document 
> the issues that will come up as a result of DoH being in the wild, and 
> perhaps the solutions people propose, whether they are recommended by 
> the IETF or not.
>
I seem to recall we had two drafts presented in the first add session ( 
draft-livingood-doh-implementation-risks-issues and 
draft-reid-operator-doh) which already captured a lot of the concern. I 
would hope that we continue to work on them within the framework that is 
yet to be setup by the IETF leadership.

So long
-Ralf
—--
Ralf Weber

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Aug 2019 14:57:16 +0000

> There is no performance difference, because no one is using it. The fact that
> different nodes are used has a big impact both performance and commercial
> if there was a large population that had to get something from a location that
> was not designed to handle its load over links that were not sized to handle
> this load.

> network, often not leaving the POP where the user connects.

I think Netflix proved quite well what happens when a massive amount of traffic is shifted to take a different path that doesn't have the capacity to handle that traffic. Of course, Netflix (and pretty much everyone else) blamed the ISPs for all the dropped packets.

The question that crossed my mind in reading the SamKnows results, was if requesting CDN content from the Google or Cloudflare CDN would have had different results. 
Barbara

---

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

On Aug 15, 2019, at 7:52 AM, Ralf Weber <[email-masked]> wrote:
> I seem to recall we had two drafts presented in the first add session ( draft-livingood-doh-implementation-risks-issues and draft-reid-operator-doh) which already captured a lot of the concern. I would hope that we continue to work on them within the framework that is yet to be setup by the IETF leadership.

I think these documents were views from the authors’ perspectives on the topic.  What I’m talking about is more a collection of the discussion of the whole group, rather than a single coherent view, no matter how interesting that might be.

I mention this because we keep going back over territory we’d already covered.

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 15 Aug 2019 17:11:26 +0200

Moin!

On 15 Aug 2019, at 16:57, STARK, BARBARA H wrote:
> I think Netflix proved quite well what happens when a massive amount 
> of traffic is shifted to take a different path that doesn't have the 
> capacity to handle that traffic. Of course, Netflix (and pretty much 
> everyone else) blamed the ISPs for all the dropped packets.
Yeah the messenger of bad news is usually shot ;-).

> The question that crossed my mind in reading the SamKnows results, was 
> if requesting CDN content from the Google or Cloudflare CDN would have 
> had different results.
Of course it would as having the client IP allows you to make much 
better mapping decision. The Google resolver shows this already for the 
SamKnows case as it is forwarding the client network using EDNS0 Client 
Subnet (ECS - RFC7871).

So long
-Ralf
—--
Ralf Weber

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 12:52:43 -0400

Sent from my iPhone

> On Aug 15, 2019, at 1:28 AM, Adam Roach <[email-masked]> wrote:
> 
> [as an individual]
> 
> I infer from your statements that you see the property that DoH cannot generally be distinguished from ordinary web traffic as a low-order protocol design decision that could be adjusted while still retaining the benefits that are driving DoH's adoption.
> 
> Having been rather deeply involved in many conversations from a browser perspective, I can comfortably state that that this *is* the singularly most important property of the protocol that is driving DoH's adoption. You don't have to agree with the reasons for this, or even to understand them, but this is the ground truth that can't really be worked around.

This is what I find extremely annoying.

We are (all of us) asking someone to explain.

You claim to actually know but effectively refuse to even attempt to explain.

I will try to elicit a meaningful response:

Is the primary purpose of intermingling DoH with 443 traffic to prevent blocking DNS resolution?

Hypothetical (but very important question):
If ALL browser DNS traffic was sent over BOTH DoH and DoT in parallel (both encrypted, sent to the same resolver), do you agree that the privacy would be the same (same encryption) and the unblockability would be unchanged? 

The reason for doing this would be to allow the choice of resolver (per client/app) to be discoverable. This is one significant gap in the DoH-only model. It would not require that the browser (or any other app) wait for both answers, so would at worst have no affect on performance, and at best would improve performance.

One variant to consider would be sending a DoT-like DNS query with only the query NAME encrypted or hashes (ie completely different from DoT or DoH where the entire DNS message is encrypted) and to return A and AAAA RDATA and QID and port number unencrypted (but encrypt all other fields and all other RDATA responses). This would allow IDS/firewall systems to control access on the basis of DNS answers, without needing to know the question.

If there is anything else you can share to enlighten everyone on the reasons, reasoning, and/or requirements from the browser side, it would be greatly appreciated by everyone.

(We are, IMHO, interested in the necessary attributes, vs beneficial attributes, specifically on privacy exclusively; there may be other requirements for providing security which might be achievable with a different set of mechanisms.)

Brian

> 
> Martin's recent summary of the situation by way of analogy to HTTPS adoption is a good one, and I encourage you to re-read it with the foregoing assertion in mind. There are legitimate network operator interests here, and we are keenly interested in preserving them in the face of this change -- but the future will not look like the past, and we need to figure out new ways to solve old problems. It would be ideal if you and other operators were involved in coming up with these new solutions.
> 
> /a
>

---

From: Joe Abley <[email-masked]>
Date: Thu, 15 Aug 2019 13:06:36 -0400

> Is the primary purpose of intermingling DoH with 443 traffic to prevent blocking DNS resolution?

I don't know what Adam's response to that is, but I don't think it's reasonable to get frustrated when asking questions that have many possible answers. (One person's "primary purpose" is another person's "ancillary benefit" is another person's "mild annoyance" is another person's "nightmare scenario".)

For what it's worth, I think that hiding DNS resolution is a perfectly reasonable primary purpose for end-users who find themselves in situations where they desire privacy from a third party.

I think it's simultaneously a terrible idea for third parties who want to block things they can't observe, measure or modify.

I'm not sure why the question is important, since I think it has been answered eleventy billion times already on this list.

Incidentally, I don't think "on the browser side" is a useful phrase, since it suggests that there are entrenched armies here all battling over the same strip of land. Different people here have different answers to the same questions. The answers are not compatible. It's ok for everybody to be right.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Aug 2019 13:38:32 -0400 (EDT)

> One variant to consider would be sending a DoT-like DNS query with only the query NAME encrypted or hashes (ie completely different from DoT or DoH where the entire DNS message is encrypted) and to…

Seeing answers leads to deducation the question. It is not privacy
preserving at all. So then you are basically just faciliating censorship
against the user's wishes.

Paul

---

From: Bret Jordan <[email-masked]>
Date: Thu, 15 Aug 2019 11:43:55 -0600

Personally I think a lot more research needs to be done so that we can make statements using data.  Further, we need to identify all of the use cases we know that need to be represented in the research to make sure it is not one-sided. 

Thanks,
Bret

> On Aug 15, 2019, at 8:11 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Aug 15, 2019 at 4:08 PM Neil Cook <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 15 Aug 2019, at 14:49, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
> As I said, I'm certainly interested in any data that someone would like to share.
> 
> -Ekr
> 
> 
> 
> Neil Cook
> [email-masked] <mailto:[email-masked]>
>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 13:52:24 -0400

Sent from my iPhone

> On Aug 15, 2019, at 1:38 PM, Paul Wouters <[email-masked]> wrote:
> 

Okay, so what if the only “signal” was client IP and destination IP on DoT packets?

You might not think there is value in that, but would that be a privacy issue per se?

The intent would be to identifying hosts that are possibly compromised, and using a known-bad resolver (for whatever is locally defined as “bad”).

Brian

---

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

> If ALL browser DNS traffic was sent over BOTH DoH and DoT in parallel (both encrypted, sent to the same resolver), do you agree that the privacy would be the same (same encryption) and the unblocka…

Why is this an important question?

---

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

Sent from my iPhone

> On Aug 15, 2019, at 1:54 PM, Ted Lemon <[email-masked]> wrote:
> 

If implemented universally by browsers (and other ADD apps), it would provide a missing signal about those apps. Specifically, it would be a somewhat weak signal that an app is legitimate (not rogue) and that it has not had its choice of resolver changed to something unusual or noteworthy.

The example use case for DoT is the same, except that DoT would also enable blocking specific DNS resolver choices. The options available (to a network or security admin) would be greatly reduced, since it would not be possible to block DNS exclusively. It would enable detection of suspicious activity, including identification of the host, which presumably could be quarantined.

IMHO it doesn’t directly impact privacy, but would enable a limited degree of network admin control. Eg as long as a single public DoH resolver was not blocked, the client could have privacy for DNS. It’s s not perfect by any means, but might be a reasonable starting point for exploring compromises between network security and user privacy.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 20:19:56 +0200

On Thu, Aug 15, 2019 at 6:52 PM Brian Dickson <[email-masked]>
wrote:

> If ALL browser DNS traffic was sent over BOTH DoH and DoT in parallel
> (both encrypted, sent to the same resolver), do you agree that the privacy
> would be the same (same encryption) and the unblockability would be
> unchanged?
>
> The reason for doing this would be to allow the choice of resolver (per
> client/app) to be discoverable. This is one significant gap in the DoH-only
> model. It would not require that the browser (or any other app) wait for
> both answers, so would at worst have no affect on performance, and at best
> would improve performance.
>

I don't understand what this is intended to accomplish.  In a later
message, you argue that this would allow a network monitor to determine
that this is a legitimate app that isn't using an undesirable DoH resolver,
but I don't understand why you think that's true. It's true that the
monitor can see that there are two connections to resolver X (DoH and DoT)
but that doesn't mean that the app is using those for its resolution; it
may be making a third connection to bad resolver Y and using the results
from that.

> One variant to consider would be sending a DoT-like DNS query with only
> the query NAME encrypted or hashes (ie completely different from DoT or DoH
> where the entire DNS message is encrypted) and to return A and AAAA RDATA
> and QID and port number unencrypted (but encrypt all other fields and all
> other RDATA responses). This would allow IDS/firewall systems to control
> access on the basis of DNS answers, without needing to know the question.
>

If all the IDS gets to see is the IP, why don't they just block on the IP
directly.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 11:29:14 -0700

> If implemented universally by browsers (and other ADD apps), it would provide a missing signal about those apps. Specifically, it would be a somewhat weak signal that an app is legitimate (not rogu…

Why not just have the app send an EDNS0 message to the resolver announcing that it is doing DoH, if your goal is simply for it to reveal that it is doing DoH?

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 15 Aug 2019 18:39:37 +0000

ekr> If all the IDS gets to see is the IP, why don't they just block on the IP directly.

Agreed. It doesn't matter how the client acquired an IP address (DNS, user typing, etc.) if the network knows the IP is bad already.

In general, I think any approach to appeasing user privacy and network security that begins with deciding which parts of traffic to leave unencrypted is heading in the wrong direction. The major point of encrypting traffic is to prevent third party boxes from seeing/tampering with the data, and there's no way to differentiate third parties with good and ill intent. Focusing on how the decision in resolvers gets made in the first place seems to provide more value, as the traffic can be manipulated in the Good Ways(tm) by the resolver trusted to do so, and not by anyone else along the path. Enabling Good Ways(tm) tampering by anyone other than the RR the stub is trying to reach just puts us back in square one (classic DNS).

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Thursday, August 15, 2019 11:19 AM
To: Brian Dickson <[email-masked]>
Cc: Paul Hoffman <[email-masked]>; ADD Mailing list <[email-masked]>; Adam Roach <[email-masked]>
Subject: Re: [Add] [Ext] Validity of network administrator role

On Thu, Aug 15, 2019 at 6:52 PM Brian Dickson <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone
> On Aug 15, 2019, at 1:28 AM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

I don't understand what this is intended to accomplish.  In a later message, you argue that this would allow a network monitor to determine that this is a legitimate app that isn't using an undesirable DoH resolver, but I don't understand why you think that's true. It's true that the monitor can see that there are two connections to resolver X (DoH and DoT) but that doesn't mean that the app is using those for its resolution; it may be making a third connection to bad resolver Y and using the results from that.

If all the IDS gets to see is the IP, why don't they just block on the IP directly.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 14:41:02 -0400

Sent from my iPhone

> On Aug 15, 2019, at 2:19 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Thu, Aug 15, 2019 at 6:52 PM Brian Dickson <[email-masked]> wrote:
>> 
>> 
>> Sent from my iPhone

The IDS and/or threat service needs to detect such an IP before it can be blocked.

The first clue new malware may provide is changing DNS so as to avoid IDS detection via DNS.

The same approach could also be used by a malicious human, eg doing data exfiltration.

My understanding is that detection is significantly hampered without any DNS information. This is better than nothing even if it is far from ideal. 

And in the case of a configured enterprise DoH server on a company owned device, where DNS resolution is monitored, changing resolver would be necessary to evade detection.

Again, not entirely foolproof, but certainly raises the bar, IMHO.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 14:44:33 -0400

Sent from my iPhone

> I don't understand what this is intended to accomplish.  In a later message, you argue that this would allow a network monitor to determine that this is a legitimate app that isn't using an undesir…

That’s why I suggested a variation where answer A or AAAA data would be exposed.
Any new connection not correlated to a recent A/AAAA response could be flagged or blocked. Not perfect, but another tool for the defense against apps behaving badly.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 20:47:20 +0200

On Thu, Aug 15, 2019 at 8:41 PM Brian Dickson <[email-masked]>
wrote:

> My understanding is that detection is significantly hampered without any
> DNS information. This is better than nothing even if it is far from ideal.
>
> And in the case of a configured enterprise DoH server on a company owned
> device, where DNS resolution is monitored, changing resolver would be
> necessary to evade detection.
>

I'm really not following your reasoning here. As I said, the application is
perfectly free to just use a totally separate channel and get IP addresses
that don't get advertised this way.

What would be helpful here would be if you described what it is that (a)
you cannot do with DoH and (b) you can do if applications do as you suggest.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 20:54:06 +0200

On Thu, Aug 15, 2019 at 8:44 PM Brian Dickson <[email-masked]>
wrote:

> Any new connection not correlated to a recent A/AAAA response could be
> flagged or blocked. Not perfect, but another tool for the defense against
> apps behaving badly.
>

This doesn't seem like an awesome practice because it breaks any app which
gets IP addresses via non-DNS mechanisms (e.g., WebRTC).

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 14:56:58 -0400

Sent from my iPhone

> On Aug 15, 2019, at 2:39 PM, Tommy Jensen <[email-masked]> wrote:
> 
> In general, I think any approach to appeasing user privacy and network security that begins with deciding which parts of traffic to leave unencrypted is heading in the wrong direction. The major point of encrypting traffic is to prevent third party boxes from seeing/tampering with the data,

Here’s what I’d like to emphasize:

Encrypted data is protected from on-path viewing, and I believe is the only mechanism available for that purpose.

However, there are two mechanisms available for prevention of tampering. One is encryption, the other is use of cryptographic signatures (eg DNSSEC, but possibly also via signing by the resolver, ie DoH server).

Exposing some portion of the responses while protecting them via signatures, is one way of preventing tampering (or at least providing tamper evidence.)

Brian

> and there's no way to differentiate third parties with good and ill intent. Focusing on how the decision in resolvers gets made in the first place seems to provide more value, as the traffic can be manipulated in the Good Ways(tm) by the resolver trusted to do so, and not by anyone else along the path.

This, I agree with. The main challenge is in the ways of ensuring the correct resolver is being used. That is the rationale for the DoT+DoH idea. I’d certainly welcome any other ideas for how that could be done.

Brian

> Enabling Good Ways(tm) tampering by anyone other than the RR the stub is trying to reach just puts us back in square one (classic DNS).
> 
> Thanks,
> Tommy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 12:03:16 -0700

> However, there are two mechanisms available for prevention of tampering. One is encryption, the other is use of cryptographic signatures (eg DNSSEC, but possibly also via signing by the resolver, i…

Blocking is a form of tampering.   One purpose of DoH is to make blocking impractical, so that the end user isn’t forced to choose a path that’s subject to tampering and intercept.

The resolver can’t attest to the validity of records for domains for which it is not authoritative, and there is no mechanism for associating a DoH resolver with an authoritative domain other than DNSSEC (nor would it be useful to define one, since DNSSEC does this quite handily).  So in practice DNSSEC is the only mechanism that prevents tampering of the sort you are describing.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 15:13:57 -0400

Sent from my iPhone

> On Aug 15, 2019, at 2:47 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Thu, Aug 15, 2019 at 8:41 PM Brian Dickson <[email-masked]> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
> I'm really not following your reasoning here. As I said, the application is perfectly free to just use a totally separate channel and get IP addresses that don't get advertised this way.
> 
> What would be helpful here would be if you described what it is that (a) you cannot do with DoH and (b) you can do if applications do as you suggest.
> 
> -Ekr

The obvious use case is the second one: a malicious user, using an unmodified app (eg browser) configured to use a monitored DoH resolver (eg enterprise resolver).

If the user changes the resolver, in the DoH-only case, the monitored resolver stops seeing queries. The malicious user accesses some site somewhere (which involves first doing the DNS query via the newly configured resolver) and exfiltrates data, then changes the configuration back. A brief period of no queries would not likely be suspicious. Queries to new resolvers would be completely unambiguous in that regard.

If the application (browser) does what I suggest, the IDS at a minimum would be able to detect the use of the rogue resolver, and potentially could disconnect the malicious user’s device from the network (preventing the exfiltration).

If the enterprise resolver also was blocking the site the user intended to use (via DNS), the only other way the user could access it would be via some kind of hard-coding. A robust anti-exfiltration solution could further restrict site access by requiring DNS-before-access.

Security is an arms race; this isn’t necessarily foolproof or comprehensive, but it doesn’t need to be, to be useful.

Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 21:14:38 +0200 (CEST)

On Thu, 15 Aug 2019, Ted Lemon wrote:

> Blocking is a form of tampering.  One purpose of DoH is to make blocking 
> impractical, so that the end user isn’t forced to choose a path that’s 
> subject to tampering and intercept.

As with any technology this is dual use. If the customer has purchased a 
solution that's built around certain mechanisms, bypassing these 
mechanisms might be against the users' wishes.

There is no correct answer here, and anyone pretending to know the correct 
answer for all situations is wrong.

So let's fall back on the "principle of least astonishment". If you tell 
the users "your browser is now doing DNS lookups using a cloud provider 
and your ISP is no longer in that loop", what do you think their response 
will be? (might need explanation to the user, but still)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 21:25:40 +0200

On Thu, Aug 15, 2019 at 9:14 PM Mikael Abrahamsson <[email-masked]> wrote:

> will be?

I think their response will be "What's DNS"?

(might need explanation to the user, but still)

I suppose it depends on whether that explanation includes describing the
various forms of misbehavior that network operators have been known to
engage in?

-Ekr

> --
> Mikael Abrahamsson    email: [email-masked]
> Add mailing list
> [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 21:26:21 +0200

On Thu, Aug 15, 2019 at 9:14 PM Brian Dickson <[email-masked]>
wrote:

> I'm really not following your reasoning here. As I said, the application
> is perfectly free to just use a totally separate channel and get IP
> addresses that don't get advertised this way.
>
> The obvious use case is the second one: a malicious user, using an
> unmodified app (eg browser) configured to use a monitored DoH resolver (eg
> enterprise resolver).
>
> If the user changes the resolver, in the DoH-only case, the monitored
> resolver stops seeing queries. The malicious user accesses some site
> somewhere (which involves first doing the DNS query via the newly
> configured resolver) and exfiltrates data, then changes the configuration
> back. A brief period of no queries would not likely be suspicious. Queries
> to new resolvers would be completely unambiguous in that regard.
>
> If the application (browser) does what I suggest, the IDS at a minimum
> would be able to detect the use of the rogue resolver, and potentially
> could disconnect the malicious user’s device from the network (preventing
> the exfiltration).
>
> If the enterprise resolver also was blocking the site the user intended to
> use (via DNS), the only other way the user could access it would be via
> some kind of hard-coding. A robust anti-exfiltration solution could further
> restrict site access by requiring DNS-before-access.
>

This all seems pretty trivial to bypass. Even if we assume that resolution
is completely under control of an enterprise resolver, it's trivial for the
attacker to set up a server co-located with some set of innocuous domains
(e.g., on GCP/AWS, etc.). The application then does resolution for one of
those innocuous domains, gets back the IP address, then connects to it and
instead requests its own domain (this is effectively domain fronting).

Security is an arms race; this isn’t necessarily foolproof or
> comprehensive, but it doesn’t need to be, to be useful.
>

It's true that things need not be foolproof to be useful, but declining to
deploy a mechanism (DoH) that has substantial security value in order to
preserve a mechanism that is easily bypassed doesn't seem like a good
tradeoff.

-Ekr

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 21:28:55 +0200 (CEST)

> various forms of misbehavior that network operators have been known to 

I guess we can agree that the answer is "it depends". There is no "one 
correct answer".

Therefore the whole discussion on "one default that fits all" is just the 
wrong answer. There is no default that suits all.

Can we at least agree on this?

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 15:29:14 -0400

Sent from my iPhone

> On Aug 15, 2019, at 3:03 PM, Ted Lemon <[email-masked]> wrote:
> 

Or, it can wait for the DoH response and use that. The incremental change is adding the DoT query, and the app can ignore that response. It still provides signal to the network (eg IDS).

Blocking is still impossible since DoH is still used.

Brian

PS I’m still advocating for client DNSSEC validation, of course, regardless of DoH/DoT.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Aug 2019 21:32:39 +0200

> Can we at least agree on this?

Yes, but that also applies to the current default. The question is what
would be a better default for more people.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 12:43:34 -0700

> Blocking is still impossible since DoH is still used.

Sure, except that if this were the default behavior of devices that use DoH, it would be trivial to block outgoing HTTPS connections for devices that do this.   And then the user would disable it, the device would go back to using the local resolver, and all would be well (for the network operator, not necessarily the user).  Or the user would disable DoT replication, and continue doing DoH.

Also, you’ve added complexity, and probably latency.   And honestly, why the heck would I implement that?   If you tell me I have to do X to make things work, and I should do Y, but it will make no difference to my user if I do Y or not, then why would I spend additional geek-hours building and testing Y?   There is no scenario I can imagine, that did not involve jack-booted thugs standing over me, where I would implement this, even if I agreed in principle that it was a good idea.  It’s a really basic principle of getting stuff done: you write the code you need to write, and no other code.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 15 Aug 2019 21:08:34 +0000

brian> However, there are two mechanisms available for prevention of tampering. One is encryption, the other is use of cryptographic signatures (eg DNSSEC, but possibly also via signing by the resolver, ie DoH server).
brian>
brian> Exposing some portion of the responses while protecting them via signatures, is one way of preventing tampering (or at least providing tamper evidence.)

I agree that DNSSEC provides evidence of tampering, but I think that is less valuable than what encryption brings (lack of visibility as well as tamper protection).

brian> This, I agree with. The main challenge is in the ways of ensuring the correct resolver is being used. That is the rationale for the DoT+DoH idea. I’d certainly welcome any other ideas for how that could be done.

After seeing the discussions on this mailing list, I think our best collective chance at determing the "correct" resolver is to work in the platform context where the correctness of a DNS server has previously been expressed. For example, the platform has configuration for deciding whether to trust the network recommendation or to use a manually provided server set, what suffixes to use with single label names, what exceptions to use for specific domain spaces as dictated by VPN or proxy configurations, and so forth. As has been pointed out, platform configurations have different sources and having a conversation about how to compare those sources would be my next step forward.

To that end, I am working with some folks offline to see if we can build a proposal for platform exposure of DNS intent to apps that could provide the correctness guide we're all looking for. That way, apps would have a cross-platform way of communicating with the platform about what the user authorities over the device have previously configured, and networks would know what contract they need to meet to prove correctness to the platform. Let me know if you're interested in such a conversation. It's far from perfect, but it would be a distinct improvement over any of these imo:

  *   "always trust network recommendation no matter what network"
  *   "always trust the app, no matter what platform configuration exists"
  *   "always ask the user, no matter how much or little they know" (or how much or little administrative control they have over the device or network, since user at keyboard != user with administrative privilege in many cases)

Thanks,
Tommy

________________________________
From: Brian Dickson <[email-masked]>
Sent: Thursday, August 15, 2019 11:56 AM
To: Tommy Jensen <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; Paul Hoffman <[email-masked]>; ADD Mailing list <[email-masked]>; Adam Roach <[email-masked]>
Subject: Re: [Add] [Ext] Validity of network administrator role

Sent from my iPhone

On Aug 15, 2019, at 2:39 PM, Tommy Jensen <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Brian

Thanks,
Tommy
________________________________
From: Add <[email-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 15, 2019 11:19 AM
To: Brian Dickson <[email-masked]<mailto:[email-masked]>>
Cc: Paul Hoffman <[email-masked]<mailto:[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>; Adam Roach <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] [Ext] Validity of network administrator role

Sent from my iPhone

-Ekr

---

From: Bret Jordan <[email-masked]>
Date: Thu, 15 Aug 2019 15:58:45 -0600

It would depend on how you phrase the question..  If you say this is going to prevent anyone from seeing your DNS traffic, you will probably get one response.  If you say, all of your data is going to central source where it can be correlated and harvested, you might get a different answer.  If you say that the parental controls you have signed up for and paid money for are no longer going to work, you might get a different answer. If you say that the malicious activity and prevention tools you use are no longer going to work, you might get a different answer.  

We need to quit thinking that solving a use case for someone at a coffee shop is somehow good for everyone.  Because this is just wrong. 

It just baffles me silly that we are worried about people seeing DNS traffic and we are not worried about certain cloud providers harvesting, mining, and tracking all users behavior on the internet and all of their interactions (email and such) that they do with the cloud providers. It seems like if we _REALLY_ wanted to improve privacy and security we would do something about that.  Maybe create an encrypted email system that was done in the browser and protected all email from being reviewed and monitored.  Further, it would be nice if browsers did a better job of preventing and denying all tracking tools. 

Thanks,
Bret

> On Aug 15, 2019, at 1:14 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> As with any technology this is dual use. If the customer has purchased a solution that's built around certain mechanisms, bypassing these mechanisms might be against the users' wishes.
> 
> There is no correct answer here, and anyone pretending to know the correct answer for all situations is wrong.
> 
> So let's fall back on the "principle of least astonishment". If you tell the users "your browser is now doing DNS lookups using a cloud provider and your ISP is no longer in that loop", what do you think their response will be? (might need explanation to the user, but still)
> 
> --

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 00:43:39 +0200

n Thu, Aug 15, 2019 at 11:59 PM Bret Jordan <[email-masked]> wrote:

>
> It just baffles me silly that we are worried about people seeing DNS
> traffic and we are not worried about certain cloud providers harvesting,
> mining, and tracking all users behavior on the internet and all of their
> interactions (email and such) that they do with the cloud providers. It
> seems like if we _REALLY_ wanted to improve privacy and security we would
> do something about that.
>

Who says we're not worried about it? Do you have a concrete plan for
addressing it?

 Maybe create an encrypted email system that was done in the browser and
> protected all email from being reviewed and monitored.
>

Here too, it seems like the question isn't one of desirability but
practicality. There have been quite a few attempts at E2E encrypted email,
none very successful. Just wishing does not make it so.

 Further, it would be nice if browsers did a better job of preventing and
> denying all tracking tools.
>

You mean like:
https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/ or
https://blog.mozilla.org/blog/2019/06/04/firefox-now-available-with-enhanced-tracking-protection-by-default/
?

-Ekr

> solution that's built around certain mechanisms, bypassing these mechanisms
> might be against the users' wishes.
>
> the users "your browser is now doing DNS lookups using a cloud provider and
> your ISP is no longer in that loop", what do you think their response will
> be? (might need explanation to the user, but still)
>
> --
> Mikael Abrahamsson    email: [email-masked] <[email-masked]>--
> Add mailing list
> [email-masked]

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 15 Aug 2019 19:17:43 -0400

Tommy Jensen writes:
> I agree that DNSSEC provides evidence of tampering, but I think that
> is less valuable than what encryption brings (lack of visibility as
> well as tamper protection).

I've seen this come up a couple of times now in ways that seem to
imply an equivalence here regarding tamper protection, with at least
one time (not on this list) where there was a clear belief that having
DoH obviated DNSSEC.

To be clear for the discussion, while it is true that DoH protects
tampering between the endpoints of a particular DNS transaction
(currently expected to usually be a resolver and a client) it does
absolutely nothing to address the authenticity of a response. That
could still well have been tampered with at many other points in the
resolution chain.  DNSSEC is currently the only mechanism we have for
automatically detecting that.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 15 Aug 2019 23:21:14 +0000

ekr> Who says we're not worried about it? Do you have a concrete plan for addressing it?

I'd suggest having a list of TRRs with the default value being selected randomly per client rather than just one TRR distributed to a large geographic population such as North America. For example, in my Firefox install (Firefox Quantum, 68.0.2) under "Enable DNS over HTTPS" I only see "CloudFlare (Default)" and "Custom" as options.

If there were many TRRs listed, and which one labeled as default randomly chosen at first launch, then at least there would be some distribution of DNS traffic for users who will never check that setting (i.e. most users), and the same configuration freedom for those those users who will check it. Another option might be testing several TRRs from the list at first launch and picking the fastest to respond to attempt some sorting by geographic efficiency.

Perhaps operators of public DNS servers on this mailing list would be interested in knowing what bar they would have to clear to get on such a list. Would it be identical to the existing published terms between Mozilla and CloudFlare? Something else? Would you be willing to collaborate on such terms with other browsers for a common standard for TRRs?

Even in my ideal world where the browser cooperates with the platform on deciding when to use which DNS stub, there will be times when the browser will know more about the user's DNS intentions than the platform, and in those cases there should definitely be a larger variety of TRRs available to any given large-scale population.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Thursday, August 15, 2019 3:43 PM
To: Bret Jordan <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Ted Lemon <[email-masked]>; Mikael Abrahamsson <[email-masked]>
Subject: Re: [Add] [Ext] Validity of network administrator role

n Thu, Aug 15, 2019 at 11:59 PM Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:

It just baffles me silly that we are worried about people seeing DNS traffic and we are not worried about certain cloud providers harvesting, mining, and tracking all users behavior on the internet and all of their interactions (email and such) that they do with the cloud providers. It seems like if we _REALLY_ wanted to improve privacy and security we would do something about that.

Who says we're not worried about it? Do you have a concrete plan for addressing it?

 Maybe create an encrypted email system that was done in the browser and protected all email from being reviewed and monitored.

Here too, it seems like the question isn't one of desirability but practicality. There have been quite a few attempts at E2E encrypted email, none very successful. Just wishing does not make it so.

 Further, it would be nice if browsers did a better job of preventing and denying all tracking tools.

You mean like: https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebkit.org%2Fblog%2F8828%2Fintelligent-tracking-prevention-2-2%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C1aaa93ba8c1e494f7e1f08d721d22216%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015058741102529&sdata=F5nFL65HCw4sBxW73KiTRiw1NnuFhH6k2c%2BRRvV%2Bj%2FM%3D&reserved=0> or https://blog.mozilla.org/blog/2019/06/04/firefox-now-available-with-enhanced-tracking-protection-by-default/<https://blog.mozilla..org/blog/2019/06/04/firefox-now-available-with-enhanced-tracking-protection-by-default/>?

-Ekr

Thanks,
Bret

On Aug 15, 2019, at 1:14 PM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C1aaa93ba8c1e494f7e1f08d721d22216%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015058741112525&sdata=V7%2FoY%2FelBrY7keJXkFcHGiSvCrnSxO%2F2Von0oPFV9qI%3D&reserved=0>

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C1aaa93ba8c1e494f7e1f08d721d22216%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015058741122521&sdata=gt3tp99cgp58XlH35HDWmWMDXlvBGpStMIeW1Wfh%2BdU%3D&reserved=0>

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Aug 2019 18:23:19 -0500

On 8/15/19 6:21 PM, Tommy Jensen wrote:
> Perhaps operators of public DNS servers on this mailing list would be 
> interested in knowing what bar they would have to clear to get on such 
> a list.

This has been asked and answered quite a few times already.

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

/a

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 15 Aug 2019 19:24:16 -0400

On Thu, Aug 15, 2019 at 19:21 Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> I'd suggest having a list of TRRs with the default value being selected
> randomly per client rather than just one TRR distributed to a large
> geographic population such as North America. For example, in my Firefox
> install (Firefox Quantum, 68.0.2) under "Enable DNS over HTTPS" I only see
> "CloudFlare (Default)" and "Custom" as options.
>
> If there were many TRRs listed, and which one labeled as default randomly
> chosen at first launch, then at least there would be some distribution of
> DNS traffic for users who will never check that setting (i.e. most users),
> and the same configuration freedom for those those users who will check it.
> Another option might be testing several TRRs from the list at first launch
> and picking the fastest to respond to attempt some sorting by geographic
> efficiency.
>
> interested in knowing what bar they would have to clear to get on such a
> list. Would it be identical to the existing published terms between Mozilla
> and CloudFlare? Something else? Would you be willing to collaborate on such
> terms with other browsers for a common standard for TRRs?
>

https://blog.mozilla.org/security/2019/04/09/dns-over-https-policy-requirements-for-resolvers/

> Even in my ideal world where the browser cooperates with the platform on
> deciding when to use which DNS stub, there will be times when the browser
> will know more about the user's DNS intentions than the platform, and in
> those cases there should definitely be a larger variety of TRRs available
> to any given large-scale population.
>
> Thanks,
> Tommy
> ------------------------------
> *From:* Add <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> *Sent:* Thursday, August 15, 2019 3:43 PM
> *To:* Bret Jordan <[email-masked]>
> *Cc:* ADD Mailing list <[email-masked]>; Ted Lemon <[email-masked]>;
> Mikael Abrahamsson <[email-masked]>
> *Subject:* Re: [Add] [Ext] Validity of network administrator role
>
> https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebkit.org%2Fblog%2F8828%2Fintelligent-tracking-prevention-2-2%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C1aaa93ba8c1e494f7e1f08d721d22216%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015058741102529&sdata=F5nFL65HCw4sBxW73KiTRiw1NnuFhH6k2c%2BRRvV%2Bj%2FM%3D&reserved=0>
> or
> <https://blog.mozilla..org/blog/2019/06/04/firefox-now-available-with-enhanced-tracking-protection-by-default/>
> ?
>
> -Ekr
>
>
>
> Thanks,
> Bret
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C1aaa93ba8c1e494f7e1f08d721d22216%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015058741112525&sdata=V7%2FoY%2FelBrY7keJXkFcHGiSvCrnSxO%2F2Von0oPFV9qI%3D&reserved=0>
>
>
> --
> Add mailing list
> [email-masked]
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C1aaa93ba8c1e494f7e1f08d721d22216%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015058741122521&sdata=gt3tp99cgp58XlH35HDWmWMDXlvBGpStMIeW1Wfh%2BdU%3D&reserved=0>
>
> --
> Add mailing list
> [email-masked]
-- 
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: Tommy Jensen <[email-masked]>
Date: Thu, 15 Aug 2019 23:24:29 +0000

Thanks for calling this nuance out explicitly. My intent here was not to say DNSSEC can be replaced by DoH (it can't), but rather to say that use of DNSSEC and unencrypted (or partially unencrypted) query responses is a step backward from fully encrypted queries, that's all.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Dave Lawrence <[email-masked]>
Sent: Thursday, August 15, 2019 4:17 PM
To: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [Ext] Validity of network administrator role

--
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%7C2f700228b18d49b6d62908d721d6cccb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015078799476204&amp;sdata=D5Yy23jX4Wi%2Fc%2BRMX%2BtPIMT%2F9RK1soJQsaCtoIdyqPQ%3D&amp;reserved=0

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 15 Aug 2019 23:27:58 +0000

Perfect, thanks for the link. So that simplifies my answer to: get more TRRs, and distribute their default assignments so as to minimize the number of users centralizing on one of them by default.

Are there other (publicly known/disclosed) DNS servers applying to this status? I know Mozilla has said they're exploring European options, but even 1-2 TRRs per continent is incredibly centralized.

Thanks,
Tommy
________________________________
From: Adam Roach <[email-masked]>
Sent: Thursday, August 15, 2019 4:23 PM
To: Tommy Jensen <[email-masked]>; Eric Rescorla <[email-masked]>; Bret Jordan <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Ted Lemon <[email-masked]>; Mikael Abrahamsson <[email-masked]>
Subject: Re: [Add] [Ext] Validity of network administrator role

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mozilla.org%2FSecurity%2FDOH-resolver-policy&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C67fa14fff3da47721f7008d721d79504%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015082121818180&amp;sdata=gy0w1nYjWfjIHK3ZszFTHu1ZYSdAsSFSpWycYrymkbY%3D&amp;reserved=0

/a

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 15 Aug 2019 19:29:30 -0400

Bret Jordan writes:
> traffic and we are not worried about certain cloud providers
> harvesting, mining, and tracking all users behavior on the internet
> and all of their interactions (email and such) that they do with the
> cloud providers. 

"and we are not worried about ..." seems to have missed a huge amount
of conversation that has in fact swirled around that very topic.

One distinction worth observing again is that the experimental
Mozilla/CloudFlare DoH setup was only one possible operational model.
We can address the issues of that model while also discussing
the issues of alternative models, evaluating then against each other
to try to get as many of the benefits as possible while bearing as few
of the disadvantages as necessary.

This is why discovery mechanisms are an interesting area of work for
the IETF.  It would be an enabler for putting more control back in the
hands of network administrators, at least to the point that major,
well-behaved applications end up using those channels.  (Yes,
obviously badly-behaved applications will circumvent the
configuration, but as has been observed many times that was an issue
before DoH ever came along.)

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Aug 2019 19:30:32 -0400

> On Aug 15, 2019, at 19:23, Adam Roach <[email-masked]> wrote:
> 
> 
> 

“at Mozilla’s sole discretion”

It’s always hard not try to gain power to do good, instead of not giving yourself the power for potential abuse or compulsion in the future.

I’m also a bit confused that there are no other requirements like bandwidth, stability, ownership of IP space or other requirements for stability and security.

The lack of requiring dnssec has already been mentioned in the past as a fundamental problem.

Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Aug 2019 18:34:32 -0500

> It’s always hard not try to gain power to do good, instead of not giving yourself the power for potential abuse or compulsion in the future.

Given Mozilla's nonprofit status, and given the precepts of its mission, 
that's a kind of non-sequitur thing to say.

/a

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Aug 2019 19:41:37 -0400

M

> On Aug 15, 2019, at 19:24, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> 

That statement is still incorrect. Unencrypted dnssec is more secure then encrypted dns without dnssec because dnssec answers cannot be spoofed.

Encrypted dns without dnssec is more private than unencrypted dnssec and the lack of privacy might cause a physical security issue for the user.

Paul

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 15 Aug 2019 23:51:03 +0000

paul> That statement is still incorrect. Unencrypted dnssec is more secure then encrypted dns without dnssec because dnssec answers cannot be spoofed.

I was very careful not to say it was more secure. What I said was partially encrypting the payload and adding DNSSEC would be "a step backward" imo considering integrity overall (authentication which only DNSSEC can provide as well as visibility protection which only encryption can provide as well as tamper protection *BETWEEN THE RR AND THE STUB* which either can provide in different ways). After all, one can simply add DNSSEC to a fully encrypted DNS pipeline and get the best of both worlds, so I wasn't seeing the merit in a partially encrypted solution. That's all.
________________________________
From: Paul Wouters <[email-masked]>
Sent: Thursday, August 15, 2019 4:41 PM
To: Tommy Jensen <[email-masked]>
Cc: Dave Lawrence <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [Ext] Validity of network administrator role

M

On Aug 15, 2019, at 19:24, Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:Jensen.Thomas=[email-masked]>> wrote:

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Aug 2019 01:40:11 +0100

Hiya,

> of the disadvantages as necessary.

I'm also personally leery of the moz/cf model as being
a possible one-off. The "we'd like more TRRs" aspiration
seems like a good, and genuine, one, but hasn't so far
produced other TRRs AFAIK. Continued work on that seems
like a good thing.

However, I've not seen other (!= moz/TRR) models proposed.

If someone has one to propose, now and here would seem
like a good time and place. By a "proposed model" I mean
a worked-out model and not a "not yet even on a beer-mat"
nor just a "sent from my iphone" type random thought;-)

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 15 Aug 2019 22:35:59 -0700

> automatically detecting that.

Isn't the relationship a bit more subtle? In researching this issue, I came
across this forum post (please excuse the slightly inflammatory title of
the thread): <https://news.ycombinator.com/item?id=7450281>.

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

These attacks do in fact happen (see <
https://mailarchive.ietf.org/arch/msg/add/NIk8gIPZu52GXDsT8zy4S1I4QsM>), so
it seems like DoT/DoH would be one step in improving DNSSEC reliability.

thanks,
Rob

---

From: Frode Kileng <[email-masked]>
Date: Fri, 16 Aug 2019 08:56:21 +0200

On 15/08/2019 23:58, Bret Jordan wrote:
<snip>
> If you say that the parental controls you have signed up for and paid 
> money for are no longer going to work, you might get a different answer. 

There are numerous other client-side child-safe products in the markets 
that will continue to work perfectly well. Please please stop using this 
"save the children" argument that has been fronted by the 
"anti-encryption camp" for the last 5 years.

frodek

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 16 Aug 2019 09:01:35 +0200

Moin!

> concern at all, or that public resolvers (like OpenDNS and Google 
Well the ideal scenario would be that the end client like the browser 
would
validate DNSSEC. However Browser vendors don’t seem to have interest 
in that.
See the thread on “Mozilla's DoH resolver policy” from April on this 
mailing
list for that. DNSSEC provides end to end security if implemented 
properly.

> it seems like DoT/DoH would be one step in improving DNSSEC 
DoH certainly can help to protect the connection between the recursive
resolver and the the stub, as would DoT. However for authenticity that 
would
not be needed if the client performed DNSSEC validation.

So long
-Ralf
—-
Ralf Weber

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 09:47:32 +0000

On 16/08/2019 07:56, Frode Kileng <[email-masked]> wrote:

> There are numerous other client-side child-safe products in the markets that will 
> continue to work perfectly well. Please please stop using this "save the children" 
> argument that has been fronted by the "anti-encryption camp" for the last 5 years.

Whilst there may be alternative child-safe products, it should be remembered that at least some ISPs provide parental controls using DNS filtering (and malware protection) as part of their service bundle, making it relatively simple for their customers to configure and use the services.  These are generally provided at no additional cost and, in some instances, are enabled by default.  Having a protocol like DoH bypass such services without due warning to those users is a problem.  Having to share data with an alternate app provider to rectify the situation may also be a problem to some of those users, particularly if that provider is based off-shore from the user.  

NB This has nothing to do with anti-encryption, is about understanding the behaviours and expectations of regular users (and regulators and politicians for that matter, although these are separate considerations).

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 12:19:25 +0200

> "CloudFlare (Default)" and "Custom" as options.

This is something we have looked at and my do, but given that there are
likely to be only about 3-4 resolvers capable of serving as the default for
a system as large as Firefox, this doesn't seem like it will improve
privacy that much.

-Ekr

---

From: Frode Kileng <[email-masked]>
Date: Fri, 16 Aug 2019 12:32:14 +0200

> Whilst there may be alternative child-safe products, it should be remembered that at least some ISPs provide parental controls using DNS filtering (and malware protection) as part of their service…

If the goal is "child safe" environment, the core issue must be the 
level of protection you provide for children not who provides, cost and 
"convenience". And those DNS-filtering solutions cannot compare to the 
client-side solution with regard to the level of protection due to their 
access to the un-encrypted content and that they protect the children on 
any network.

I strongly disagree that this "protect the children" is a valid argument.

> NB This has nothing to do with anti-encryption, is about understanding the behaviours and expectations of regular users (and regulators and politicians for that matter, although these are separate…

Sorry for not making this clearer. I intended only to  point out 
similarities between the this discussion and argumentation with the 
encryption/anti-encryption discussion. with many of the same arguments 
repeated from that time. Back then, network operators argued that 
encryption would have a disastrous effect on network management, 
undermining their role and also threatens the safety of children and 
others.

I strongly agree with Martin's suggestions to maybe take some lessons 
from that encryption discussion, i.e. to "produce a dispassionate 
assessment of each use case in turn, reaching agreement that the 
analysis was at least accurate, then deciding what was important enough 
to do something about" [1] . (I was not lucky enough to  experienced 
such a constructive effort within the communities I participated back 
then and feel still exhausted when thinking back...).

[1] https://mailarchive.ietf.org/arch/msg/add/You2UXZbjDogcASupgZTzjdYVMs

Best regards

Frode

---

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

On 16/08/2019 11:32, Frode Kileng <[email-masked]> wrote:
> If the goal is "child safe" environment, the core issue must be the level of protection you 
> provide for children not who provides, cost and "convenience". And those DNS-filtering 
> solutions cannot compare to the client-side solution with regard to the level of protection 
> due to their access to the un-encrypted content and that they protect the children on 
> any network.

I agree that there are trade-off here, with some solutions providing more comprehensive protection, albeit some of those are in turn significantly more intrusive to the client (child) which raises its own, separate issues - probably too far off-topic to pursue here.  

> I strongly disagree that this "protect the children" is a valid argument.

This will vary in different markets.  For example, in the UK there are new and specific requirements being introduced by one of the regulators (the Information Commissioner's Office) requiring tech companies to show how they are protecting the data of children that use their services.  In addition, a general duty of care is in the process of being introduced through legislation, currently targeted primarily at social media platform, to address a range of issues caused by online harms.  Yes this particular example is UK-specific but does require a range of companies to show that they are "protecting the children".  It would be helpful to understand if this is an isolated example or if there are other, similar initiatives elsewhere.  

> I strongly agree with Martin's suggestions to maybe take some lessons from that encryption 
> discussion, i.e. to "produce a dispassionate assessment of each use case in turn, reaching 
> agreement that the analysis was at least accurate, then deciding what was important enough 
> to do something about" [1] . 
> 

Here we can certainly agree.  😊

Andrew

---

From: Neil Cook <[email-masked]>
Date: Fri, 16 Aug 2019 12:00:48 +0100

> On 16 Aug 2019, at 11:32, Frode Kileng <[email-masked]> wrote:
> 
> If the goal is "child safe" environment, the core issue must be the level of protection you provide for children not who provides, cost and "convenience". And those DNS-filtering solutions cannot compare to the client-side solution with regard to the level of protection due to their access to the un-encrypted content and that they protect the children on any network.
> 

What people choose to use for parental control, internet filtering, malware protection etc. is up to them, as is their choice in terms of the level of protection it provides. You are not the arbiter of that. You are entitled to your opinion of course, but that’s all it is.  DNS filtering is a valid use-case whether or not it meets your personal definition of child safety (or malware protection or whatever).

Neil Cook

European Office: 

US Office:

---

From: Frode Kileng <[email-masked]>
Date: Fri, 16 Aug 2019 14:01:12 +0200

On 16/08/2019 13:00, Neil Cook wrote:
> What people choose to use for parental control, internet filtering, 
> malware protection etc. is up to them, as is their choice in terms of 
> the level of protection it provides. You are not the arbiter of that. 
> You are entitled to your opinion of course, but that’s all it is.  DNS 
> filtering is a valid use-case whether or not it meets your personal 
> definition of child safety (or malware protection or whatever).

So your use case is "Use DNS as filtering mechanism fo provide not 
child/malware protection", not "provide child/malware protection"? And 
if so I agree that DoH challenges your use-case.....

Best regards

Frode

---

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

Here is an alternate model.  Mozilla produces a hardened standalone DoH server that everyone can run off their home network and expose out to the internet via their DMZ zone. Then no more centralization. No more need to trust things outside.  Give people back control.  

Thanks,
Bret

> On Aug 15, 2019, at 6:40 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 10:30:48 -0600

Not every devices supports this.  Please stop using the “endpoints can do everything” argument that been fronted by the “there is nothing wrong camp” for the last 5 years. 

Thanks,
Bret

> On Aug 16, 2019, at 12:56 AM, Frode Kileng <[email-masked]> wrote:
> 
>> If you say that the parental controls you have signed up for and paid money for are no longer going to work, you might get a different answer. 
> 
> There are numerous other client-side child-safe products in the markets that will continue to work perfectly well. Please please stop using this "save the children" argument that has been fronted by the "anti-encryption camp" for the last 5 years.
> 
> frodek
> 
> 
> 
> 
> -- 
> Add mailing list
> [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 10:33:44 -0600

Yes, I agree.  It is about taking choice away.  We already know that the general market does not understand a lot of these things.  Taking things away from them, because you think it will be better for them, is just wrong.

Thanks,
Bret

> On Aug 16, 2019, at 3:47 AM, Andrew Campling <[email-masked]> wrote:
>

---

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

> Here is an alternate model.  Mozilla produces a hardened standalone DoH server that everyone can run off their home network and expose out to the internet via their DMZ zone. Then no more centraliz…

This is almost exactly equivalent to just using a DoH resolver provided by your ISP.   Which would certainly be a valid choice, if you consider your ISP more trustworthy than Google or Cloudflare.  If you are getting your child safety protection through DNS filtering from your ISP, this is probably a good choice.   I certainly don’t object to you doing this, and it may even be a better solution for some users than using Google (I really don’t know). 

But I don’t see this as Mozilla’s job to provide.  Mozilla’s job is to make sure that if you want to do this, it’s easy to do, and that if you are using some DoH resolver that’s not under your control, you don’t reveal PII when you query it.

Also, bear in mind that if you are connecting directly to your home to get this information, that reveals more about you to the local network than if you were connecting to your ISP or to Google or Cloudflare.   So it would probably be better for your security to connect directly to the ISP’s DoH resolver, and make sure that your DoH client doesn’t send PII while doing the query.

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 10:40:18 -0600

I agree.  People need to be able to make their own choice and someone should not be making it for them. Just because some do not like the solution or use-case does not mean it is not valid and does not meet the need.

Thanks,
Bret

> On Aug 16, 2019, at 5:00 AM, Neil Cook <neil.cook=[email-masked]> wrote:
> 
> 
> 
>> On 16 Aug 2019, at 11:32, Frode Kileng <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On 16/08/2019 07:56, Frode Kileng <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 16 Aug 2019 13:00:28 -0400

Ted Lemon writes:
> So it would probably be better for your security to connect directly
> to the ISP s DoH resolver, and make sure that your DoH client doesn't
> send PII while doing the query. 

FWIW some of the filtering products rely on PII for per-device
customization, so for example the kids' devices can be treated
different than the parents.

---

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

> different than the parents.

I’m aware of this.  However, it’s not a requirement that it be done this way.   It would be just as good for the device to just say what filter properties it wants.  This could still be used to fingerprint the device, but would not be PII per se.

---

From: Frode Kileng <[email-masked]>
Date: Fri, 16 Aug 2019 21:55:42 +0200

On 16/08/2019 18:30, Bret Jordan wrote:
> Not every devices supports this.  Please stop using the “endpoints can 
> do everything” argument that been fronted by the “there is nothing 
> wrong camp” for the last 5 years.

How can "your" ISP DNS-filtering solution protect my children when not 
connected that specific network? How can it protect if the end-point 
bypass the network specific DNS using DoT or some "hidden" mechanisms? 
How can a "FQDN matching rule" protect when the malware/"dangerous 
content" is distributed from a previously un-classified source or 
distributed from a source normally considered safe?

Wanting to add competitive advantages compared to other ISPs by offering 
a DNS-based filtering solution is a perfectly good business argument but 
I cannot understand the argument that this is the only or best solution 
for this specific use-case.

Frode

>> On Aug 16, 2019, at 12:56 AM, Frode Kileng <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> If you say that the parental controls you have signed up for and 
>>> paid money for are no longer going to work, you might get a 
>>> different answer.
>>
>> There are numerous other client-side child-safe products in the 
>> markets that will continue to work perfectly well. Please please stop 
>> using this "save the children" argument that has been fronted by the

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 16 Aug 2019 21:30:00 +0000

ekr> This is something we have looked at and my do, but given that there are likely to be only about 3-4 resolvers capable of serving as the default for a system as large as Firefox, this doesn't seem like it will improve privacy that much.

However, that is only a drawback if the random selection has equal weights for each server. By adding a growing right tail of smaller DNS servers which carry weights of, for example, ~0.1 or ~0.01 versus CloudFlare's 1.0 you could distribute default selection according to each provider's estimated volume handling. This would provide more decentralization than ~1-2 providers per continent at least.

Thanks,
Tommy
________________________________
From: Eric Rescorla <[email-masked]>
Sent: Friday, August 16, 2019 3:19 AM
To: Tommy Jensen <[email-masked]>
Cc: Bret Jordan <[email-masked]>; ADD Mailing list <[email-masked]>; Ted Lemon <[email-masked]>; Mikael Abrahamsson <[email-masked]>
Subject: Re: [Add] [Ext] Validity of network administrator role

On Fri, Aug 16, 2019 at 1:21 AM Tommy Jensen <[email-masked]<mailto:[email-masked]>> wrote:
ekr> Who says we're not worried about it? Do you have a concrete plan for addressing it?

This is something we have looked at and my do, but given that there are likely to be only about 3-4 resolvers capable of serving as the default for a system as large as Firefox, this doesn't seem like it will improve privacy that much.

-Ekr

Thanks,
Tommy
________________________________
From: Add <[email-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 15, 2019 3:43 PM
To: Bret Jordan <[email-masked]<mailto:[email-masked]>>
Cc: ADD Mailing list <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] [Ext] Validity of network administrator role

You mean like: https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebkit.org%2Fblog%2F8828%2Fintelligent-tracking-prevention-2-2%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C74064d1f3f304139691908d722334d52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015476053160417&sdata=pWXzbW5xrP7T%2BKC6nTygkJ35s2BWrUd4t7g5agbs0Js%3D&reserved=0> or https://blog.mozilla.org/blog/2019/06/04/firefox-now-available-with-enhanced-tracking-protection-by-default/<https://blog.mozilla..org/blog/2019/06/04/firefox-now-available-with-enhanced-tracking-protection-by-default/>?

-Ekr

Thanks,
Bret

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C74064d1f3f304139691908d722334d52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015476053160417&sdata=dX323O%2BwPbu07WlNFrS%2BqqRh4BOVdUStjcWo1SeVI2k%3D&reserved=0>

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C74064d1f3f304139691908d722334d52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637015476053170412&sdata=TgYEUM95732g1qMrT8ZUz%2F%2Bge0sw3LCdn9Oe96FM2Y8%3D&reserved=0>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 16 Aug 2019 18:16:31 -0400

On Fri, Aug 16, 2019 at 3:01 AM Ralf Weber <[email-masked]> wrote:

> > https://mailarchive.ietf.org/arch/msg/add/NIk8gIPZu52GXDsT8zy4S1I4QsM>),
>
> > so

I don't view DoH and DNSSEC as being substantially in competition.  To the
contrary, I think that ADD with DoH greatly improves the likelihood of
end-to-end DNSSEC being widely deployed.  The main barriers I'm aware of to
stub DNSSEC deployment (broken middleboxes, broken recursives, split-DNS
name squatting, restrictive query APIs with opaque error reporting, ancient
system stub implementations, reflection attacks, truncation retry delays,
...) are all potentially solved when the application is speaking directly
to a known, modern DoH server.

In an ADD world, I'm much more optimistic about DNSSEC.  (Especially if we
can get more deployment support for RFC 7901.)

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 17 Aug 2019 08:05:11 +0200

Moin!

On 17 Aug 2019, at 0:16, Ben Schwartz wrote:
> end-to-end DNSSEC being widely deployed.
Agreed. It could also be a DoT server. As others said DNSSEC and DoH/DoT 
are
complementary and should be used both in a modern name resolution setup.

> The main barriers I'm aware of to
> ....) are all potentially solved when the application is speaking 
> directly
Absolutely, some of this is of course something the DoH/DoT server still 
will
have to cope with. The question is which DoH server. I’d rather see 
the current
DNS server upgraded to DoH or DoT and not switch to another server just
for the sake of doing DoH.

> can get more deployment support for RFC 7901.)
I admire your optimism. We do unfortunately have the example one of the 
first
application using DoH not doing DNSSEC.

So long
-Ralf

---

From: Neil Cook <[email-masked]>
Date: Sat, 17 Aug 2019 09:27:52 +0100

> 
> Wanting to add competitive advantages compared to other ISPs by offering a DNS-based filtering solution is a perfectly good business argument but I cannot understand the argument that this is the only or best solution for this specific use-case.
> 

I’ve not seen anyone arguing that. The fact is that they exist and in widespread use. That is all that is relevant for this list.

Neil

>>> On Aug 16, 2019, at 12:56 AM, Frode Kileng <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

Neil Cook

European Office: 

US Office:

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 21 Aug 2019 17:06:28 +0200 (CEST)

> Il 16 agosto 2019 02:40 Stephen Farrell <[email-masked]> ha scritto:
> 

Well, if you run infrastructure that resolves millions of DNS queries per second, turning DoH on is not a matter of clicking a button et voilà. But I am confident that we will see more big DoH resolvers appear in some months (whether Mozilla will then accept them on their list is another matter).

At the same time, the uncertainty on what the browsers are going to do does not help to convince managers to authorize investment on wide scale DoH deployment.

> nor just a "sent from my iphone" type random thought;-)

Ideally, one could put together a working group of people from all stakeholders (at the IETF or ad hoc) and work out a generalization of Mozilla's policy that could become an industry standard (perhaps allowing for some leeway for different resolvers to offer different features and different clients to require different features). This would allow resolver operators to have a single set of requirements to meet to become accepted by all clients (as long as the minimum requirements for each client are met). 

In turn, this would make it much easier for people to deploy resolvers - much easier than having to apply once per browser and meet sets of potentially conflicting requirements to be accepted on each of their trusted lists, or taking the risk to invest a lot of time and money and deploy encrypted DNS services on a mass scale, just to be told later by the browsers "we don't like you, so users will not be allowed to use your resolver unless they manually change a 3-level-deep configuration option". And there could be some kind of entity tasked with administering the standard and running accreditations.

Note that this is orthogonal to the issue of resolver discovery and choice by the client, though I suppose that some clients might be more willing to use a locally discovered DoH resolver if it is on that list.

I also wrote the above on a beer-mat to meet your condition, but of course this is still totally abstract - however, it does not make sense to spend more effort on this idea if there is not significant interest in working on it together.

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