Subject: [Add] lifecycle of an engagement between an application and a service

From: Joe Abley <[email-masked]>
Date: Tue, 9 Apr 2019 10:26:22 -0400

Hi all,

Vittorio and Stephen reminded me of some handwaving I inflicted on various people in the Hilton bar in Prague. Perhaps now is the time to widen the circle of injury.

Consider an end-user who wants to use some service over the Internet. I'll suggest we can consider the overall engagement between the end-user and the service in terms of a number of phases, each of which has some characteristics that are usefully different from others. My intent is to see whether we can reduce the scope of the problem from "all resolution in the world, ever" to something smaller.

For example, in the taxonomy below, I think we are mainly arguing about mechanisms within the initialisation phase. I speculate about different name resolution protocols being architecturally viable in the following established phase.

-- Initialisation Phase --

The end-user uses an application to begin a session with some service or other. Unless the addresses of the relevant service endpoints in the network are hard-coded into the application (in which case stern frowny-face) this will involve some name resolution.

For popular services today that name resolution often involves enterprise DNS services who generate responses based on a set of criteria specified by the service provider, e.g. the (city, provider) pair that the DNS provider guesses corresponds to the end-user, based on things like the EDNS(0) client-subnet option, the address of the resolver, etc. This process involves approximations and assumptions. The QNAMEs are generally generic (e.g. they are bigservice.org <http://bigservice.org/>, not user-specific-random-label.bigservice.org <http://user-specific-random-label.bigservice.org/>).

The end-user uses a resolver that has been provided as part of the process of joining the local network, or one that has been hand-configured by the end-user, or one that is specified by the vendor of the application.

The result of the resolution process is a set of one or more initial service endpoints, layer-3 addresses. The application stands up one or more transport layer sessions to those initial service endpoints. Those transport layer sessions often incorporate some end-point authentication (e.g. a bundle of TLS sessions with some appropriate certificate validation process).

The control point whereby someone (e.g. a resolver operator, an on-path network operator) can prevent the application from communicating with the service by DNS name exists within this phase. The choice of name resolution mechanism in this phase is hence contentious.

The control point whereby an on-path network operator can prevent the application from communicating with the service by layer-3 address exists within this phase. This is potentially independent of the choice of name resolution protocol or transport.

There is potential for metadata surveillance during this phase -- the fact that an application located at one address is attempting to initialise a service using a particular DNS name. This is a potential privacy concern. There is potentially a similar risk based on layer-3 address which is independent of name resolution.

-- Established Phase --

The application begins to communicate with the service end-points.

Additional name resolution may well occur during this phase since popular services are distributed, network performance and topology is dynamic and end-users are mobile. The QNAMEs involved might be user-specific and designed to trigger cache-misses (e.g. incorporating pseudo-random 64-character labels), e.g. because there is some user-specific behaviour that is incorporating the resolution process as a communications channel, or for reasons of traffic-engineering as described in the enterprise DNS commentary above, or because it's more reliable than using low TTLs, or something like that.

By the time an application's engagement with a service enters this phase, the opportunity to block the engagement has passed. The nature of the name resolution that exists within this phase is therefore potentially less contentious than in the initialisation phase. The communications channels between the application and the service endpoint have been authenticated at this point, and so to some degree the same trust that the application puts in those channels for other objects might also apply to name resolution.

As a thought experiment, perhaps a particular web service is easier to manage if all the resolution in the established phase happens inside the same HTTPS bundle that carries HTML and other objects; performance measurements executed in javascript in a browser could be shared with the service provider which could then push user-specific names to optimise service performance and that process might be architecturally cleaner and cheaper than using the more circuitous approach necessary with enterprise DNS services. The control points mentioned in the initialisation phase are unavailable in this case, but perhaps that's ok.

Even without such sophisticated resolution requirements, making the service provider directly responsible for the name resolution involved in using their service eliminates some attack vectors, e.g. the chance that some required resolution in this established phase might be hijacked by a third party as part of a phishing attack.

-- Termination Phase --

For many web services this seems like it is probably a noop, but it seems wrong not to include it by way of acknowledging that all good things must surely end.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Apr 2019 16:04:50 +0100

Hiya,

On 09/04/2019 15:26, Joe Abley wrote:
> Perhaps now is the time to widen the circle of injury.

Heh:-)

