Subject: [Add] Browser Administrative Authority

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Fri, 24 May 2019 14:48:47 +0000

HI everyone,

I’ve been thinking though some of the issues with the proposal DoH deployment in browsers.

A big part of the tug of war here is  the authority precedence for advanced security and network settings that should be followed.

Historically, it’s been at the device level – which meant the device administrator, which could choose delegate choices to a specific DNS resolver operator, or to the Network DHCP provided settings.

Now the browser is seeking to adding itself into the authority chain for those settings. The trouble being that this is a major change to the administrative trust model.

To date, browser settings have been limited to rendering options, some basic certificate options, addons, and scripting language choices.    Advance security and trust has remained with the device administrator.     Adding the browser to the administrative chain so that it can control advanced security and network settings introduces a problem because the browser does not have an administrative level authority that is as high as the device administrator.

Current hierarchy (top has more authority)

              Device Administrator       -- device authority for security, network, trust settings
              Network Administrator     -- provides recommend network settings to devices
              Resolver Administrator    -- can provide filtering
              Browser  Maker               -- provides core trusted certificate list
              Browser User                  -- can set rendering options, can make limited certificate choices, plugins.  – Impact is limited to the browser sandbox

The problem is that some of the browser makers proposals are now changing this administrative authority hierarchy, but they haven’t done the extra work of establishing administrative trust and working through the consequences of that such as a child being able to change the browser DNS settings and bypass both resolver, Network, and even OS based restrictions.

So they are changing it to:

              Browser Maker                -- provides default DNS resolver and DNS Protocol choices.
              Browser User                  -- can set DNS resolver and DNS protocol
              Device Administrator       -- device authority for security, network, trust settings
              Network Administrator     -- provides recommend network settings to devices
              Resolver Administrator    -- can provide filtering

The path to fixing this maybe to see if there is a way to express the administrative hierarchy that respects the intentions of the device administrator on what hierarchy they want to accept/delegate decisions to.

It maybe that what’s needed is a means to communicate to the browser what authority the device administrator wants it to follow, since in the end the device owner should be in charge.

-glenn

---

From: Tom Ritter <[email-masked]>
Date: Fri, 24 May 2019 10:55:23 -0500

What about the device administrator configuring the browser the way they
want it to behave? As far as I know administratively configured browsers
cannot be overridden by a local user.

-tom

On Fri, May 24, 2019, 9:49 AM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> A big part of the tug of war here is  the authority precedence for
> advanced security and network settings that should be followed.
>
>
>
> Historically, it’s been at the device level – which meant the device
> administrator, which could choose delegate choices to a specific DNS
> resolver operator, or to the Network DHCP provided settings.
>
>
>
> Now the browser is seeking to adding itself into the authority chain for
> those settings. The trouble being that this is a major change to the
> administrative trust model.
>
>
>
> To date, browser settings have been limited to rendering options, some
> basic certificate options, addons, and scripting language choices.
>    Advance security and trust has remained with the device administrator.
>     Adding the browser to the administrative chain so that it can control
> advanced security and network settings introduces a problem because the
> browser does not have an administrative level authority that is as high as
> the device administrator.
>
>
>
>               Browser User                  -- can set rendering options,
> can make limited certificate choices, plugins.  – Impact is limited to the
> browser sandbox
>
>
>
>
>
> The problem is that some of the browser makers proposals are now changing
> this administrative authority hierarchy, but they haven’t done the extra
> work of establishing administrative trust and working through the
> consequences of that such as a child being able to change the browser DNS
> settings and bypass both resolver, Network, and even OS based restrictions.
>
>
>
> The path to fixing this maybe to see if there is a way to express the
> administrative hierarchy that respects the intentions of the device
> administrator on what hierarchy they want to accept/delegate decisions to.
>
>
>
> It maybe that what’s needed is a means to communicate to the browser what
> authority the device administrator wants it to follow, since in the end the
> device owner should be in charge.
>
>
>
>
>
> -glenn
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 May 2019 10:57:43 -0500

This is called “enterprise policy”, and — as far as I know — all major browsers honor it. 

See, e.g., https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise

/a

> On May 24, 2019, at 09:48, Deen, Glenn (NBCUniversal) <[email-masked]> wrote:
> 
> HI everyone,
>

---

From: "Cook, Neil" <[email-masked]>
Date: Fri, 24 May 2019 17:56:56 +0100

Glenn’s point is not just about enterprises. It applies to consumer use cases as well.

Neil

Sent from my iPhone

> On 24 May 2019, at 16:58, Adam Roach <[email-masked]> wrote:
>

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 24 May 2019 17:37:47 +0000

Glenn, that was a great write-up. Thanks for sharing.

To highlight Neil's point about this not being enterprise only: imagine a parent who configures content controls through their ISP. In a world where the browser defaults the user into using the browser's own DNS (DoH or otherwise) while bypassing system policies, children have a no effort needed sidestep to parental controls and it won't be immediately obvious to the parent why their controls don't work.

I don't think asking the platform and other apps on the platform to all be aware of one another's policies is scalable. For the same reasons Glenn gave, I think apps should defer to the platform, redirecting users to make changes there rather than making changes within their own space.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Cook, Neil <neil.cook=[email-masked]>
Sent: Friday, May 24, 2019 9:56 AM
To: Adam Roach
Cc: [email-masked]; Deen, Glenn (NBCUniversal)
Subject: Re: [Add] Browser Administrative Authority

Neil

Sent from my iPhone

On 24 May 2019, at 16:58, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

See, e.g., https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fproducts%2Ffirefox-enterprise%2Fpolicies-customization-enterprise%2Fpolicies-overview-enterprise&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C421d47c01fa144f4193208d6e068dcdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943138330418185&sdata=uuA80939I8ud4IOBT%2BjtbgXuxjYYapkrVPIJzYWDVXE%3D&reserved=0>

/a

On May 24, 2019, at 09:48, Deen, Glenn (NBCUniversal) <[email-masked]<mailto:[email-masked]>> wrote:

HI everyone,

-glenn

--
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%7C421d47c01fa144f4193208d6e068dcdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943138330418185&sdata=oU%2BCn1b6ZnhcqdbC9DfsZJDdbgBuUulonrCmpszw5cg%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%7C421d47c01fa144f4193208d6e068dcdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943138330428195&sdata=UpeS0reJ%2BhVeVP4HuDCqMK3sDCqVDv4o2LAtIyoBS2o%3D&reserved=0>

---

From: Tom Ritter <[email-masked]>
Date: Fri, 24 May 2019 19:23:29 +0000

"imagine a parent who configures content controls through their ISP"

Okay; but then this isn't a device administrator. This is a network
administrator. (And whether it's enterprise or not isn't really
relevant, no feature is restricted to enterprise use.)