I think starting discussion that way could be useful,
thanks.

One note on your mail and one possible new "phase" below.
(Both of which I think provide arguments one could use
regardless of whatever place in this discussion one starts
from.)

The note:

> There is potential for metadata surveillance during
> this phase

I think it's more than potential:-(

But what I wanted to note was that the DNS service could
also have already been borked and might send the transport
connection to somewhere dangerous. (E.g. in the case of
a compromised home router or an unwisely user-selected DNS
service provider.)

The possible additional phase:

There's also maybe an "it's not fecking working" phase,
that could be caused by, or avoided by, by a choice of
DNS service endpoint. And the DNS server choices in place
will impact on whomever an end user might contact whilst
in that phase. Maybe "support phase" could be a name for
this?

Again, I'd emphasise that I reckon the above points
provide arguments both for those who like, or dislike, the
particular DoH-deployment that's the proximate cause for
this discussion.

Cheers,
S.

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Apr 2019 11:26:26 -0400

> I think it's more than potential:-(

Well, it's is possible that there's somewhere in the world where it's not happening as a matter of course. You never know.

> a compromised home router or an unwisely user-selected DNS

I think that's true.

The control point could be welcome intervention ("I am using OpenDNS out of choice", "I am visiting Paul Vixie's house and the company and the beer more than make up for the fact that my libertarian views on end-user freedom are being compromised") or it could be uninvited meddling (compromised CPE, on-path attack, poisoned upstream cache).

I suppose those particular examples of welcome intervention have the characteristic that if the application detects the control (e.g. DNSSEC validation failed, in some future utopia of DNSSEC deployment) the application's recourse is the same as the intended intervention, which is resolution failure. There might be others that don't line up that way, though.

Uninvited meddling might have the goal of taking you off down a dark alley so you can be relieved of private data, in which case identification of the meddling by the application might mitigate, or it might be to lie you down on the ground and give you a good kicking, by which colourful aphorism I mean denial of service, in which case DNSSEC failure is aligned with the undesired outcome.

Authentication of the service using means other than DNS (e.g. TLS certificate validation for services that use TLS) can presumably provide some mitigation of the case where DNS lies lead the application to connect somewhere it shouldn't.

> in that phase. Maybe "support phase" could be a name for

This sounds like the selection of a resolver to support the resolution that happens in the initialisation phase.

Conventionally (e.g. on my laptop, as far as I know) this is something that happens system-wide, either automatically through things like PPP or DHCP or manually-configured by an end-user or an administrator.

There were some examples from the recent shouting when it was application-specific, though. I think Paul's example was a chromekey (or something; I don't really watch television) that was hard-coded to use 8.8.8.8 regardless of user or local network preference. Other pitchforks were variously levelled at Mozilla for Firefox's currently-off-by-default use of a dedicated resolver, which is either an application-specific example or another system-wide one (considering the browser to be a system that hosts individual applications).

I suppose regardless of whether a choice is system-wide or application-specific it's still a choice that has implications for control vs. privacy in the initialisation phase.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Apr 2019 17:32:32 +0100

Hiya,

On 09/04/2019 16:26, Joe Abley wrote:
>> There's also maybe an "it's not fecking working" phase, that could
>> be caused by, or avoided by, by a choice of DNS service endpoint.
>> And the DNS server choices in place will impact on whomever an end
>> user might contact whilst in that phase. Maybe "support phase"
>> could be a name for this?
>
> This sounds like the selection of a resolver to support the
> resolution that happens in the initialisation phase.

That wasn't what I tried to describe, so maybe let me
try again.

If a user thinks they are up and running nicely with some
DNS setup (as a result of the "initialisation phase"),
then at some later time, that user might try resolve some
name that then doesn't work.