The network should be considered hostile until configured otherwise
because... the network usually is hostile. Or at least it's untrusted.
Every cellular connection; every coffee shop, every store's free wifi,
every friend's network you connect to, every AirBnB wireless, every
hotel... Percentage-wise, the number of untrusted networks the average
user connects to dwarfs the number of trusted networks (even if the
percentage of time spent on untrusted networks is dwarfed by the
percentage spent on trusted networks.)

Device administration is the appropriate answer here - it's the
appropriate trust boundary for users. An administrator of a device is
a person or organization the user of that device knows and understands
controls it. For the network to be able to override and disable users'
security and privacy controls is inappropriate - for example we don't
allow networks to strip TLS. UNLESS, of course, the device is
configured to allow such activity.

-tom

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 24 May 2019 19:37:02 +0000

Good point. I made a leap by connecting network admin with device admin for a simple reason: today, most platforms do trust their network via their default setting of using the DNS servers recommended by the network. Whether that's ideal is another topic.

To eliminate network trust as a variable in this discussion, let's have the story be the use of a DNS provider, say CleanBrowsing for example. In this scenario, the parent as the device admin has manually changed the device's DNS server settings to point to CleanBrowsing. However, the use of an app which rolls its own DNS stack by default will bypass this configuration. Device authority has been sidestepped in a way the user is not likely to understand.

I agree with your point that device administration is the appropriate answer. Apps should defer to (or proactively refer to if they want to suggest changes) device configuration rather than the device needing to be aware of the nuances of each app it could be running.

Thanks,
Tommy
________________________________
From: Tom Ritter <[email-masked]>
Sent: Friday, May 24, 2019 12:23 PM
To: Tommy Jensen
Cc: Cook, Neil; Adam Roach; [email-masked]; Deen, Glenn (NBCUniversal)
Subject: Re: [Add] Browser Administrative Authority

-tom

On Fri, 24 May 2019 at 17:53, Tommy Jensen
<Jensen.Thomas=[email-masked]> wrote:
> See, e.g., https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fproducts%2Ffirefox-enterprise%2Fpolicies-customization-enterprise%2Fpolicies-overview-enterprise&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=Qx5XXn2n77kMw9TscJ5Fxexlnju92%2BQtUad%2FqEXU500%3D&amp;reserved=0
>
> /a
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=wbq0RiqgNQODZ%2FY%2BCX6Ie1iYjbG4uw5iRHQ7glreOIk%3D&amp;reserved=0
>
> --
> 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%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=wbq0RiqgNQODZ%2FY%2BCX6Ie1iYjbG4uw5iRHQ7glreOIk%3D&amp;reserved=0
>
> --
> 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%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=wbq0RiqgNQODZ%2FY%2BCX6Ie1iYjbG4uw5iRHQ7glreOIk%3D&amp;reserved=0

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Fri, 24 May 2019 19:55:46 +0000

On 5/24/19, 12:23 PM, "Tom Ritter" <[email-masked]> wrote:

    

[GD] The reason why I put it as a hierarchy isn't to make any judgement on the network's hostility or trustworthiness.    
         It's all about the device owner making the choice on if they accept, and thus are choosing to trust, settings from the network.        

[GD] in the case of "imagine a parent who configures content controls through their ISP", 
        they parent is making a choice to accept the their ISP as trust worthy.   It's not that the 
        network is imposing that upon them, they are making the choice to accept and trust.

[GD]  Control Hierarchy Classic:

        Control Hierarchy Being Proposed by Some: 

 [/GD]
    
On 5/24/19, 12:23 PM, "Tom Ritter" <[email-masked]> wrote:

[GD]. I don't hear anyone proposing that the network should be in the role of overriding or disabling a device's security or privacy controls.    
Likewise, neither should browsers be overriding or disabling the device's security or privacy controls..   It's the device
Administrator that should have final authority in such things.   The entire past 30+ years of OS and security architecture is built
on that model.  Yet, some of the public plans have proposed doing just that.

[GD] The question is how to respect the hierarchy when introducing new protocols so as to avoid introducing undesired side effects
Such as children being able to trivially bypass parental and school choices.

[GD] This could also be solved by doing it at the device/OS layer instead of inside the browser, because then it would integrate with the device 
Administration hierarchy.    Making DNS resolver and protocol choices in the application is a major change to the traditional role of 
DNS as an OS/device level choice.  

[GD] In the end , doing it in the browser creates 2 DNS behaviors:  (1) One for the OS and apps; (2) another that's different in each browser that overrides the device.

[GD] Perhaps DoH settings could be a device setting done at the OS level that the browsers could look to in order to understand the device administrators intent?   This could even
be a setting the device administrator can choose to inherit from a network, if again they choose to.

-glenn

---

From: Melinda Shore <[email-masked]>
Date: Fri, 24 May 2019 21:01:15 -0800

To be honest I think the framing is perhaps not particularly
correct.  Right now browser vendors are mediating trust, anyway,
through their root programs and other security policy enforcement
mechanisms that are not being explicitly chosen by the user or
the ISP.  I'm really not sure what to make of

    "The problem is that some of the browser makers proposals are now
    changing this administrative authority hierarchy, but they haven’t
    done the extra work of establishing administrative trust"

given the current state of the web PKI.  (Allowing, of course,
that the current state of the web PKI may be the strongest
argument against allowing browser vendors to own trust for
name resolution.)

I think the notion that they may be choosing a DNS resolver for web
applications is not that much of a change from current practice.  I
don't really love this but it's where we are at the moment.

I do, however, think that application authors understand their
own security requirements better than ISPs do, and in that sense
may be closer to the user's intentions than ISPs are (and indeed,
user needs and ISP desires are often in conflict).  In the
absence of some standard way of allowing applications to discover
their security environment I'm pretty good (with reservations) with
them choosing their own DNS resolver and DNS transport.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: "Cook, Neil" <[email-masked]>
Date: Sat, 25 May 2019 09:39:32 +0100

Melinda,

The specific example that’s been referred to is users (e.g. head of household) who have chosen to enable malware filtering and/or parental control on their broadband connection (this also applies to mobile or indeed other types of network).

This isn’t so much about what ISPs want, this is about what users want (and in the specific case of families, about what the responsible adult wants).

Suggesting that application manufacturers in this case are “closer to the user’s intentions” is clearly not true, in fact it is quite the opposite.

For devices that have a layered admin model, the admin for that device should surely take precedence over individual applications (this becomes trickier with devices like iPads and smartphones which only have a single user/admin).

Neil 

Sent from my iPhone

> On 25 May 2019, at 06:01, Melinda Shore <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 May 2019 12:42:47 +0100

Hi Glenn,

> resolver operator, or to the Network DHCP provided settings.