Some (perhaps short time) later, the user might then
contact someone to complain, and that is what might mark
the start of the "support phase." One reason that a putative
support phase may differ is that whomever the user contacts
might or might not have been involved with the actual DNS
setup resulting from the initialisation phase. As with all
the variables here, that (user complains to wrong place) is
something that already happens but in the context of this
discussion, it may be that whomever is contacted (be that
a web site, browser or ISP) just can't see the same problem
because of the DNS setup. On the other side of the coin,
it could be that some DNS setups might produce fewer user-
visible issues and so less support confusion/cost, and
that might be somewhat measurable.

Cheers,
S.

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 09 Apr 2019 18:36:29 +0200

Moin!

On 9 Apr 2019, at 16:26, Joe Abley wrote:
> By the time an application's engagement with a service enters this 
> phase, the opportunity to block the engagement has passed. The nature 
> of the name resolution that exists within this phase is therefore 
> potentially less contentious than in the initialisation phase. The 
> communications channels between the application and the service 
> endpoint have been authenticated at this point, and so to some degree 
> the same trust that the application puts in those channels for other 
> objects might also apply to name resolution.
Can we please stop this train of thought. We have no mechanism to 
associate that a domain is bound to a service, so the client has no idea 
if what he gets send back from the server actually belongs to that 
service and we are past the point where a service is made of one client 
server connection. It easily can be hundreds in parallel to different 
entities and even if we had a mechanism (certs, DNSSEC) to validate the 
answer send back it could be wrong for that client especially in a multi 
CDN world.

> As a thought experiment, perhaps a particular web service is easier to 
> manage if all the resolution in the established phase happens inside 
> the same HTTPS bundle that carries HTML and other objects; performance 
> measurements executed in javascript in a browser could be shared with 
> the service provider which could then push user-specific names to 
> optimise service performance and that process might be architecturally 
> cleaner and cheaper than using the more circuitous approach necessary 
> with enterprise DNS services. The control points mentioned in the 
> initialisation phase are unavailable in this case, but perhaps that's 
> ok.
So we share more data to more parties for something that already works 
today. Where is the advantage? It is way more complicated and puts way 
more stuff into the browser than just DNS, and introduces new otherwise 
unnecessary signaling. I can to see how this is architectural cleaner.

So long
-Ralf
—--
Ralf Weber

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Apr 2019 12:45:59 -0400

Hi Ralph,

On 9 Apr 2019, at 12:36, Ralf Weber <[email-masked]> wrote:

> Can we please stop this train of thought. We have no mechanism to associate that a domain is bound to a service, so the client has no idea if what he gets send back from the server actually belongs to that service and we are past the point where a service is made of one client server connection.

In that thought experiment some (non-DNS), transport-layer authentication has already happened. So that's exactly the mechanism to bind name resolution within the context of that session to a unique session cache that's populated in-band.

> It easily can be hundreds in parallel to different entities and even if we had a mechanism (certs, DNSSEC) to validate the answer send back it could be wrong for that client especially in a multi CDN world.

I think you're presupposing a particular architecture that has holes. Perhaps try to imagine one that doesn't?

> So we share more data to more parties for something that already works today.

No, we share less data with fewer parties. Instead of service providers using third-party enterprise DNS providers to generate session-specific responses based on data that's harvested from real-user monitoring across a swathe of fourth-party sites, performance monitoring, traffic steering, etc can all happen within the bounds of a service contract that is already established for the purpose of using the actual service.

But really there was a reason why I labelled these as thought experiments and separated the lifecycle into phases. You're arguing against a thought experiment in precisely the part of the whiteboard that I suggest is unimportant for the purposes of the current discussion :-)

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Apr 2019 12:55:14 -0400

> name that then doesn't work.

The phases I described were intended to be in the context of a single session between an application and a service (what I half-heartedly referred to as an "engagement" since I think the word session is a bit loaded).

The initialisation phase is the front door, with all the signposts and locks and visitor's books associated with that.

In the established phase you're shuffling between offices inside the building in a way that might well be invisible to the outside world, although maybe the building has windows that allow people to peer in.