(Some) VPNs don't match that history. There are probably other
examples but those never caused such debate. Main thing is I
don't think we can ignore the issue that the scale of the
potential (not yet actual) change is part of what's causing
angst, and not just the functional/architectural/control change.
I think that means that attempts such as yours (which is fair,
though I'd quibble a bit about some details) to analyse this
functionally are naturally likely to devolve back down to
the kind of well-meant whataboutery [1] that we've seen
before and are starting to see repeated in this thread.

Secondly, while I'd love to see OSes offer new APIs so that
applications could e.g. tell if DoT is in use, ISTM that we
can't expect that application developers who want better
DNS privacy will hold off on use of DoH and wait for such
APIs to be offered across the various platforms about which
they care. So I'm not sure there's a viable approach that
largely preserves the status-quo wrt controls over DNS even
though it'd be a great thing if OSes were providing such
APIs to applications. I think that means that this debate
can't really end up at the status-quo if applications do
want to use our DNS privacy mechanisms. That doesn't mean
we end up with your "new" hierarchy but it may mean that we
have to accept that the "old" hierarchy is going to be
changed for sure and that there's little point in trying to
fully maintain that.

Cheers,
S.

[1] https://en.wiktionary.org/wiki/whataboutery

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Sat, 25 May 2019 14:08:50 +0000

Hi Stephen,

> On May 25, 2019, at 4:42 AM, Stephen Farrell <[email-masked]> wrote:
> 
> Some) VPNs don't match that history. There are probably other
> examples but those never caused such debate

I think one important difference with VPNs is that the device admin likely chose to install them since many of them require admin authority to install.  In most cases, the user or admin also had to choose to configure and turn them on.  So it would be working within the classic administrative hierarchy.

I suspect, that many would be very upset, If there was a situation where an application developer decided on their own to quietly install a user space VPN and then route all the app’s traffic through VPN endpoints also chosen by developer without first getting the users or administrators agreement and full awareness.   

Further, if the app and it’s VPN resulted in a variety of other things breaking that were important to the user, such as security and machine configuration, I suspect the application would soon be the subject of massive debate. 

Hence the debate this is causing.

To be clear, my analysis was not in any way expressing a concern for the DoH protocol.  It was to highlight that the proposed application level changes were violating a well established security and device management architecture and with that choice comes unintended side effects.   

We have examples of such conscious choices to bypass established hierarchies in other contexts - If a network protocol did something similar, we’d call it a layer violation.  Programmers have encapsulation violation.  

With each choice to violate architectural hierarchies, there is often a driving motivation to get something done; For those of us who have crossed the line and done such things, the lesson of needing to properly and fully deal with unintended side effects is something I for one have come to learn and respect.

I am also worried about the notion that we need just push it through, or that we can’t wait to do it right, because there is a urgent need to deploy this particular application level change in choice of DNS resolvers and protocol selection.    It worries me a for a couple reasons, not the least of which is it means that time won’t be taken for studying the possible side effects and dealing with them properly.

We’ve already identified the unintended side effect of breaking filters for child protection and things like malware sites.  

There are and will be others.

Going back to VPN example at the start of this note. There is likely unintended side effects with VPNs as they often depend on DNS configurations and resolver choices in order to work seamlessly.  Certainly secure corporate environments often rely of split DNS for their VPNs.  Having a browser level DNS that resolves address differently than the VPN expects may cause a lot of unexpected and hard to diagnose behavior for the users.

Identifying, understanding, and dealing with unintended side effects seems like an important consideration for something this impactful.

This is not simply a case of let’s be perfect before doing anything.  It is very much a case of wanting to avoid major disruption for users that we should have seen coming if we took the time needed. 

FWIW - My suggestion of an OS or device level means for managing and respecting the administrators choice to follow doesn’t necessarily depend on the OS manufacturer to accept changes.  Most OSs have the means to have application level settings that require device administrator privilege to be set and managed.  

Regards,
Glenn

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 May 2019 15:40:19 +0100

Hiya,

Coupla comments and a question at the end...

On 25/05/2019 15:08, Deen, Glenn (NBCUniversal) wrote:
> I think one important difference with VPNs is that the device admin
> likely chose to install them since many of them require admin
> authority to install.. 

Browser installs also do; or if shipped with the device then
the device vendor made that choice so I see zero difference
there.

> In most cases, the user or admin also had to
> choose to configure and turn them on.  So it would be working within
> the classic administrative hierarchy.
> 
> I suspect, that many would be very upset, If there was a situation
> where an application developer decided on their own to quietly
> install a user space VPN and then route all the app’s traffic through
> VPN endpoints also chosen by developer without first getting the
> users or administrators agreement and full awareness.
> 
> Further, if the app and it’s VPN resulted in a variety of other
> things breaking that were important to the user, such as security and
> machine configuration, I suspect the application would soon be the
> subject of massive debate.
> 

Gotta say I don't agree that the above's that valid. Minor
VPN products misbehave all the time in way worse ways and
don't cause this level of debate. I think we ought be clear
that the volume or traffic and number of users involved is
why we're getting this level of debate, not architectural
(im)purity.

> To be clear, my analysis was not in any way expressing a concern for
> the DoH protocol.  It was to highlight that the proposed application
> level changes were violating a well established security and device
> management architecture and with that choice comes unintended side
> effects.

Sure.

> 
> We have examples of such conscious choices to bypass established
> hierarchies in other contexts - If a network protocol did something
> similar, we’d call it a layer violation.  Programmers have
> encapsulation violation.
> 
> With each choice to violate architectural hierarchies, 

Using terms like "violate" is likely to irritate those in
favour of applications making these choices, just like
network operators get irritated when folks describe the
network as being hostile. Neither term is wrong but it's
not particularly useful for us to irritate one another
either;-)

> there is often
> a driving motivation to get something done; For those of us who have
> crossed the line and done such things, the lesson of needing to
> properly and fully deal with unintended side effects is something I
> for one have come to learn and respect.
> 
> I am also worried about the notion that we need just push it through,

Push what through? DoH is done as an RFC. What other "it" do think
is needed? (That might result from this debate.)

Cheers,
S.

> or that we can’t wait to do it right, because there is a urgent need
> to deploy this particular application level change in choice of DNS
> resolvers and protocol selection.    It worries me a for a couple
> reasons, not the least of which is it means that time won’t be taken
> for studying the possible side effects and dealing with them
> properly.
> 
> We’ve already identified the unintended side effect of breaking
> filters for child protection and things like malware sites.
> 
> Going back to VPN example at the start of this note. There is likely
> unintended side effects with VPNs as they often depend on DNS
> configurations and resolver choices in order to work seamlessly.
> Certainly secure corporate environments often rely of split DNS for
> their VPNs.  Having a browser level DNS that resolves address
> differently than the VPN expects may cause a lot of unexpected and
> hard to diagnose behavior for the users.
> 
> Identifying, understanding, and dealing with unintended side effects
> seems like an important consideration for something this impactful.
> 
> This is not simply a case of let’s be perfect before doing anything.
> It is very much a case of wanting to avoid major disruption for users
> that we should have seen coming if we took the time needed.
> 
> 
> 
> FWIW - My suggestion of an OS or device level means for managing and
> respecting the administrators choice to follow doesn’t necessarily
> depend on the OS manufacturer to accept changes.  Most OSs have the
> means to have application level settings that require device
> administrator privilege to be set and managed.
> 
> Regards, Glenn
>

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Sat, 25 May 2019 14:48:38 +0000