The termination phase doesn't matter so much. Climb out of a window if you like.

Are you talking about the problem of wandering into a wall whilst inside the building? Or of finding some other building entirely?

It seems like the use of a separate resolution protocol in the established phase makes support easier. If things don't work properly while I'm using the booktweet service, I blame the booktweet service people. If you can't get booktweet to load properly, whatever that means, that feels like an Internet problem. But as I tried to say to Raph just now, the use of a different resolution protocol is intended to illlustrate the difference in sensitivities between the phases, not that the established phase can't use (e.g.) the same local resolvers as were used in the initialisation phase.

Joe

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 10 Apr 2019 07:55:21 +0200

Moin!

On 9 Apr 2019, at 18:45, Joe Abley wrote:
> In that thought experiment some (non-DNS), transport-layer 
> authentication has already happened. So that's exactly the mechanism 
> to bind name resolution within the context of that session to a unique 
> session cache that's populated in-band.
What if you are connected to an rouge authenticated actor. If you have a 
connection and do/give something that requires a new connection and then 
add domain data to it you might have successfully cached/hijacked that 
new connection.

>> It easily can be hundreds in parallel to different entities and even 
>> if we had a mechanism (certs, DNSSEC) to validate the answer send 
>> back it could be wrong for that client especially in a multi CDN 
>> world.
>
There is no such thing says the cynical me. I’ve seen so many secure 
systems being abused and hacked that I’d rather work with the devil I 
know (that of course is a very opsy position).

> No, we share less data with fewer parties. Instead of service 
> providers using third-party enterprise DNS providers to generate 
> session-specific responses based on data that's harvested from 
> real-user monitoring across a swathe of fourth-party sites, 
> performance monitoring, traffic steering, etc can all happen within 
> the bounds of a service contract that is already established for the 
> purpose of using the actual service.
I don’t know how you get that much parties, but in my good old DNS 
world the stub asks the recursive resolver which asks the authoritative 
server - with that the connection gets established.

> But really there was a reason why I labelled these as thought 
> experiments and separated the lifecycle into phases. You're arguing 
> against a thought experiment in precisely the part of the whiteboard 
> that I suggest is unimportant for the purposes of the current 
> discussion :-)
I though the topic of this list was discussing applications doing DNS 
and not some service meta discussions. I’m an old grey bearded unix 
sysadmin, so give me connections and bits on the wire (which the IETF is 
mostly about) and we can talk.

The thought experiment (or at least part of it) sounded exactly like the 
“resolver less” DNS idea we discussed in a side meeting which has 
security and other problems as described above.

So long
-Ralf
—--
Ralf Weber

---

From: Brian Dickson <[email-masked]>
Date: Tue, 9 Apr 2019 23:50:12 -0700

> add domain data to it you might have successfully cached/hijacked that
(I presume you meant "rogue", probably autocorrect error.)

You are correct. This is indeed an apparent flaw in the system described by
Joe.
Again, this presumes the rogue is the entity to which the "established"
connection
is established, after which the DNS traffic is encrypted (and trusted).

In some ways it is worse, since such a rogue would be the resolver.
No resolver poisoning would be needed, if the bad actor were the one
operating this resolver.

The flip side here is that not only have you given something (DNS queries)
to the rogue operator,
the rogue can (will) give you bad responses in return (presuming that
either the client
does not do DNSSEC validation, or that the data is not signed, or both).

The rogue would be free to be selective in the bad data (e.g. specific
FQDNs or domains), or not.
The responses could point at one or more servers, and those servers might
serve https
using self-signed certs. The success rate might not be high, but...
phishing and spam, those
don't require high success rates to achieve their goals.

> server - with that the connection gets established.

What I believe Joe meant was, the other parties (on-path parties) can no
longer see
the DNS queries/answers, since the DNS traffic is encrypted. Thus, those
parties
are no longer parties to the DNS transaction traffic. (Thus, fewer.)

> mostly about) and we can talk.