Hi Melinda,

> On May 24, 2019, at 10:01 PM, Melinda Shore <[email-masked]> wrote:
> 

I don’t see this as equivalent to the trust mediation that browser makers do through their certificate root programs or security settings because those things are very much web application domain choices and are entirely appropriate to be controlled in the context of the web browser.   Those trust certificates are for web servers and applications, and so are in exactly the right place.

DNS has traditionally been a network service and as such it’s configuration and settings have been a network level domain choice made by the device administrator.    While it is possible for the device administrator to choose to delegate network choices to the network, it always starts with the device administrator to make the choice.

In the case of browsers, there is an established means for the root list to be maintained securely, and to be update when needed.  That’s fundamental to the trust model working. If it were possible for this root list to be altered outside of that means and it’s associated integrity controls, then the trust model would be broken because it would be possible for unapproved roots to be installed.

By pulling the DNS up into the application settings, it’s also abandoning the security model for administration of those settings, the same as if the root certificates were pulled out and say placed into a simple file in the user’s file system.  

It’s the removal of information from its established management and protection context that causes the problem I pointed out.

> argument against allowing browser vendors to own trust for

;)

> them choosing their own DNS resolver and DNS transport.

My analysis didn’t grant any implicit authority unto ISPs.   I don’t see this as the root debate here. Instead, it’s about that authority for making such choices starts with the device administrator, then the user, and only in cases where the administrator chooses to do so do the network’s provided settings come into play.

Also, when I say network settings I do not simply mean the ISP.  In my home network my router provides DNS settings that I as the router and administrator explicitly chose.  Yet, each device administrator can choose to set their own.     None of that is ISP controlled.

So this isn’t about the ISP vs browser application maker being more connected to the user’s wants,

However, with the current proposals of it being done by default at a browser app level using default settings pushed down by the application maker, I’m going to be in the position of having to watch the configuration of browser apps on each and every device that I manager, or provide support to (as I’m the IT support desk at home) to make my home setting desires match what the browser app uses, and I’m going to have to do it again and again at each update to ensure that the app didn’t change them again.  That’s a lot of work for users who want nothing more than to have their administrative choices respected. 

Regards, 
Glenn

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Sat, 25 May 2019 15:10:19 +0000

Howdy,  inline..

> On May 25, 2019, at 7:40 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

The difference is in the administrative level needed to make changes, and how that fits with the administrators and user’s expectations, as well as expectations of working with the understood administrative model of authority.

> why we're getting this level of debate, not architectural

Certainly, the scale of users affected here is raising the level of attention and impact. 

Some minor VPN not working isn’t really going to affect many users or cause much disruption.  But at scale it makes a lot of users unhappy, and can also cost organizations a lot of money due to support calls and problems.
> not particularly useful for us to irritate one another

Sorry, my use of the word “violate” was chosen because it’s the term of art for when  protocol layers and data encapsulation in objects is bypassed or not observed.     It was not in anyway meant to irritate.

> is needed? (That might result from this debate.)

I was responding to your original notes assertions that I read to be about not getting stuck in a perpetual debate in search of perfection.  (Because the ietf never does that!) 

My understanding was that this list was being used to additionally discuss and explore the impacts and consequences of proposed DoH architectural deployment choices.  

So what I was saying is that I hope the community of internet and web architects and those who build the applications and systems take the time to get the proposed deployments right because the scale of the impact of the choice of deployment approach is very very large here and it will amplify any unintended side effects.

-Glenn

---

From: Melinda Shore <[email-masked]>
Date: Sat, 25 May 2019 11:17:07 -0800

On 5/25/19 6:48 AM, Deen, Glenn (NBCUniversal) wrote:
> I don’t see this as equivalent to the trust mediation that browser
> makers do through their certificate root programs or security
> settings because those things are very much web application domain
> choices and are entirely appropriate to be controlled in the context
> of the web browser.   Those trust certificates are for web servers
> and applications, and so are in exactly the right place.

Yeah, but you can make the same case for name resolution.
It's certainly the case that some applications that run in
browsers have narrower security requirements around DNS
than others do, and right now there's no way for those
applications to discover whether or not their DNS queries
are protected.

But, I think the broader problem is that ISPs are not running
recursives that use encrypted transport, and because they're not
other folks are stepping up/in.  I suppose that in a better
world an endpoint would be able to check whether or not they
can protect DNS traffic to the default recursive and, if not,
fall back to one of {Google, Cloudflare, whomever} but that's
not where we are right now.

> In the case of browsers, there is an established means for the root
> list to be maintained securely, and to be update when needed.  That’s
> fundamental to the trust model working. If it were possible for this
> root list to be altered outside of that means and it’s associated
> integrity controls, then the trust model would be broken because it
> would be possible for unapproved roots to be installed.

It hasn't always been the case that browser root programs had
strict entry requirements, or that CAs were audited, or that
there were external mechanisms for misissuance detection.  Those
were added as problems were identified.  And, I'll note, that
the browsers are occasionally acting unilaterally around PKI
issues, as well - this situation with encrypted DNS is neither
unique nor isolated.

I do think part of the problem here is that for whatever reason
our community (the IETF) hasn't come to consensus on problems
related to trust in the DNS.  If you don't have a trustworthy
name resolution system you can't trust much else, either.  This
relates to both being able to get a correct answer that hasn't
been mucked with by a third party, and to privacy protection
of queries and responses.  It seems unsurprising to me that
browsers (and other application vendors) would respond to the
default unprotected DNS situation by doing something about it
themselves.

Melinda

---

From: Paul Ebersman <[email-masked]>
Date: Sat, 25 May 2019 13:25:41 -0600

melinda> I do think part of the problem here is that for whatever reason
melinda> our community (the IETF) hasn't come to consensus on problems
melinda> related to trust in the DNS.  If you don't have a trustworthy
melinda> name resolution system you can't trust much else, either.  This
melinda> relates to both being able to get a correct answer that hasn't
melinda> been mucked with by a third party, and to privacy protection of
melinda> queries and responses.  It seems unsurprising to me that
melinda> browsers (and other application vendors) would respond to the
melinda> default unprotected DNS situation by doing something about it
melinda> themselves.

If you are worried about full end to end data integrity, DoH/DoT isn't
it. It's a point to point encryption with no way to know if that
recursive you're talking to actually got valid DNS data.

DNSSEC solves that problem (end to end data integrity).

DoT/DoH solves the confidentiality (snooping the wire) problem but
that's all it solves.

If you want privacy and validated data, you need both.

But that's the technology piece. That still doesn't address user consent
vs network policy.

Let's not conflate several problems into one big hairball. Glenn laid
out some policy and consent issues. That seems something useful to at
least enumerate and define clearly so we at least know what problem
we're trying to chew on first.

---

From: Erik Kline <[email-masked]>
Date: Sat, 25 May 2019 12:27:20 -0700