I believe Joe was breaking down the way that the DNS gets established using
TLS,
which requires unencrypted DNS queries to "bootstrap" the new DNS "channel".
(As a grey bearded unix sysadmin myself, I presume "bootstrap" is
understood. :-) )

> security and other problems as described above.

Yes.  I believe Joe was imagining an example implementation, without naming
the implementers
or distinguishing the unique aspects they might choose in how they
implement, i.e. keeping the
thought experiment as generic and as close to the "application doing DNS"
as possible.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 10 Apr 2019 00:17:20 -0700

[Much of the greatly appreciated flow has been elided by me below, to
highlight one area of concern...]

On Tue, Apr 9, 2019 at 7:26 AM Joe Abley <[email-masked]> wrote:

> Consider an end-user who wants to use some service over the Internet.
> The end-user uses an application to begin a session with some service or
> other.
> -- Established Phase --
>

The area I want to focus on here, is the distinction between arbitrary
end-users (without admin privileges), and end-users with administrative
privileges on the machine they are using.

In the former case, in the current world, the user *might* not have the
ability to select, configure, change, override, or do anything with regards
to selection of DNS resolver.
(There are a plethora of reasons why the entity who has administrator
privileges might disable user access to make these changes, such as
third-party DNS resolvers, or custom resolver configurations such as RPZ.)

In the current world, such a user might attempt to connect to some
arbitrary end-point (such as a web site), and the attempt might fail as a
result of how the DNS resolver that the user's machine is using, is
operated.

Let's presume there is a good reason for this, and that this prevents the
user from being exposed to something "bad" (for some value of "bad", such
as malware, or offensive content, or similar.)

In Joe's thought experiment, it would *appear* the user has the ability to
select the service end-point (where the service provides a replacement DNS
resolution that pre-empts the pre-existing DNS resolution as provided to
the user.)

The result is that the user has been provided the means to make changes to
DNS, *that the administrator of the machine didn't permit*. The user is now
free to use arbitrary DNS servers, whether they are trustworthy or
malicious.

The scope of the resulting injury may be limited to that single user on the
machine in question, but depending on what that injury is (e.g. malware),
the consequences may impact more than the individual user, and may impact
other machines on the local network.

There is also the issue with how user changes can be performed, such as by
modifications to configuration files.

If there is not some "special sauce" to limit how those configuration files
are able to be changed, the general presumption on multi-user systems is
that the ownership and permissions would need to allow changes by the user.

This in turn means that a malicious application would not require elevated
privileges beyond those of the user in question, to change that user's DNS
resolver, thus lowering the bar for such resolver changes.

Equally true, would be the impact of someone leaving their machine
unattended with a browser open. Even if the user were not an administrator,
the DNS choice for the user could be changed, which is a much broader and
more subtle attack than browsing to a malicious site directly.

NB: All of the above is the situation where the user does not have
administrative privileges, but enables the user to expose him/herself to
hostile resolvers and hostile content as a result, with knock-on effects.

In contrast, a user who does have administrative privileges (such as
someone who owns their own machine), would already have the ability to
change DNS resolvers, so nothing particularly new happens as a result of
these changes.
(But also, the need for the user to make those changes via the application
is a moot issue; the user can already make the change directly on their
system.)

TL; DR: the ability for a user to select an encrypted channel to a DNS
resolver, is in and of itself a privilege escalation, if the user is not a
machine administrator. And once the channel is established, control has
already been lost.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 11 Apr 2019 18:47:37 -0400

On Wed, Apr 10, 2019 at 3:17 AM Brian Dickson <[email-masked]>
wrote:

> In Joe's thought experiment, it would *appear* the user has the ability
> to select the service end-point (where the service provides a replacement
> DNS resolution that pre-empts the pre-existing DNS resolution as provided
> to the user.)
>
> DNS, *that the administrator of the machine didn't permit*.
>

I can't parse this claim.  In my vocabulary, a non-admin user is defined as
a user who can only take actions that the administrator permits.  Perhaps
you mean "that the administrator permitted unintentionally"?