> applications to discover whether or not their DNS queries
FWIW, we did try to address this in Android's DoT implementation with
LinkProperties#getPrivateDnsServerName()
<https://developer.android.com/reference/android/net/LinkProperties#getPrivateDnsServerName()>
 and LinkProperties.html#isPrivateDnsActive()
<https://developer.android.com/reference/android/net/LinkProperties.html#isPrivateDnsActive()>.
But that's just the one platform.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 May 2019 23:28:22 +0100

On 25/05/2019 16:10, Deen, Glenn (NBCUniversal) wrote:
> I was responding to your original notes assertions that I read to be
> about not getting stuck in a perpetual debate in search of
> perfection.  (Because the ietf never does that!)
Heh:-)

> My understanding was that this list was being used to > additionally discuss and explore the impacts and
> consequences of proposed DoH architectural deployment
> choices.

Ah, fair enough. I thought you had some specific end-result
in mind. Might be no harm if we started to think about that
at some point. (Though I suspect we need the browser folks
to figure out what they wanna do about split-horizon before
we can get done here.)

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 May 2019 20:38:54 -0400 (EDT)

On Sat, 25 May 2019, Melinda Shore wrote:

> recursives that use encrypted transport

While from a generic hygiene point of view I agree, but a security point
I don't. People are more in need of protection against DNS manipulation
from their last mile ISP (malicious and "helpful") than from anyone
else. If my local ISP uses encrypted DNS, I still don't trust them. And
the second issue is that ISPs sell DNS query data and other private
information of their customers to third parties and/or their own
affiliates.

As a user I cannot determine that if I once google for "canadian contact
lenses", who and why and where that info went. All I know is that 60%
of ads are suddently about contact lenses across my house, devices and
applications. And the only way out is to encrypt everything end to end,
with no midle man or ISP seeing anything.

> not where we are right now.

I don't think that solves an interesting problem. At home, systems can
be configured to use a third party DNS (and DoT/DoH helps those IPs to
not get hijacked by their ISP). But for mobile devices, things are much
harder to reconfigure and that's where we need protection the most.
Because there my DNS queries are also getting mapped against my location
data against my own personal privacy interest.

> of queries and responses.

And we are making it worse and worse over time by keeping DNSSEC as an
optional part of DNS, instead of saying that the experiment has been
successful and we are now moving towards phasing out insecure DNS.

>  It seems unsurprising to me that

It wasn't my impression that the deployment of DoT/DoH by browsers was
done primarilly to help the user get a more secure DNS. If that was
the case, tls-dnssec-chains would have zoomed through the WG. Instead,
it seems browser vendors want a more robust and lower latency DNS. A
worthy goal but not a security goal. Also the latency saved will not
give the enduser a faster page, but will be spend extending the ad
auctions to generate more profit of the end users. Bonus points for
encrypting the DNS packets so the competition cannot see them for their
own advertisement and search platforms. Transport security is just a
side effect of all of this.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 May 2019 20:18:55 -0400 (EDT)

>       applications to discover whether or not their DNS queries

Since browsers refuse to use DNSSEC, and thus TLSA, why do browsers have
narrower security for some apps? It seem they purposepully present apps
with no DNS security. And their runaround now is "let our browsers use
transport secured unsafe DNS towards our own trusted DNS infrastructure".

That's correcting a mistake with a mistake, and now we all have to take
into account that a few browser/DNS vendors will be the choke point for
large scale censorship based on DNS.

Paul

---

From: Christian Huitema <[email-masked]>
Date: Sun, 26 May 2019 21:41:47 -0700

> with no midle man or ISP seeing anything. 

Paul,

I don't like surveillance any more than you do, but look at the example
that you just gave. You are asking Google for information about a
specific product, presumably over an encrypted connection to their
search engine. Your ISP only sees an encrypted connection to
"google.com". You may then click on some of the search results, at which
point both Google, your ISP and all the trackers on the target web page
know that you contacted https://www.contactlensescanada.com/. Then you
complain that the surveillance apparatus is bombarding you with ads for
contact lenses, and you blame the ISP for that. Seriously?

-- Christian Huitema

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 27 May 2019 11:25:04 +0200 (CEST)

> Il 24 maggio 2019 21:23 Tom Ritter <[email-masked]> ha scritto:
> 

There definitely is a security/privacy issue for people and devices that roam a lot and it's fine to address it, but IMHO this is the view you get from a specific viewpoint and does not represent the full picture or even the best part of it. There are tons of people/devices that do not move and only use the Internet from a single trusted network, usually a home/corporate one, and rely on it for security. As a subset of this, there also is an increasing number of cases in which the user controls the network much more than the device: think of all the IoT stuff that you buy and deploy at home, but which is really a black box to you - unless you can use your local network administrator power to exert at least some control on their traffic.

Perhaps this should lead to different control hierarchies and policies for roaming devices (e.g. mobile phones) than those for the rest of the world. More generally, this is what makes the ADD issues hard: different use cases have conflicting requirements. Perhaps, part of the work could be documenting the appropriate control hierarchies in different situations, as Glenn did, and then see if there are ways to reconcile the conflicts - and I suspect these are going to be by policy and user interaction, rather than by technical instruments.

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

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 27 May 2019 11:27:49 +0200 (CEST)

> Il 25 maggio 2019 21:17 Melinda Shore <[email-masked]> ha scritto:
> 

If there were general agreement that this is the desired final outcome, I think there could be broad support for an industry effort to make it materialize pretty quickly (and it would be a great result of the wake-up call generated by DoH). However, as far as I understand, not everyone in the browser world thinks so.

Ciao,
--

---

From: tirumal reddy <[email-masked]>
Date: Mon, 27 May 2019 16:29:27 +0530

On Mon, 27 May 2019 at 14:57, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> If there were general agreement that this is the desired final outcome, I
> think there could be broad support for an industry effort to make it
> materialize pretty quickly (and it would be a great result of the wake-up
> call generated by DoH). However, as far as I understand, not everyone in
> the browser world thinks so.
>

If the DOH server provided by the network offers the same level of privacy
preserving data policy as the DOH server pre-configured in the browser, Why
shouldn't the browser use the network provided DOH server ?

-Tiru

---

From: Jim Reid <[email-masked]>
Date: Mon, 27 May 2019 12:23:44 +0100

On 27 May 2019, at 11:59, tirumal reddy <[email-masked]> wrote:
> 
> If the DOH server provided by the network offers the same level of privacy preserving data policy as the DOH server pre-configured in the browser, Why shouldn't the browser use the network provided DOH server ?

How could the browser tell that both DoH servers have the same policy?

How does the browser (or anything else for that matter) know what some arbitrary DoH server’s privacy preserving data policy is? Where will this be documented and published in a way that a web-based application or the end user can understand and then make an informed choice?

Now rinse and repeat that for other server-side policies: data retention, GDPR compliance, DNS filtering/blocking, TLS session resumption, ECS behaviour, QNAME minimisation, NXDOMAIN rewriting, query-related adware, etc, etc.

Oh, and if some DoH server says “I do QNAME minimisation” (say), does the browser or end user simply take that on trust or would they somehow be expected to verify that for themselves?

---

From: tirumal reddy <[email-masked]>
Date: Mon, 27 May 2019 18:42:01 +0530

On Mon, 27 May 2019 at 16:53, Jim Reid <[email-masked]> wrote:

> > If the DOH server provided by the network offers the same level of
> privacy preserving data policy as the DOH server pre-configured in the
> browser, Why shouldn't the browser use the network provided DOH server ?
>

> How does the browser (or anything else for that matter) know what some
> arbitrary DoH server’s privacy preserving data policy is? Where will this
> be documented and published in a way that a web-based application or the
> end user can understand and then make an informed choice?
>

https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-03#section-10
defines a new privacy certificate extension that identifies the privacy
preserving data policy of the DNS server, it is in a machine-parsable
format.

>
> Now rinse and repeat that for other server-side policies: data retention,
> GDPR compliance, DNS filtering/blocking, TLS session resumption, ECS
> behaviour, QNAME minimisation, NXDOMAIN rewriting, query-related adware,
> etc, etc.
>
> Oh, and if some DoH server says “I do QNAME minimisation” (say), does the
> browser or end user simply take that on trust or would they somehow be
> expected to verify that for themselves?
>

End user typically does not trust DOH server in a untrusted network (e.g.
public WiFi network) and may only use the DOH server provided by trusted
network (e.g. Enterprise, Secure home networks), similar to the way users
disable VPN connection in specific networks and enable VPN connection by
default in other networks for privacy. In addition, the privacy extension
includes a URL that points to the security assessment report of the DNS
server by a third party auditor.

Cheers,
-Tiru

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Mon, 27 May 2019 14:03:54 +0000

Hi Paul,

> On May 26, 2019, at 8:44 PM, Paul Wouters <[email-masked]> wrote:
> 

This may not be a good example for use in the current discussion as it’s really a web search and web page tracking example and not DNS as everything in this example can be accounted for entirely by what’s going on inside your browser, the search engine, and visited web pages.

It’s well documented that the search engine and linked visited web pages are all instrumented and mined to track your web visits and correlate them so that the Ad provider, which is owned and run by search engine, can sell Ads targeted to you.  The cited example is just the web search and advertising technology and business model at work.  

The hard work needed to turn DNS queries into such actionable target Ads isn’t worth doing when the search engine already knows the exact search terms you are looking for and all the subsequent web pages you visit afterward.   

The fact that they appear on many devices across your house would suggest that the tracking device infrastructure is also correlating your home activity around the shared NAT address your home uses, and it is then targeting ads to any browser activity that comes from that IP address.  All of this will still work the same way even when application and DNS traffic if encrypted end to end.

Encryption of DNS or general encryption of all network traffic won’t help in the case of tracking web activity by Ad networks since the search engine and every web page will still in the see, track, and report everything you do at the web application level.  The tracking and advertising technology and business model that finances much of the web won’t be affected in any way by on the wire encryption.

The discussion at hand isn’t about the web Ads business model, it’s about how  the deployment architectures of technologies like DoT and DoH might be best done,  what bad consequences may come from poor deployment choices, and what gaps are still missing in the technologies so as to permit them to be deployed without also breaking a lot of other important Internet, application, and web infrastructure at the same time.

-Glenn

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 May 2019 22:49:40 -0400 (EDT)

> contact lenses, and you blame the ISP for that. Seriously?

I should have restrictd by last sentence a bit. I cannot determine who is
sharing my desire for contact lenses. It could be the ad platform, google,
facebook trackers, or anyone monitoring my DNS queries, such as my ISP.

Arguably, I would have a better idea who is sharing that information if
my last mile was not getting a free look at all my DNS queries, as in
that case only a few https endpoints could know this information.

Anyway, my point was that the ISP (carrier of hotspot) only uses their
view of my DNS to my detriment. Sending them encrypted to the ISP gains
me nothing. (exception for RBL enhanced DNS servers, but as long as they
are breaking DNSSEC, they cannot be distinguished from a malicious
attack)

Paul

---

From: Neil Cook <[email-masked]>
Date: Tue, 28 May 2019 08:57:56 +0100

> On 28 May 2019, at 03:49, Paul Wouters <[email-masked]> wrote:
> 

I don’t know the case of your particular ISP, but IMO saying things like "the ISP (carrier of hotspot) only uses their view of my DNS to my detriment” is not very helpful.

All the ISPs I know and work with spend a great deal of time trying to ensure that DNS works well for their customers, including things minimising latency, and spending a lot of money and time on hosting CDN nodes in their network that are close to their customers (since DNS is often/usually used to send customers to their closest content node).

Maybe that’s not true everywhere, but equally so is the “ISPs are evil and do nothing for me” point of view.

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: tirumal reddy <[email-masked]>
Date: Tue, 28 May 2019 15:45:37 +0530

> are breaking DNSSEC, they cannot be distinguished from a malicious

Network security functions (NSF) are also deployed by ISPs to protect home
networks and mobile subscribers, for instance NSF can perform DNS filtering
to block malicious domains. You may want to look into the work happening in
I2SNF https://datatracker.ietf.org/wg/i2nsf/about/ and SFC
https://datatracker.ietf.org/wg/sfc/about/.

Cheers,
-Tiru

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 May 2019 10:40:42 -0400 (EDT)

> I don’t know the case of your particular ISP, but IMO saying things like "the ISP (carrier of hotspot) only uses their view of my DNS to my detriment” is not very

I meant, either they don't interfere or resell DNS data, in which case
the last mile is safe because no one else has access to it, or they do
interfere or resell DNS data, in which case encryption to the same ISP
does not help defend against the attack.

But perhaps my view was a bit too simplistic with multi-tenant
deployments. I would hope my ISP, that uses Bell for their last mile,
would encrypt all data between my modem and their network, so Bell
couldn't see anything, but that is not likely to be the case.

Note also that I meant that ISP's can be coerced to mangle DNS, such
as for the recent mandated porn filter in the UK. I did not mean to
say mangling at the ISP level is always the ISPs fault. It could be a
government fault.

Paul

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 28 May 2019 15:43:27 +0000

First – thanks for the pointer!

Comment – things like ‘logging’ seem very binary. What about default logging = no except if FQDN = malware C&C, in which case yes (to support notifying the end user of infection)?

From: Add <[email-masked]> on behalf of tirumal reddy <[email-masked]>
Date: Monday, May 27, 2019 at 9:12 AM
To: Jim Reid <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] publication of DoH Resolver policies

On Mon, 27 May 2019 at 16:53, Jim Reid <[email-masked]<mailto:[email-masked]>> wrote:

https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-03#section-10 defines a new privacy certificate extension that identifies the privacy preserving data policy of the DNS server, it is in a machine-parsable format.