The user is now free to use arbitrary DNS servers, whether they are
> trustworthy or malicious.
>
> The scope of the resulting injury may be limited to that single user on
> the machine in question, but depending on what that injury is (e.g.
> malware), the consequences may impact more than the individual user, and
> may impact other machines on the local network.
>
> If there is not some "special sauce" to limit how those configuration
> files are able to be changed, the general presumption on multi-user systems
> is that the ownership and permissions would need to allow changes by the
> user.
>

Chrome and Firefox have made clear that administrators will have the
ability to control the DoH setting, disabling or limiting non-admin users'
choice.  Perhaps this shows that they agree with you on this point, and
intend to support this use case.

> more subtle attack than browsing to a malicious site directly.

Note that most browsers have long supported proxy settings, so an attacker
with access to the browser settings can easily redirect all user traffic to
a machine of their choosing.  This is of course just one of myriad ways
that an attacker with full login access can compromise your security.  In
general, I think the IETF has done well to consider such attacks out of
scope for our work.

> machine administrator.

I disagree with this characterization.  Users who can install arbitrary
software (e.g. SSH, Windows Remote Desktop, Opera Mini) have always been
able to send DNS over such an encrypted channel.  Users who can only
install software selected by their administrator will continue to perform
DNS only in the manner permitted by their administrator.

There's nothing new here.

> And once the channel is established, control has already been lost.
>
> Brian
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 11 Apr 2019 17:14:37 -0700

On Thu, Apr 11, 2019 at 3:47 PM Ben Schwartz <[email-masked]> wrote:

>
>
> On Wed, Apr 10, 2019 at 3:17 AM Brian Dickson <
> [email-masked]> wrote:
>
>>
>> The result is that the user has been provided the means to make changes
>> to DNS, *that the administrator of the machine didn't permit*.
>>
>
> I can't parse this claim.  In my vocabulary, a non-admin user is defined
> as a user who can only take actions that the administrator permits.
> Perhaps you mean "that the administrator permitted unintentionally"?
>

Not really.
The distinction I'm trying to make is the following:

   - Assume the administrator installs the browser as the administrator has
   always installed the browser, with the defaults unchanged. (Pretty common,
   IMHO.)
   - Assume that the {network,system} administrator(s) use DNS as a control
   point, including limiting access to outside DNS resolvers. (Also fairly
   common.)
   - If the software, in its default configuration, enables the user to
   select arbitrary HTTPS servers for DNS resolution, this is user-level
   configuration which has the effect of overriding system-level (and locked)
   configurations. (This is what is proposed, and even ships in Firefox if you
   visit 'about:config'.)
   - So, while technically true that it falls into "permitted
   unintentionally", that puts the blame on the victim, in this case the
   administrator.

For example, the administrator may be very familiar with DNS, and may not
be familiar with changes to an application's capabilities or defaults.

E.g. From a security/interface perspective, consider that currently the
configuration elements do NOT actually contain a name component called
'DNS'.
Unless I had been closely following a bunch of mailing lists and reading
release notes, I would not know to look for 'trr' as the component
affecting DNS.
I also would not have been able to find it by looking at the stock user
preferences, as only non-default preferences are saved; I literally had to
use 'strings' in the binary, or read the source, to determine the variables.

>> There is also the issue with how user changes can be performed, such as
>> by modifications to configuration files.
>>

That may be true, but does not change the fact that in the stock
configuration, non-privileged users will have access (and already have
access!!!) to this capability, i.e. to over-ride DNS resolver choice.

The other problem with this is that, if the administrators fail to make
such a configuration change, the only way to DETECT their error is by
looking for the mistake, ON THE SPECIFIC HOST.
The encrypted transport over port 443 is the secondary issue, or maybe
primary issue.
Yes, the administrator can fix the issue, IF they know about it. But, their
existing tool set will not alert them to the error.
This also means BYOD is dead.

It isn't so much a question of whether the administrators can disable a
feature, it is whether it is on-by-default (or even simple enabled for use)
on a system where there are unprivileged users.

On a machine owned by the (only) user, an off-by-default configuration
isn't a significant roadblock. Alternatively, different builds based on
single-user systems (installed in user's home directory) versus multi-user
systems (installed centrally) may be sufficient to address the concern. I
would like to see a commitment to do that, however.

> general, I think the IETF has done well to consider such attacks out of

You're mixing apples and oranges, by combining the DNS semantics with the
HTTP semantics.

Currently, DNS is, in many enterprise settings, a critical component of
both monitoring and mitigating a variety of security issues (mostly
malware, but also data exfiltration).

Suggesting that, because this new DNS stuff happens in the browser, that it
shouldn't be treated as a DNS issue, will probably raise the ire of folks
in the security, DNS, enterprise, and anti-malware spaces.

It doesn't matter what other things have already been possible, IMHO, what
matters is the new things that are enabled. The bypassing of existing
INTERNAL DNS controls, in an enterprise environment, is a HUGE deal, and
one reason lots of folks are interested in discussing both the problem
spaces and potential solution spaces.

DNS complements other stuff that browsers do, in protecting users; the
phrase "belt and suspenders" is an appropriate analogy.

Making changes that don't provide equivalent enterprise-level controls over
user DNS configuration limitations, (and specifically in the shipped
default settings), is akin to removing either the belt or suspenders. It
means that there is now only one element preventing one's pants from being
located at one's ankles. (Use of a disturbing visual in the analogy is
deliberate. :-) )

>> (But also, the need for the user to make those changes via the
>> application is a moot issue; the user can already make the change directly
>> on their system.)
>>
> I disagree with this characterization.
>
[snip]

> Users who can only install software selected by their administrator will
> continue to perform DNS only in the manner permitted by their administrator.
>

Currently, there is no "in the manner". Use of the passive voice obscures
the change, unfortunately.
It is a change compared to the current DNS environment, demonstrably:

   - DNS is configured only by the administrator, either through a system
   configuration mechanism local to the system, or handled via DHCP (but not
   capable of being altered by a non-admin user).

What HAS changed (or more precisely, "will have changed") is that a DEFAULT
configuration of a browser (I say default, as this is what the existing
builds are configured to enable, and public statements by the browser
vendors support this as the intended configuration), WILL enable user
bypass of DNS resolver choice which had previously been configured by the
administrator.

Enabling this change of mode SHOULD require an active configuration by the
administrator, and NOT be the consequence of inaction. Currently, the
proposed scenario is the latter.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 12 Apr 2019 17:34:59 -0400

On Thu, Apr 11, 2019 at 8:14 PM Brian Dickson <[email-masked]>
wrote:

>    - Assume the administrator installs the browser as the administrator
>    has always installed the browser, with the defaults unchanged. (Pretty
>    common, IMHO.)
>    - Assume that the {network,system} administrator(s) use DNS as a
>    control point, including limiting access to outside DNS resolvers. (Also
>    fairly common.)

Thanks for helping me understand.  I agree: this new feature does represent
a change that requires the attention of administrators who are in the
position you describe, and browser vendors should make sure to made admins
aware of the new feature as it becomes available.  In the case of Firefox,
they made a clear public announcement in May 2018:
https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/,
with several followup announcements over a period of many months before the
feature reached stable.  They even made a cartoon, for those unfamiliar
with DNS:
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/.  In
my view, their communication on the topic has been exceptionally good.

Modern browsers make similarly significant changes on a regular basis, and
these changes are communicated to administrators, who must remain up to
date with changes in the applications they allow.  For example, last month
Firefox announced that they would change their default root certificate
store on Windows, which likely has implications for many system
administrators.  Over the past few years, browsers have introduced
countless transformational new features with significant implications for
enterprise IT: audio/video capture, new extension systems, tighter TLS
requirements, etc.

> use 'strings' in the binary, or read the source, to determine the variables.

Firefox has a huge number of about:config options, including many that are
likely to interfere with enterprise IT administration.  I'm not an expert
on Firefox configuration, but admins who needed this level of control
should probably already have blocked user access to the about:config flags:
https://github.com/mozilla/policy-templates#blockaboutconfig.  There's no
need to enumerate precisely which options are relevant.