End user typically does not trust DOH server in a untrusted network (e.g. public WiFi network) and may only use the DOH server provided by trusted network (e.g. Enterprise, Secure home networks), similar to the way users disable VPN connection in specific networks and enable VPN connection by
default in other networks for privacy. In addition, the privacy extension includes a URL that points to the security assessment report of the DNS server by a third party auditor.

Cheers,
-Tiru

---

From: "Winfield, Alister" <[email-masked]>
Date: Tue, 28 May 2019 16:36:06 +0000

It would be wonderful if every malicious domain was known prior to its use, sadly except where a DGA is known that’s not the case. So it can be useful to have a little historic information to see the extent of the issue once it’s become known.

It’s also true that with performance issues unless they are very obvious (eg impacting say Facebook, Google, Amazon etc), operators necessarily rely on analytics or customers to complain. Given issues can be transient or periodic only a historic record can provide insight into the root cause.

Alister

From: Add <[email-masked]> on behalf of "Livingood, Jason" <[email-masked]>
Date: Tuesday, 28 May 2019 at 16:43
To: tirumal reddy <[email-masked]>, Jim Reid <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] publication of DoH Resolver policies

https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-03#section-10<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-dprive-bootstrap-dns-server-03%23section-10&data=02%7C01%7Calister.winfield%40sky.uk%7Cd36e8632ef774a63e75608d6e383483f%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636946550340220810&sdata=8%2Fkda0%2B9qoR%2FljDojoEKu%2FGQpol%2BhJl0PtuIwASKPUY%3D&reserved=0> defines a new privacy certificate extension that identifies the privacy preserving data policy of the DNS server, it is in a machine-parsable format.

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

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

---

From: Petr Špaček <[email-masked]>
Date: Wed, 29 May 2019 10:14:38 +0200

On 28. 05. 19 18:36, Winfield, Alister wrote:
> It would be wonderful if every malicious domain was known prior to its
> use, sadly except where a DGA is known that’s not the case. So it can be
> useful to have a little historic information to see the extent of the
> issue once it’s become known.
> 
>  
> 
> It’s also true that with performance issues unless they are very obvious
> (eg impacting say Facebook, Google, Amazon etc), operators necessarily
> rely on analytics or customers to complain. Given issues can be
> transient or periodic only a historic record can provide insight into
> the root cause.

I disagree, it is not corrent to claim that blacklists are not useful
becuse the black list needs to be filled in first. For example e-mail
spam lists often get domains blacklisted in _minutes_ from beginning of
spam campain.

Sure, it takes some time to get bad domains on blacklists so naturally
there is a window of opportunity for attackers, but security is not
binary at all and closing the window as early as possible is the very
nature of Internet security.

Once domains is blacklisted it is useful to block it at various levels
(or just log it for a while), depending on situation.

Petr Špaček  @  CZ.NIC

> 
>  
> 
> Alister
> 
>  
> 
> *From: *Add <[email-masked]> on behalf of "Livingood, Jason"
> <[email-masked]>
> *Date: *Tuesday, 28 May 2019 at 16:43
> *To: *tirumal reddy <[email-masked]>, Jim Reid <[email-masked]>
> *Cc: *ADD Mailing list <[email-masked]>
> *Subject: *Re: [Add] publication of DoH Resolver policies
> 
>  
> 
> Comment – things like ‘logging’ seem very binary. What about default
> logging = no except if FQDN = malware C&C, in which case yes (to support
> notifying the end user of infection)?
> 
>  
> 
> *From: *Add <[email-masked]> on behalf of tirumal reddy
> <[email-masked]>
> *Date: *Monday, May 27, 2019 at 9:12 AM
> *To: *Jim Reid <[email-masked]>
> *Cc: *ADD Mailing list <[email-masked]>
> *Subject: *Re: [Add] publication of DoH Resolver policies
> 
>  
> 
>     privacy preserving data policy as the DOH server pre-configured in
>     the browser, Why shouldn't the browser use the network provided DOH
>     server ?
> 
>     How does the browser (or anything else for that matter) know what
>     some arbitrary DoH server’s privacy preserving data policy is? Where
>     will this be documented and published in a way that a web-based
>     application or the end user can understand and then make an informed
>     choice?
> 
>  
> 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-dprive-bootstrap-dns-server-03%23section-10&data=02%7C01%7Calister.winfield%40sky.uk%7Cd36e8632ef774a63e75608d6e383483f%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636946550340220810&sdata=8%2Fkda0%2B9qoR%2FljDojoEKu%2FGQpol%2BhJl0PtuIwASKPUY%3D&reserved=0>
>     Now rinse and repeat that for other server-side policies: data
>     retention, GDPR compliance, DNS filtering/blocking, TLS session
>     resumption, ECS behaviour, QNAME minimisation, NXDOMAIN rewriting,
>     query-related adware, etc, etc.
> 
>     Oh, and if some DoH server says “I do QNAME minimisation” (say),
>     does the browser or end user simply take that on trust or would they
>     somehow be expected to verify that for themselves?
> 
>  
> 
> End user typically does not trust DOH server in a untrusted network
> (e.g. public WiFi network) and may only use the DOH server provided by
> trusted network (e.g. Enterprise, Secure home networks), similar to the
> way users disable VPN connection in specific networks and enable VPN
> connection by 
> 
> default in other networks for privacy. In addition, the privacy
> extension includes a URL that points to the security assessment report
> of the DNS server by a third party auditor.
> 
>  
> 
> Cheers,
> 
> -Tiru
> 
> Information in this email including any attachments may be privileged,
> confidential and is intended exclusively for the addressee. The views
> expressed may not be official policy, but the personal views of the
> originator. If you have received it in error, please notify the sender
> by return e-mail and delete it from your system. You should not
> reproduce, distribute, store, retransmit, use or disclose its contents
> to anyone. Please note we reserve the right to monitor all e-mail
> communication through our internal and external networks. SKY and the
> SKY marks are trademarks of Sky Limited and Sky International AG and are
> used under licence.
> 
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited
> (Registration No. 2067075), Sky Subscribers Services Limited
> (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259)
> are direct or indirect subsidiaries of Sky Limited (Registration No.
> 2247735). All of the companies mentioned in this paragraph are
> incorporated in England and Wales and share the same registered office
> at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: tirumal reddy <[email-masked]>
Date: Wed, 29 May 2019 15:59:24 +0530

> notifying the end user of infection)?

If access to malicious domains is logged, logging the client IP address to
notify the user is PII, and if client IP address is logged, it is either
stored in temporary or permanent logs.

Cheers,
-Tiru

>
> *From: *Add <[email-masked]> on behalf of tirumal reddy <
> [email-masked]>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 29 May 2019 16:24:30 +0530

On Tue, 28 May 2019 at 22:06, Winfield, Alister <Alister.Winfield=
[email-masked]> wrote:

> useful to have a little historic information to see the extent of the issue
> once it’s become known.
>

DGA is just one technique, malicious domains like C&C domains can possibly
be identified by inspecting TXT records (used to send commands to the
compromised host), fast flux service network etc.

Cheers,
-Tiru

> (eg impacting say Facebook, Google, Amazon etc), operators necessarily rely
> on analytics or customers to complain. Given issues can be transient or
> periodic only a historic record can provide insight into the root cause.
>
>
>
> Alister
>
>
>
> *From: *Add <[email-masked]> on behalf of "Livingood, Jason" <
> [email-masked]>
> originator. If you have received it in error, please notify the sender by
> return e-mail and delete it from your system. You should not reproduce,
> distribute, store, retransmit, use or disclose its contents to anyone.
> Please note we reserve the right to monitor all e-mail communication
> through our internal and external networks. SKY and the SKY marks are
> trademarks of Sky Limited and Sky International AG and are used under
> licence.
>
> (Registration No. 2067075), Sky Subscribers Services Limited (Registration
> No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or
> indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the
> companies mentioned in this paragraph are incorporated in England and Wales
> and share the same registered office at Grant Way, Isleworth, Middlesex TW7
> 5QD
> --
> Add mailing list
> [email-masked]

---

From: "Winfield, Alister" <[email-masked]>
Date: Wed, 29 May 2019 11:16:27 +0000

Fair enough, I’m just stating that not all queries/responses are known as potentially bad (malware / phishing) until after the fact. That simple fact is the reason some DNS providers choose to hold logs.

Cheers
Alister

From: tirumal reddy <[email-masked]>
Date: Wednesday, 29 May 2019 at 11:54
To: "Winfield, Alister" <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] publication of DoH Resolver policies

On Tue, 28 May 2019 at 22:06, Winfield, Alister <Alister.Winfield=[email-masked]<mailto:[email-masked]>> wrote:
It would be wonderful if every malicious domain was known prior to its use, sadly except where a DGA is known that’s not the case. So it can be useful to have a little historic information to see the extent of the issue once it’s become known.

DGA is just one technique, malicious domains like C&C domains can possibly be identified by inspecting TXT records (used to send commands to the compromised host), fast flux service network etc.

Cheers,
-Tiru

Alister

From: Add <[email-masked]<mailto:[email-masked]>> on behalf of "Livingood, Jason" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 28 May 2019 at 16:43
To: tirumal reddy <[email-masked]<mailto:[email-masked]>>, Jim Reid <[email-masked]<mailto:[email-masked]>>
Cc: ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] publication of DoH Resolver policies

From: Add <[email-masked]<mailto:[email-masked]>> on behalf of tirumal reddy <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 27, 2019 at 9:12 AM
To: Jim Reid <[email-masked]<mailto:[email-masked]>>
Cc: ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] publication of DoH Resolver policies

https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-03#section-10<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-dprive-bootstrap-dns-server-03%23section-10&data=02%7C01%7CAlister.Winfield%40sky.uk%7C12d61a8dd0ee460e0ac308d6e4241425%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636947240943132005&sdata=meQxjGhaC2hZmVFpiavQeLq7XK6o83WzHghsCIyiPSY%3D&reserved=0> defines a new privacy certificate extension that identifies the privacy preserving data policy of the DNS server, it is in a machine-parsable format.

Cheers,
-Tiru

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CAlister.Winfield%40sky.uk%7C12d61a8dd0ee460e0ac308d6e4241425%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636947240943142013&sdata=qU0MLdTjX%2FmsjLEqcy8OCYsKXJRlGQLxA7e7%2B6eno1o%3D&reserved=0>
--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
--------------------------------------------------------------------

---

From: tirumal reddy <[email-masked]>
Date: Wed, 29 May 2019 18:38:50 +0530

On Wed, 29 May 2019 at 16:46, Winfield, Alister <[email-masked]>
wrote:

> Fair enough, I’m just stating that not all queries/responses are known as
> potentially bad (malware / phishing) until after the fact. That simple fact
> is the reason some DNS providers choose to hold logs.
>

Agreed, policy analysis by Sara
https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements
shows
most DNS providers clear the transaction data and do not store client IP
address.

-Tiru

>
>
> Cheers
>
> Alister
>
>
>
> *From: *tirumal reddy <[email-masked]>
> *Date: *Wednesday, 29 May 2019 at 11:54
> *To: *"Winfield, Alister" <[email-masked]>
> *Subject: *[EXTERNAL] Re: [Add] publication of DoH Resolver policies
>
>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-dprive-bootstrap-dns-server-03%23section-10&data=02%7C01%7CAlister.Winfield%40sky.uk%7C12d61a8dd0ee460e0ac308d6e4241425%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636947240943132005&sdata=meQxjGhaC2hZmVFpiavQeLq7XK6o83WzHghsCIyiPSY%3D&reserved=0>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CAlister.Winfield%40sky.uk%7C12d61a8dd0ee460e0ac308d6e4241425%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636947240943142013&sdata=qU0MLdTjX%2FmsjLEqcy8OCYsKXJRlGQLxA7e7%2B6eno1o%3D&reserved=0>
>
> *--------------------------------------------------------------------*
>
> *This email is from an external source. Please do not open attachments or
> click links from an unknown or suspicious origin. Phishing attempts can be
> reported by sending them to [email-masked] <[email-masked]> as
> attachments. Thank you*
>
> *--------------------------------------------------------------------*
>
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 29 May 2019 15:13:23 +0000

Adding to what Vittorio said, some research I have seen suggests that people's movements are much less variable that you may think - we are creatures of habit. Most people may only be on their home network, their work network, their 4G/5G network, and maybe 1 other WiFi network (e.g. coffee shop) on the average day. In situations like the coffee shop - or a random airport WiFi - they would know trust is lower and can optionally use a VPN -- or at least feel safe in the knowledge that their web transaction is likely encrypted (which is >90% of user time on the web these days IIRC).

JL

    

    Ciao,
    --

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 29 May 2019 15:17:27 +0000

> other folks are stepping up/in

I am skeptical of this. In the grand scheme of things DoH was standardized rather quickly. It takes time to be implemented in a variety of systems, and this is starting to happen now. I think rather that in this case the other folks took pre-emptive action, and this is the source of some of the tension here. In any case, the open source and commercial DNS software platforms are now adding support for DoH and DoT, which is the enabler for ISPs beginning technical trials (and eventual deployment). 

JL

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 29 May 2019 16:24:54 +0000

Today's dominant real-time ad auction systems don't appear to depend on DNS lookups at all. These ads all depend on HTTP-layer tracking like cookies and tracking pixels. Some good reading materials: https://instapage.com/blog/facebook-retargeting-pixel, https://blog.tryadhawk.com/google-adwords/how-google-adwords-works/, https://www.iab.com/wp-content/uploads/2015/06/IAB-Native-Advertising-Playbook2.pdf, https://www.iab.com/insights/user-generated-content-for-marketing-and-advertising-purposes/, https://www.iab.com/wp-content/uploads/2019/05/Full-Year-2018-IAB-Internet-Advertising-Revenue-Report.pdf

JL