> on a system where there are unprivileged users.

In my view, this is a question that can be settled entirely between the
browser vendors and their enterprise customers.  Browser vendors are well
aware of their customers' needs, and are always trying to keep those
customers happy.

>> This in turn means that a malicious application would not require
>>> elevated privileges beyond those of the user in question, to change that
>>> user's DNS resolver, thus lowering the bar for such resolver changes.
>>>
>> Note that most browsers have long supported proxy settings, so an
>> attacker with access to the browser settings can easily redirect all user
>> traffic to a machine of their choosing.  This is of course just one of
>> myriad ways that an attacker with full login access can compromise your
>> security.  In general, I think the IETF has done well to consider such
>> attacks out of scope for our work.
>>
>
> Suggesting that, because this new DNS stuff happens in the browser, that
> it shouldn't be treated as a DNS issue, will probably raise the ire of
> folks in the security, DNS, enterprise, and anti-malware spaces.
>

I bring up proxy settings specifically because it is a pre-existing browser
feature that already bypasses such internal DNS controls entirely, so the
attack you described has already been possible in most browsers from the
past 10+ years.  It's not new.

> Making changes that don't provide equivalent enterprise-level controls
> over user DNS configuration limitations, (and specifically in the shipped
> I agree that many IT admins may think this is what they have required, but
I disagree that it is a good characterization of a typical enterprise
network.  For example, I can easily spin up an Amazon WorkSpaces VM, access
it graphically from my browser, and then open a browser in that VM.  Now I
have access to all the world's services without leaving a DNS trace in the
enterprise network.

> What HAS changed (or more precisely, "will have changed") is that a
> DEFAULT configuration of a browser (I say default, as this is what the
> existing builds are configured to enable, and public statements by the
> browser vendors support this as the intended configuration), WILL enable
> user bypass of DNS resolver choice which had previously been configured by
> the administrator.
>

Thanks for helping me understand this concept.  Change is always
challenging.  Sitting in the status quo forever is not an option, but
change for change's sake isn't helpful either.  Maybe we can find a balance.

Brian

---

From: Joe Abley <[email-masked]>
Date: Wed, 17 Apr 2019 12:28:46 -0400

On 10 Apr 2019, at 01:55, Ralf Weber <[email-masked]> wrote:

> What if you are connected to an rouge authenticated actor. If you have a connection and do/give something that requires a new connection and then add domain data to it you might have successfully cached/hijacked that new connection.

We should certainly not pretend that there isn't a risk analysis to be done, but on the flip side assuming that because risks exists that we must be at a dead end seems like a recipe for getting nowhere. There are and will always be risks.

> There is no such thing says the cynical me. I’ve seen so many secure systems being abused and hacked that I’d rather work with the devil I know (that of course is a very opsy position).
> 
> I don’t know how you get that much parties, but in my good old DNS world the stub asks the recursive resolver which asks the authoritative server - with that the connection gets established.

The response generated by the authority server involves an algorithm that combines inferences about the query, the resolver that sent it, the stub resolver that originated it, and the performance of thousands of representative CDN tests in other protocols that seem relevant that are collected, analysed, bought and sold by a thrilling community of third parties in many different jurisdictions.

> I though the topic of this list was discussing applications doing DNS and not some service meta discussions. I’m an old grey bearded unix sysadmin, so give me connections and bits on the wire (which the IETF is mostly about) and we can talk.

The point I was trying to make (apparently not very well) is that there are parts of the interaction between an application and a service that can be improved if we open our minds to application-specific name resolution, and that it might be reasonable to look for solutions that could improve performance, reduce complexity, reduce privacy threats, all without diminishing control to a point that is intolerable.

> The thought experiment (or at least part of it) sounded exactly like the “resolver less” DNS idea we discussed in a side meeting which has security and other problems as described above.

Yes. However, that side meeting bundled all name resolution into one bucket. My point is that if we are able to separate the aggregated resolution problem we may well find that there are components that are soluble. The alternative, as I think we have all noticed, is that there's at least one perspective that makes any solution untenable.

Joe