Subject: [Resolverless-dns] Paper on Resolver-less DNS

From: Erik Sy <[email-masked]>
Date: Tue, 13 Aug 2019 14:07:35 +0200

Hi all,

I wrote a paper to clarify the design of resolver-less DNS and to
investigate its feasibility.
You can find the paper here:
https://svs.informatik.uni-hamburg.de/publications/2019/2019-08-13-Sy-preprint-Enhanced_Performance_and_Privacy_via_Resolver-Less_DNS.pdf

In total, I think this is a great performance-optimization especially
for clients on high-latency access networks. Furthermore, it can improve
the client's privacy posture towards the recursive DNS resolver.

Best regards,
Erik

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 14 Aug 2019 17:11:22 -0400

Thanks for conducting this investigation, Erik!

In my view, the two main concerns with resolverless architectures have been
(1) simplifying stolen key attacks and (2) potential interference with
DNS-based load balancing.

Currently, an attacker who has stolen a TLS private key also needs control
of the victim's network in order to mount an impersonation attack.
Resolverless DNS (especially without DNSSEC, as in your model) might make
these attacks much easier to execute, by sending the victim a DNS record
that points the compromised domain to the attacker's IP address.

Domains that rely on DNS-based load balancing have concerns about third
parties handing out DNS records for their domains.  These third parties
might (accidentally) provide the same DNS record to all of their users,
overloading a particular server instead of spreading the load across many
servers.

If you're interested in this topic, I hope you'll think a bit about these
problems, and see if you find a way to solve them.

On Tue, Aug 13, 2019 at 8:07 AM Erik Sy <[email-masked]>
wrote:

> --
> Resolverless-dns mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>

---

From: Erik Sy <[email-masked]>
Date: Thu, 15 Aug 2019 12:43:19 +0200

Thank you for your feedback, Ben!

On 8/14/19 23:11, Ben Schwartz wrote:
> In my view, the two main concerns with resolverless architectures have
> been (1) simplifying stolen key attacks and (2) potential interference
> with DNS-based load balancing.
>
> Currently, an attacker who has stolen a TLS private key also needs
> control of the victim's network in order to mount an impersonation
> attack.  Resolverless DNS (especially without DNSSEC, as in your
> model) might make these attacks much easier to execute, by sending the
> victim a DNS record that points the compromised domain to the
> attacker's IP address.
>
The described attack of a compromised TLS private key or even a broken
PKI is quite strong. Certainly, it is not a design goal of DNS to
mitigate these attacks. However, let's assume that this attack is
relevant. In the traditional DNS as well as in the server-less DNS
network paths involving the HTTPS server (victim) and the corresponding
authoritative nameserver are vulnerable to such an impersonation attack
as shown in this figure
(https://erik-sy.de/Resolver-less_DNS_Attack.pdf). Resolver-less DNS
replaces only the vulnerable paths involving the resolver with the paths
involving the HTTP server providing the DNS records. In my view, none of
these DNS designs protects against the described impersonation attacks
and the attack surface remains substantially the same across these designs.

> Domains that rely on DNS-based load balancing have concerns about
> third parties handing out DNS records for their domains.  These third
> parties might (accidentally) provide the same DNS record to all of
> their users, overloading a particular server instead of spreading the
> load across many servers.

I think, that this is not a new problem introduced by the resolver-less
DNS design. Moreover, it describes a general drawback of DNS-based load
balancing that one is dependent on 'unreliable' third parties to spread
the load. For example, it is known that some resolvers ignore small TTLs
of their cached DNS records impacting this load balancing mechanism.

Is anybody interested in co-authoring an ID on resolver-less DNS?

Best regards,
Erik 

> If you're interested in this topic, I hope you'll think a bit about
> these problems, and see if you find a way to solve them.
>
> On Tue, Aug 13, 2019 at 8:07 AM Erik Sy <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     [email-masked] <mailto:[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2019 12:39:38 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-

I also like the paper but it misses the largest concern with
resolverless DNS: it circumvents DNS based access controls.  I realize
this is not a popular position in the IETF, but there are lots of
perfectly good reasons that networks provide filtered DNS.  Even
though it has usually been technically easy to circumvent, most people
don't and it's been good enough.  If it's widely circumvented, we can
expect much more intrusive filtering with a lot more collateral damage.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Thu, 15 Aug 2019 12:54:01 -0400

Hi John,

On 15 Aug 2019, at 12:39, John Levine <[email-masked]> wrote:

> resolverless DNS: it circumvents DNS based access controls.

This is an area where applicability is important, I think. I suggested splitting the problem space once before into phases (the message I sent seems not to be in the add list archive, so no link, but copy below). In that crude taxonomy, DNS-based access control seems applicable to the initialisation phase but not so much to the established phase.

If we can assume for the sake of this topic that there is a security model that makes sense that constrains what DNS data could be exchanged between server and client within an HTTPS bundle, and if access control was already exercised during the initialisation phase, perhaps it's not needed in the established phase. In that case, in that phase, resolverless DNS might be a perfectly reasonable and uncontentious choice.

Joe

> Begin forwarded message:
> 
> From: Joe Abley <[email-masked]>
> Subject: lifecycle of an engagement between an application and a service
> Date: 9 April 2019 at 10:26:22 EDT
> To: [email-masked]
> 
> 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: Ted Hardie <[email-masked]>
Date: Thu, 15 Aug 2019 10:57:42 -0700

Howdy John,

On Thu, Aug 15, 2019 at 9:39 AM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> been
> perfectly good reasons that networks provide filtered DNS.

I think it is important to distinguish between networks providing filtering
DNS and networks requiring use of their DNS filters.  As far as I can tell,
no one seems to object to providing filtered DNS either in a local
resolver, in a pass-through to an off-premises service, or as a local
configuration to the off-premises service.   The tussle seems to be instead
of whether passing through that control surface is mandatory for clients.

We all seem to realize that it was never mandatory for the sophisticated
user (/etc/hosts and its friends are a thing, as you imply below), but
folks are concerned that if it should become widely available that the
situation would change in some deleterious way.  Among those posited are:

* new opportunities for circumvention for malware
* increased likelihood for inappropriate exposure to distressing content
(whether for adults or children)
* new risks for regulatory or common imposition of other control surfaces

There is a further assumption that these risk go up as the level of
sophistication for circumvention goes down.  I think many of these are
predicated on an assumption that the non-local DNS has no filters, which I
do not believe has been that well demonstrated; certainly many off-premise
services are there specifically to filter for the customers who configure
their services.  But that filtering highlights the other risks:

* new opportunity for a malicious configured service to provide false data
to non-DNSSEC validating hosts or applications.
* no opportunities for external services to provide access to split-DNS
internal data.

 From my perspective, the push-based DNS record approach is most risky for
this latter set of risks.  The document currently says:

First, clients are only allowed to send application data over an
> established connection if they validated the server’s identity via a
> server authentication mechanism or a fallback DNS lookup. Figure 2
> presents the validation strategy applied by user agents on DNS records retrieved
> via resolver-less DNS
>

I can't reproduce the diagram here, but my reading is that you can use this
DNS data if you have cached TLS resumption ticket or equivalent; in that
case, you can start the 0-RTT exchange knowing the other side will be able
to see the application data only if they have the right cryptographic
materials.  This misses the risk that establishing a connection may leak
private information*.  It also create a new, fun dependency in the already
confusing interaction of cache lifetimes.  The DoH style method creates an
interdependence between DNS TTL and HTTP cache lifetimes; this creates one
with the ticket lifetime.  RFC 5077 says this:

   A client SHOULD delete the ticket and associated state when the time expires.
   It MAY delete the ticket earlier based on local policy.  A server MAY
   treat a ticket as valid for a shorter or longer period of time than
   what is stated in the ticket_lifetime_hint.

If you know a server sets 0 or a long lifetime, in other words, you may be
able to guess that a session ticket is available, but otherwise it is a
crapshoot either for the benign DNS-record supplying host or an attacker.

Given the large number of cases that will have to follow fallback DNS
lookup for the authentication, I think this a useful building block only
for very popular services (since they are likely to be in the cache).
Given the other resources they have and the reputational risk of allowing
random sites to provide DNS records related to them, I'm not yet sure that
this is worth it.

Ted

*Imagine you are a government which wishes to detect when citizens use
GRINDR, as you disapprove of same sex encounters.  You can have government
and affiliated sites push GRINDR DNS records using this method; when
someone with a fresh TLS ticket for GRINDR tries to connect, you get their
IP address and whatever other data leaked in the exchange.  You can limit
this risk in various ways (e.g. by requiring the presented TLS certificate
of the DNS-record supplying host have the domain in its list of alternative
names), but this limits the effectiveness of this method and also runs the
risk that governments may have root certificates that can generate those.

Even

---

From: Erik Sy <[email-masked]>
Date: Thu, 15 Aug 2019 21:00:31 +0200

Hi John,

> resolverless DNS: it circumvents DNS based access controls.

Resolver-less DNS does not circumvent DNS-based access controls. First,
clients can configure their user agent to filter the DNS records
retrieved via resolver-less DNS to enforce such access controls. Second,
resolver-less DNS requires in some situations fallback DNS queries using
the traditional resolver that may conduct DNS-based access controls.

Erik

---

From: "John R Levine" <[email-masked]>
Date: 15 Aug 2019 15:09:15 -0400

I think I've seen rants that any interference with true DNS is evil (add 
DNSSEC to suit) but I think we can agree they're in the weeds.

> [ possible badness ] are:
>

Not just distressing.  A lot of networks are inside organizations, and 
they have policy reasons to limit what things their employees can see, 
e.g., porn and gambling, or perhaps competitor's web sites if there's a 
risk of anti-competive collusion.  I've seen networks that force all 
outgoing port 53 traffic to their own resolver to more or less 
transparently enforce the policy.

> predicated on an assumption that the non-local DNS has no filters, ...

Not at all, it's that the non-local DNS doesn't have the policy filters 
that the local DNS does.

> * no opportunities for external services to provide access to split-DNS

That, too.  But the key point is that many networks do policy filtering 
and other people's DNS is unlikely to implement the same policy.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Aug 2019 19:22:16 +0000

On Thursday, 15 August 2019 19:00:31 UTC Erik Sy wrote:
> retrieved via resolver-less DNS to enforce such access controls.

how? right now network operators use DNS RPZ, implemented in their recursive 
name servers, to achieve multivendor threat intelligence based policy 
enforcement at the DNS level. i know of no similar protocol by which browsers 
could learn the network operator's policy. and in any case some of the policy 
rules expressed in RPZ are about name server names and name server addresses, 
neither of which a browser will know.

so, this _does_ circumvent, as written, and i suspect, by (poltiical) intent.

> Second,

that's small beer, irrelevant to the thread.

-- 
Paul

---

From: Eric Orth <[email-masked]>
Date: Thu, 15 Aug 2019 16:13:30 -0400

>From the Chrome perspective, this is a concern I partly share.  I'm mostly
ignoring here the circumvention and forced-filtering issues of whether or
not the network should be able to mandate filtering/manipulation or whether
or not clients should be forced to comply with such things because that
issue is being debated enough over in the ADD mailing list.

But if Chrome is using a particular filtering DNS server, especially if
that server has been explicitly selected by the user or someone with
authority over the user's device, seems like it would result in a bad user
experience if we then bypassed that filtering by retrieving results outside
the DNS server.  My initial thinking is that we would then ideally only use
resolverless DNS if we had knowledge that the in-use recursive resolver is
not doing significant filtering.  But such a signal does not currently
generally exist, so would we be limited to only doing resolverless DNS when
the resolver is on a hardcoded list of non-filtering resolvers?

---

From: Erik Sy <[email-masked]>
Date: Thu, 15 Aug 2019 22:25:23 +0200

Hi Ted,

On 8/15/19 19:57, Ted Hardie wrote:
>  From my perspective, the push-based DNS record approach is most risky
> for this latter set of risks.  The document currently says:
>
>     established connection ifthey validated the server’s identity via
>     a server authentication mechanism or a fallback DNS lookup. Figure
>     2 presents the validation strategy applied by user agents on DNS
>     records retrieved via resolver-less DNS
>
>
> I can't reproduce the diagram here, but my reading is that you can use
> this DNS data if you have cached TLS resumption ticket or equivalent;
> in that case, you can start the 0-RTT exchange knowing the other side
> will be able to see the application data only if they have the right
> cryptographic materials.  This misses the risk that establishing a
> connection may leak private information*.

The problem you are describing is not introduced by resolver-less DNS. A
traditional DNS resolver can conduct the exact same attack by
distributing fake DNS records and observe the client's connection
establishment.

>   It also create a new, fun dependency in the already confusing
> interaction of cache lifetimes.  The DoH style method creates an
> interdependence between DNS TTL and HTTP cache lifetimes; this creates
> one with the ticket lifetime.

I feel like you possibly misunderstood the validation strategy. I
proposed an opportunistic approach, where the client always attempts a
connection establishments towards the IP address retrieved via
resolver-less DNS. Subsequently, if the connection does not provide
server authentication, the client evaluates a fallback DNS record
retrieved via the traditional DNS. Thus, I do not understand why an
interdependence with the ticket lifetime is created.

Erik 

>   RFC 5077 says this:
> If you know a server sets 0 or a long lifetime, in other words, you
> may be able to guess that a session ticket is available, but otherwise
> it is a crapshoot either for the benign DNS-record supplying host or
> an attacker. 
>
> lookup for the authentication, I think this a useful building block
> only for very popular services (since they are likely to be in the
> cache).  Given the other resources they have and the reputational risk
> of allowing random sites to provide DNS records related to them, I'm
> not yet sure that this is worth it.
>
> Ted
>
> GRINDR, as you disapprove of same sex encounters.  You can have
> government  and affiliated sites push GRINDR DNS records using this
> method; when someone with a fresh TLS ticket for GRINDR tries to
> connect, you get their IP address and whatever other data leaked in
> the exchange.  You can limit this risk in various ways (e.g. by
> requiring the presented TLS certificate of the DNS-record supplying
> host have the domain in its list of alternative names), but this
> limits the effectiveness of this method and also runs the risk that
> governments may have root certificates that can generate those.
>
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Aug 2019 14:03:17 -0700

Hi Erik,

Thanks for your reply.

> distributing fake DNS records and observe the client's connection
Agreed, but your proposal appears as written to allow any web server to try
the attack, where it was formerly limited to a configured resolver.  Unless
I misunderstand the proposal, that a significant change in attack surface.

> resolver-less DNS.

You're right, I misread it.  I thought you were saying that the client
should try only in the case where it had the TLS resumption ticket and
should fall back *before attempting the resolution* otherwise.  You may
want to update the text pointing to Figure 2 or Figure 2 to make that
clearer.

> Subsequently, if the connection does not provide
> retrieved via the traditional DNS.

This seems to indicate that the attack I mentioned earlier is much easier
to mount as both tracks in Figure 2 allow it.  It also raises the risk that
a client will receive a server authentication from a CA not intended by the
domain owner (our friend the enterprise, an attacker, a government, etc.).
We have some mitigations for that, but they are not complete.

Unless you somehow limit the number of domains a web server can provide DNS
records for in some way that approximately matches their own URL authority,
this seems fairly risky to me.   You can eliminate the risk for a DNSSEC
validating application if the DNS records allow the validation to occur.
But that is not, at least yet, common.

regards,

Ted

Thus, I do not understand why an

---

From: Fred Baker <[email-masked]>
Date: Thu, 15 Aug 2019 15:01:24 -0700

One thing I would want to be certain of is that the host did DNSSEC validation. It’s the only way I know of to verify the validity of the RR.

Sent using a machine that autocorrects in interesting ways...

> On Aug 15, 2019, at 1:13 PM, Eric Orth <ericorth=[email-masked]> wrote:
> 
> 
> From the Chrome perspective, this is a concern I partly share.  I'm mostly ignoring here the circumvention and forced-filtering issues of whether or not the network should be able to mandate filtering/manipulation or whether or not clients should be forced to comply with such things because that issue is being debated enough over in the ADD mailing list.
> 
> But if Chrome is using a particular filtering DNS server, especially if that server has been explicitly selected by the user or someone with authority over the user's device, seems like it would result in a bad user experience if we then bypassed that filtering by retrieving results outside the DNS server.  My initial thinking is that we would then ideally only use resolverless DNS if we had knowledge that the in-use recursive resolver is not doing significant filtering.  But such a signal does not currently generally exist, so would we be limited to only doing resolverless DNS when the resolver is on a hardcoded list of non-filtering resolvers?
> --

---

From: Joe Abley <[email-masked]>
Date: Thu, 15 Aug 2019 18:11:02 -0400

> One thing I would want to be certain of is that the host did DNSSEC validation. It’s the only way I know of to verify the validity of the RR.

In the case of a client doing resolverless DNS with a server, presumably it has already

 - looked up the name using a resolver
 - established a TCP connection
 - completed a TLS handshake with some degree of certificate validation
 - potentially supplied acceptable credentials for HTTP authentication, if the server needs them

before it is in a position to do name resolution within the resulting HTTPS bundle. What is the reasoning to require that additional precautions be taken at this point, compared to the conventional behaviour where the client continues to get fake results from the cache of the poisoned resolver?

I agree the DNSSEC validation at the client would be nice to see, but I think that's a more general statement than one that is specific to this case.

Joe

---

From: "John R Levine" <[email-masked]>
Date: 15 Aug 2019 18:21:39 -0400

On Thu, 15 Aug 2019, Eric Orth wrote:
> My initial thinking is that we would then ideally only use

It's hard to imagine how you could get such a signal in a way that would 
be useful.  Who's going to publish "yeah, sure, bypass me, I don't care"?

There are heuristics like looking to see if it's one of the popular 
n.n.n.n public resolvers, but I wouldn't want to push it too far.

Regards,

---

From: Eric Orth <[email-masked]>
Date: Thu, 15 Aug 2019 19:07:04 -0400

> be useful.  Who's going to publish "yeah, sure, bypass me, I don't care"?

I imagine most resolvers if they don't do any filtering or other
manipulations won't care if they're bypassed by a well-designed
resolverless DNS system.  The problem is that most of them probably don't
care enough to add a signal about it.

> n.n.n.n public resolvers, but I wouldn't want to push it too far.

Essentially the "hardcoded list of non-filtering resolvers" I mentioned.
Maybe such methods are enough to get reasonable use of resolverless-DNS,
but I hope somebody can think of a way to do better.

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2019 23:53:37 -0400

This strikes me as rather overoptimistic.  Sure, a sophisticated user
can set up her DNS configuration do all sorts of stuff.  But until
now, the other 99.99% of normal users just use whatever DNS
configuration their system gives them.  They don't know what DNS is,
and if a browser or other application does resolverless DNS, they
don't understand the implications or how to turn it off.

If the browser pops up a permission window, it says:

  blah blah security parp parp DNS bloop bloop
  extremely dangerous gargle gargle safety?

so they'll click OK to make it go away.

R's,
John

---

From: Erik Sy <[email-masked]>
Date: Fri, 16 Aug 2019 09:27:40 +0200

Hi Ted,

On 8/15/19 23:03, Ted Hardie wrote:
>
> Agreed, but your proposal appears as written to allow any web server
> to try the attack, where it was formerly limited to a configured
> resolver.  Unless I misunderstand the proposal, that a significant
> change in attack surface.
Ok, we can include this into the privacy discussion of resolver-less
DNS. In detail, an adversary providing tampered DNS records for a
specific hostname can possibly learn that the user agent had established
a connection to this hostname in the past. A successful attack requires
the user agent to posses valid state of that prior connection allowing
an abbreviated connection establishment such as QUIC source address
tokens or TLS session resumption tickets.
>  
>  It also raises the risk that a client will receive a server
> authentication from a CA not intended by the domain owner (our friend
> the enterprise, an attacker, a government, etc.).  We have some
> mitigations for that, but they are not complete.

The problem you are describing is not introduced by resolver-less DNS.
The fact that the client may receive a server authentication from a CA
not intended by the domain owner applies also to the traditional DNS. As
mentioned earlier, I think attacks assuming a broken PKI cannot be
effectively mitigated by DNS.

Erik

>
> Unless you somehow limit the number of domains a web server can
> provide DNS records for in some way that approximately matches their
> own URL authority, this seems fairly risky to me.   You can eliminate
> the risk for a DNSSEC validating application if the DNS records allow
> the validation to occur.   But that is not, at least yet, common.
>
> regards,
>
> Ted
>
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 08:46:32 -0400

On Aug 16, 2019, at 03:28, Erik Sy <[email-masked]> wrote:
> 
> I think attacks assuming a broken PKI cannot be

DNSSEC +TLSA doesn’t work?

---

From: Erik Sy <[email-masked]>
Date: Fri, 16 Aug 2019 15:36:03 +0200

> DNSSEC +TLSA doesn’t work?
Looking at the deployment issues of DNSSEC [1] and TLSA [2], I think
DNSSEC+TLSA do not solve the broken PKI problem on the web. Furthermore,
I'm not aware of any user agent enforcing a strict validation of
DNSSEC+TLSA, which would be necessary to mitigate the described attacks.

1:
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-chung.pdf

2: https://link.springer.com/chapter/10.1007/978-3-319-17172-2_15

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 10:39:52 -0400

Both of those papers talk about incompetence of operation, not about technical weaknesses. Competently operated DNSSEC will not have the problems these two papers describe. Are you aware of any technical problem with using TLSA to prevent PKI attacks, or is this just FUD?

Sent from my iPhone

> On Aug 16, 2019, at 09:36, Erik Sy <[email-masked]> wrote:
> 
>

---

From: Steffen Nurpmeso <[email-masked]>
Date: Fri, 16 Aug 2019 17:25:32 +0200

Ted Lemon wrote in <[email-masked]>:
 |Both of those papers talk about incompetence of operation, not about \
 |technical weaknesses. Competently operated DNSSEC will not have the \
 |problems these two papers describe. Are you aware of any technical \
 |problem with using TLSA to prevent PKI attacks, or is this just FUD?

Competence does not help if governments or companies enforce some
policy.  If they are willing to channel data and require
installation of a certificate in your CA pool, then the best you
can get is increased effort on their side, by introducing a shadow
DNS topology, unless i am mistaken.

I do not understand, and never (~18 years) did, why the complexity
of DNS is increased so much; instead of moving over to secure
transport that is.  And if you want to sign data bundles, then
those keys could also be used, they have the potential for it, do
they.  Repeatedly connect up to the root domain of your URL in
question, and collect certificates along the way, unless you have
the complete chain, which you can cache locally.  Especially if
you now even pump the data as such over an already open HTTP
channel.  But in general this looked to me the much more elegant
resolution (once i looked at DNSSEC and TSIG and said "no
(hopefully not)").  And much easier to implement, and by using
facilities of libraries which see many eyes.  And keeping the core
protocol clean.

What do you win more than (possibly) increased complexity on the
door through the wall?  But "leaving lonely people fight in dark
side streets as opposed to perceptable noise when someone enforces
entries in local CA pools"?
Just my one cent.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Aug 2019 15:35:47 +0000

On Friday, 16 August 2019 15:25:32 UTC Steffen Nurpmeso wrote:
> ...
> transport that is.

DNS over TLS (note, this is not the same as DNS over HTTPS) is such a 
transport. however, transport security doesn't assure data authenticity. 
therefore the another complexity (DNSSEC) was added first. and, neither of 
these protocols can be used to express permission, so another complexity 
(TSIG) was added before either of the others.

> And if you want to sign data bundles, then
> they.

no. both for reasons of caching and reasons of policy and monitoring, most DNS 
transactions are bounced through relays called "full resolvers". if you try to 
design these out, your system will lose vital properties compared to DNS 
itself.

> Repeatedly connect up to the root domain of your URL in

the losses from this approach would be, as stated above, vital.

the web isn't by far the only app running on the internet, and while it will 
grow, the internet is larger will grow faster.

-- 
Paul

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Aug 2019 08:50:41 -0700

Howdy,

> tokens or TLS session resumption tickets.

Yes, this is true, but I thought you asserted that it would
opportunistically attempt to use the provided records.  That means it could
also leak the interest of the client in a specific resource to a
potentially malign collector at the instigation of any web site providing
the malign DNS record; that's the increase in attack surface for the
existing attack.  At the very least, that appears to require clients to
cache where DNS records came from in their cache, so that they can build a
reputation for sources that supplied bad data and ignore data from sources
that gave bad data.  That's a far from perfect mitigation, of course, but
it helps some.

> The problem you are describing is not introduced by resolver-less DNS.

Agreed, but it also can't be ignored that the new source of supplied DNS
records gives a new opportunity to line up the facilities needed for a
successful attack.

regards,

Ted

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 11:54:10 -0400

DNSSEC lets you check that the cert you have been offered is for a key that the site actually uses. Of course DNSSEC can be blocked, but it can’t be blocked undetectably.  So with DNSSEC you can at least know that you are under attack and decide whether to proceed. 

It’s also true that sometimes state actors openly break PKI, and that we can’t do anything about that systemically. But when state actors or others secretly break PKI, having a way to detect that is very beneficial. 

Sent from my iPhone

> On Aug 16, 2019, at 11:25, Steffen Nurpmeso <[email-masked]> wrote:
>

---

From: Erik Sy <[email-masked]>
Date: Fri, 16 Aug 2019 20:40:43 +0200

Hi Ted,

On 8/16/19 17:50, Ted Hardie wrote:
> opportunistically attempt to use the provided records.  That means it
> could also leak the interest of the client in a specific resource to a
> potentially malign collector at the instigation of any web site
> providing the malign DNS record; that's the increase in attack surface
> for the existing attack.

Today, websites can already learn something about the interest of their
clients in specific resources. For example, search engines learn which
results a client clicked by providing the client redirects instead of
direct links. Thus, I think the described attack surface does not
increase with respect to links directly provided by the website
supporting resolver-less DNS.

Beyond this, I describe in Section 3.2.2 of the paper restrictions for
DNS records retrieved via resolver-less DNS. Here, it is recommended
that user agents restrict the use of unvalidated DNS records retrieved
via resolver-less DNS within the context of the same website or possibly
the same browser tab. This measure prevents the described leaks beyond
the applied context of a website or browser tab. Thus, I do not agree
that resolver-less DNS contributes to the described increase in the
attack surface.

Erik

>   At the very least, that appears to require clients to cache where
> DNS records came from in their cache, so that they can build a
> reputation for sources that supplied bad data and ignore data from
> sources that gave bad data.  That's a far from perfect mitigation, of
> course, but it helps some.
>  
>
>     >  
> Agreed, but it also can't be ignored that the new source of supplied
> DNS records gives a new opportunity to line up the facilities needed
> for a successful attack.
>
> regards,
>
> Ted
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Aug 2019 19:50:15 +0000

> that resolver-less DNS contributes to the described increase in the

does this mean an fbcdn.net link occuring inside a facebook.com object would 
require a real DNS lookup, and that any fbcdn.net DNS data included in the 
facebook.com link would be ignored by a correctly implemented browser?

i ask, because of this:

> ;; ANSWER SECTION:
> www.microsoft.com.  CNAME  www.microsoft.com-c-3.edgekey.net.
> www.microsoft.com-c-3.edgekey.net. CNAME www.microsoft.com-
c-3.edgekey.net.globalredir.akadns.net.
> www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. CNAME 
e13678.dspb.akamaiedge.net.
> e13678.dspb.akamaiedge.net. A 23.197.97.139

my stub resolvers trust this from their recursive servers. but such CNAME 
chains are ignored by recursive servers, since the authority can only speak 
for one zone at a time. i'd like to be sure that i understand the rules you 
are proposing for the web equivalent of all this.

-- 
Paul

---

From: Erik Sy <[email-masked]>
Date: Fri, 16 Aug 2019 22:25:39 +0200

Hi Paul,

> facebook.com link would be ignored by a correctly implemented browser?

Let's assume, the user visits the website facebook.com. This website
requires the resource https://fbcdn.net/file1. Furthermore, the
connection with facebook.com pushes a DNS record for fbcdn.net to the
client. Now, the client can use the provided DNS record to retrieve
https://fbcdn.net/file1. However, if the server authentication with
fbcdn.net fails, this requires the client to evaluate a fallback DNS lookup.

Expanding this scenario, we can assume file1 requires to retrieve
https://a.com/file2 and the connection with fbcdn.net also pushes the
corresponding DNS record for a.com. Now, the browser can use the DNS
record for a.com to retrieve file2 because these connection occur within
the context of the same website assuming a successful server authentication.

Erik

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Aug 2019 13:29:01 -0700

Hi Erik,

Thanks for the time you've taken with your replies.  It appears we simply
disagree, as I believe the measure does increase the attack surface,
especially in the cases where the measures to limit the supplied records
are not (for example, I think "same browser tab" is too lax).  I appreciate
the opportunity to discuss this, however, despite our disagreement.

regards,

Ted

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Aug 2019 20:30:49 +0000

On Friday, 16 August 2019 20:25:39 UTC Erik Sy wrote:
> ...
> > does this mean an fbcdn.net link occuring inside a facebook.com object
> > would require a real DNS lookup, and that any fbcdn.net DNS data included
> > in the facebook.com link would be ignored by a correctly implemented
> > browser?
> > 

quite aside from my concerns about the lack of monitoring and control by the 
local network operator (who may have DNS policies which no standard ought to 
ignore or bypass), this seems wrong on the face of it. can you limit it to 
same-origin policy? web publishers wishing to take advantage of whatever 
benefits "resolverless dns" would offer them, can easily rename their linked 
objects to fit a same-origin policy similar to the one used for cookie 
coverage.

> the context of the same website assuming a successful server authentication.

thank you for clarifying that; i redouble my earlier (above) ask that this NOT 
be done.

-- 
Paul

---

From: Erik Sy <[email-masked]>
Date: Fri, 16 Aug 2019 22:50:05 +0200

On 8/16/19 22:30, Paul Vixie wrote:
> quite aside from my concerns about the lack of monitoring and control
> by the local network operator (who may have DNS policies which no
> standard ought to ignore or bypass), this seems wrong on the face of it.
Can you please explain your concern and why you think that a limitation
to a same-origin policy is required?
> can you limit it to same-origin policy? web publishers wishing to take
> advantage of whatever benefits "resolverless dns" would offer them,
> can easily rename their linked objects to fit a same-origin policy
> similar to the one used for cookie coverage.
>
> thank you for clarifying that; i redouble my earlier (above) ask that
> this NOT be done.
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Aug 2019 21:02:49 +0000

> to a same-origin policy is required?

nothing which can be abused won't be. your design has at least one flaw that a 
red team would find for you if you had one. instead you've got us.

there is no reason for a web client to trust a web server to provide correct 
information about dns outside of its same-origin. that data could be stale, 
accidentally wrong, or purposefully wrong. this problem is why dnssec exists.

i believe i've seen you argue elsewhere in this thread as to the authenticity 
guarantees of the TLS (HTTPS) path from the web client to the web server. i 
don't agree with that view, and the DANE (TLSA RR) approach is necessary.

however, even if i agreed, i would decline a design which called for the 
client to trust the server to have accurate information about any domain 
outside of the same-origin policy which we already trust for cookie coverage.

* * *

i'm also waiting to see a problem statement that justifies resolverless dns, 
and if we get past that, i'll want to see how the network operator's policies 
for dns monitoring and filtering will be reliably detected, and respected.

-- 
Paul

---

From: Anne Bennett <[email-masked]>
Date: Fri, 16 Aug 2019 17:35:25 -0400

Paul Vixie <[email-masked]> writes:

> i'll want to see how the network operator's policies for
> dns monitoring and filtering will be reliably detected,
> and respected.

I would think this to be an impossible task; if I as a network
operator am redirecting all port 53 traffic to my resolvers,
which use various filtering policies to, for example, redirect
queries for known phishing and malware sites to my local
"don't be phished" web page, what on earth mechanism could
possibly exist that could mirror my policies in this context?

While I believe in the bona fide of the people advocating for
resolverless DNS, and I don't doubt that there are performance
bottlenecks that could be alleviated with such a scheme, as a
sysadmin I feel almost as if these designs were specifically
created to prevent me from protecting my users.  :-(

Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email-masked]                                    +1 514 848-2424 x2285

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Aug 2019 21:45:08 +0000

> possibly exist that could mirror my policies in this context?

this draft in another wg appears to be an attempt at such:

https://datatracker.ietf.org/doc/draft-sah-resolver-information/

i don't know if it can meet the "reliably detected" threshold though.

> created to prevent me from protecting my users.  :-(

i know that feeling. but i think what's happened is the next generation of 
internet technologists have taken an interest in dns, without ever having 
tried to secure it or defend it, or its applications. not knowing what they 
don't know, their proposals seem more reasonable to them than to me.

see also:

http://dnstap.info/

and:

https://dnsrpz.info/

-- 
Paul

---

From: Erik Sy <[email-masked]>
Date: Fri, 16 Aug 2019 23:52:40 +0200

> for dns monitoring and filtering will be reliably detected, and respected.

Clients using a traditional DNS resolver do not care about a validation
of those DNS records. Resolver-less DNS changes this practice and
applies validation strategies for DNS records to improve the clients
security.

In this thread, we talked about possible privacy drawbacks of
resolver-less DNS. However, did we talk about the privacy risks of using
a traditional DNS resolver? They can monitor the entire browsing
activities of a user and present the real privacy problem.

Finally, DNS lookups introduce additional delay to connection
establishments on the web. Especially, for clients on high-latency
access networks this delay is quite significant. In my view, user and
service provider benefit from resolver-less DNS as it reduces that delay
and contributes to an accelerated retrieval of websites.

Erik

---

From: Paul Vixie <[email-masked]>
Date: Sat, 17 Aug 2019 05:39:55 +0000

On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote:
> > i'm also waiting to see a problem statement that justifies resolverless
> > dns, and if we get past that, i'll want to see how the network operator's
> > policies for dns monitoring and filtering will be reliably detected, and
> > respected.
> of those DNS records.

i have significant evidence to the contrary.

> Resolver-less DNS changes this practice and

your reinvention will not be universally welcomed as a saviour.

> activities of a user and present the real privacy problem.

DoT (RFC 7858) corrects that privacy problem and is being deployed.

> and contributes to an accelerated retrieval of websites.

you are not the first designer to prioritize performance over safety and 
correctness, or to offer one-off solutions which do not help to create a 
unified architecture where each part leverages the whole.

please respect the network operator's wishes if local DNS policy filtering 
and/or monitoring is a requirement.

please do not define a protocol which offers, or accepts, non-same-origin 
data.

i will be happy to meet you on a teleconference to discuss these matters.

-- 
Paul

---

From: Erik Sy <[email-masked]>
Date: Sat, 17 Aug 2019 21:35:23 +0200

> i have significant evidence to the contrary.
Can you please share your evidence?
> DoT (RFC 7858) corrects that privacy problem and is being deployed.

The privacy problem is that a significant share of DNS resolvers monitor
the users' online activities, aggregate these data in user profiles and
use these profiles within behavioral advertising or share these user
profiles with other parties. Here [1], you can find a comparative
analysis of public DNS resolver privacy policies substantiating my claims.

Transport encryption for DNS records does not mitigate the privacy
problem presented by DNS resolvers. Indeed, DoT facilitates the linking
of DNS queries to specific user profiles. Previously, machine learning
based on behavioral DNS pattern was required to reidentify a user after
a change of its IP address [2]. DoT and DoH allow the DNS resolver to
link user activities precisely based on TLS session resumption because
these protocols compensate the costs of a full TLS handshake across
several resumed sessions [3].
Thus, DoT and DoH do not contribute mitigating the privacy problem
centering around DNS resolver.

Erik

[1] https://onlinelibrary.wiley.com/doi/pdf/10.1002/poi3.195

[2]
https://svs.informatik.uni-hamburg.de/publications/2013/2013-04-10HBF_Behavior-based-tracking-with-dns-traffic.pdf

[3] https://arxiv.org/pdf/1810.07304.pdf

---

From: Steffen Nurpmeso <[email-masked]>
Date: Sat, 17 Aug 2019 22:20:48 +0200

Erik Sy wrote in <[email-masked]\
mburg.de>:
 |On 8/17/19 07:39, Paul Vixie wrote:
 |> On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote:
 |>> On 8/16/19 23:02, Paul Vixie wrote:
 ...
 |>> Clients using a traditional DNS resolver do not care about a validation
 |>> of those DNS records.
 |> i have significant evidence to the contrary.
 |Can you please share your evidence?

 |>> In this thread, we talked about possible privacy drawbacks of
 |>> resolver-less DNS. However, did we talk about the privacy risks of using
 |>> a traditional DNS resolver? They can monitor the entire browsing
 |>> activities of a user and present the real privacy problem.
 |> DoT (RFC 7858) corrects that privacy problem and is being deployed.

That is cool, btw., and i truly had an eruption of joy once that
(these) RFC(s) came along!  I personally do not really understand
why this data (certificates) absolutely has to be stored in the
DNS itself, but that is me and i am talking from the view of
implementing the fully caching stub resolver that i once did.
And so many RFCs have been produced on that topic, and exist,
anyway.

 |The privacy problem is that a significant share of DNS resolvers monitor
 |the users' online activities, aggregate these data in user profiles and
 |use these profiles within behavioral advertising or share these user
 |profiles with other parties. Here [1], you can find a comparative
 |analysis of public DNS resolver privacy policies substantiating my claims.
 |
 |Transport encryption for DNS records does not mitigate the privacy
 |problem presented by DNS resolvers. Indeed, DoT facilitates the linking
 |of DNS queries to specific user profiles. Previously, machine learning
 |based on behavioral DNS pattern was required to reidentify a user after
 |a change of its IP address [2]. DoT and DoH allow the DNS resolver to
 |link user activities precisely based on TLS session resumption because
 |these protocols compensate the costs of a full TLS handshake across
 |several resumed sessions [3].
 |Thus, DoT and DoH do not contribute mitigating the privacy problem
 |centering around DNS resolver.

Collecting data is a real and hard so-called business (maybe "the
root of all evil to- ooday"), at least in the hard west, like the
U.S.[1].
 
  [1] https://www.schneier.com/essays/archives/2018/03/its_not_just_faceboo.html

So even if HTTP/2 does its best to hide more behind crypto, and of
course thinking about the issue and trying to give more privacy
back to users is honourable, people have their smart phone in
bedroom/toilet/car/funeral, their car is online, their household
appliances are online etc.  In April i bought my first new box in
ten years, and out of interest installed the default Windows, for
me the first since Windows 95B, and i got really frightened by the
questions and, yes, services that installation asked and/or
offered.  (It was possible to turn all off, iirc.)  In 2009
i bought an Apple (wanted one once in my life), and i still grim
when i think back and recall the hundreds of megabytes of data
a "software update" collection send over the internet; when
i compare with the much less than 10MB that an update of the Linux
and *BSD distributions take, and these are entire package
collections with tens of thousands of packages.
You have credit cards, and you use it.  Mind you, maybe you even
use amazon, facebook, twitter, paypal, or any such company, which
i do not.

Once this resolverless DNS came up already i seem to remember the
idea to create a kind of "mini per-connection tor", at least
regarding DNS data.  But then you have "islands" of caching
resolvers all along the way, to which you will be able to talk
encrypted via TLS/DTLS soon, hopefully.  (Hopefully in the sense
that i put trust everywhere, and thus also in the DNS endpoint
i am actually talking to.  I personally would have nothing against
TSIGs on data sent from it, too.  And if some HTTP/2 speaking
browser can use and verify DNS binary blobs coming over from the
HTTP server all i personally feel about that is that those
software monsters can do that and reuse the anyway open connection
they sit upon, because why not.  But i do not think it will heal
the world, i would guess that all it will possibly do, and maybe
only temporary even, is that it makes the mesh more broad.  At the
cost of increased complexity and even more technical aspects to
adhere to; but rather a HTTP than a DNS problem, me thinks.
I think that is what i wanted to say.)

A nice Sunday everybody!
Ciao from (and to) Germany,

--steffen
|

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 17 Aug 2019 23:13:18 +0200

Moin!

> analysis of public DNS resolver privacy policies substantiating my claims.
The majority of DNS resolvers for end users are still run by ISPs and
Telcos. In that paper you reference the only company that can be seen
as an ISP is Level3, although there resolver in contrast to mosts ISPs
is open. The other are the usual open resolver vendors. So this paper
clearly misses a large part of the resolver population.

And my experiences with ISPs and Telkos is that they are, probably
because most of them are regulated very sensitive to privacy and
data analysis for marketing and advertising. A lot of them do or
let others do analytics on their data, mostly after being anonymised,
for security purposes, but not more.

So long
-Ralf
—--
Ralf Weber

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2019 12:24:00 -0400

>analysis of public DNS resolver privacy policies substantiating my claims.

I took a look at that paper, written by two grad students.  If I were
their advisor I would have handed it back to them and told them to
talk to some people who understand the topic so they could fix the
many painful factual errors.  They got the whole WHOIS GDPR fight
backward, and made the rather large leap assuming that every word in,
say, Google's generic privacy policy applies to queries to 8.8.8.8.
What does it mean to have an account with a DNS resolver?

I'm not saying that there are no issues, but this paper is not a
useful discussion of them.

R's,
John

---

From: Erik Sy <[email-masked]>
Date: Mon, 19 Aug 2019 09:58:54 +0200

On 8/18/19 18:24, John Levine wrote:
> I took a look at that paper, written by two grad students.  
I think the term grad student is not an appropriate description for a
professor at the American University in Washington, DC. From my
perspective, Samantha Bradshaw [1] and Laura DeNardis [2] have a good 
academic track record in the filed.
> If I were

The authors describe this limitation in their paper. In detail, some
privacy policies are too generic and lack specific information about
what DNS query data was collected, used and stored. Nonetheless, the
authors concluded that the privacy policies of several DNS resolvers
allow using DNS queries to aggregate user data for advertising.

I'm not surprised by the authors' classification of Google's DNS
resolver. In my view, it is plausible that an advertising company
running a large number of DNS resolvers as a free service is using the
collected user data in the context of behavioral advertising.

> useful discussion of them.

I agree that an empirical measurement substantiating the use of prior
DNS queries within behavioral advertising is certainly a stronger
indication for the mentioned privacy issue than a description in the
privacy policy. However, I'm not aware of prior empirical research work
in that direction.

In total, resolver-less DNS does still send a possibly large number of
fallback DNS queries to the preconfigured DNS resolver. Following this,
the main argument to support resolver-less DNS is a faster connection
establishment on the web as it saves the delay caused by the traditional
DNS lookups. The described privacy enhancement via resolver-less DNS is
just a positive side-effect.

Erik

[1] https://scholar.google.de/citations?user=emHBI1MAAAAJ
[2] https://scholar.google.de/citations?user=PROAnvEAAAAJ

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Aug 2019 09:04:31 -0700

Hi Erik,

> collected user data in the context of behavioral advertising.
Google has published specific information on how the DNS logs are processed:

https://developers.google.com/speed/public-dns/privacy

so there is no need to guess.

regards,

Ted

---

From: Anne Bennett <[email-masked]>
Date: Mon, 19 Aug 2019 12:10:48 -0400

PV = Paul Vixie <[email-masked]>
AB = Anne Bennett <[email-masked]>
ES = Erik Sy <[email-masked]>

PV>>> i'll want to see how the network operator's policies for
PV>>> dns monitoring and filtering will be reliably detected,
PV>>> and respected.

AB>> I would think this to be an impossible task;

PV> this draft in another wg appears to be an attempt at such:
PV> https://datatracker.ietf.org/doc/draft-sah-resolver-information/
PV> 
PV> i don't know if it can meet the "reliably detected" threshold though.

I took a quick look at the above draft; it specifies a method
for enquiring about "features of a recursive resolver", but
gives no ideas or guidance as to what such features might
consist of, aside from a brief sentence fragment in the
abstract, "such as whether they perform DNSSEC validation or
are available over transports other than what is defined in
RFC 1035".

It seems to me straightforward to use this mechanism to supply
the information *that* a resolver applies filtering, but I don't
see how it could reasonably *describe* the filtering, since
such a description would essentially almost *be* the filtering.

I think your polite assumption that it could be possible for
resolverless DNS to respect a network operator's policies for
DNS filtering is, well, polite.  ;-)

... which brings us to:

ES>> we talked about possible privacy drawbacks of resolver-less
ES>> DNS. However, did we talk about the privacy risks of using a
ES>> traditional DNS resolver? They can monitor the entire browsing
ES>> activities of a user and present the real privacy problem.

PV> DoT (RFC 7858) corrects that privacy problem and is being deployed.

I dispute the idea that DNS over TLS addresses the privacy
problem of the resolver operator having access to all of a
user's DNS queries.

That being said, I think that stating that traditional DNS has the
"real privacy problem", and implying that resolverless DNS doesn't
suffer from a similar problem, is disingenuous.

If I ask a question and expect an answer, *someone* has to hear my
question!  Who would I rather trust: an ISP whose services I pay for,
or a commercial web site where most likely, I *am* the product? 

Anne.

---

From: Eric Orth <[email-masked]>
Date: Mon, 19 Aug 2019 12:28:58 -0400

> such a description would essentially almost *be* the filtering.

But that could still be very valuable.  If (and this is a big if) many
recursive resolvers use this mechanism to state whether or not they do
significant filtering, then for those that report that they do not, this
becomes a strong signal to clients that resolverless DNS will not bypass
any filtering.

---

From: "John Levine" <[email-masked]>
Date: 19 Aug 2019 13:07:49 -0400

>becomes a strong signal to clients that resolverless DNS will not bypass

I'm scratching my head trying to figure out why I would want to
configure my DNS resolver to tell random malware and PII stealing apps
what my filtering policy is.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 19 Aug 2019 13:17:12 -0400

>allow using DNS queries to aggregate user data for advertising.

Indeed, but since the authors clearly didn't understand what they were
talking about, this remains unhelpful.  It's hypothetically possible
that, say, Google uses query data from 8.8.8.8 to target ads, but
in the absence of a lot of other user data like logging in from a Chrome
browser it's hard to see how it would be more than a very weak signal
in an environment full of strong signals.

>privacy policy. However, I'm not aware of prior empirical research work

Neither am I, so I don't understand why anyone makes assertions about
what they do.

R's,
John

---

From: Erik Sy <[email-masked]>
Date: Mon, 19 Aug 2019 21:09:13 +0200

Hi Ralf,

On 8/17/19 23:13, Ralf Weber wrote
> for security purposes, but not more.

Nonetheless, there exists empirical evidence that several popular ISPs
and Telcos sold data on their customers' online activities to
advertising companies [1,2,3]. Thus, it is plausible that these ISPs and
Telcos use their DNS resolver to aggregate such user profiles. Note,
that features such as Encrypted Server Name Indication (ESNI) for TLS
will make the aggregation of such user data based on the analysis of
network traffic more difficult. Thus, for ISPs aiming to monitor the
users' online activities, the DNS resolver may become an increasingly
important source of such user data.

Erik

1:
http://transition.fcc.gov/Daily_Releases/Daily_Business/2014/db0903/DOC-329127A1.pdf

2:
https://www.ftc.gov/system/files/documents/public_comments/2015/09/00008-97486.pdf

3:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.700.4721&rep=rep1&type=pdf

---

From: Erik Sy <[email-masked]>
Date: Mon, 19 Aug 2019 22:25:13 +0200

> suffer from a similar problem, is disingenuous.

Ok, I assume we agree on a traditional DNS resolver being able to
monitor the user's online activities, right?
Resolver-less DNS is different as the web server does not learn anything
new about it's users when serving DNS records because it just provides
the user with some relevant DNS records. Note, that there does not exist
a concept for DNS queries in resolver-less DNS. Furthermore,
resolver-less DNS is a decentralized approach where there does not exist
a single entity being able to monitor the full scope of the user's
online activities. I hope this clarified the privacy difference of the
two DNS mechanisms.

> or a commercial web site where most likely, I *am* the product? 

In resolver-less DNS you do not trust retrieved DNS records because you
validate these records. In my view, this is a significant benefit of
resolver-less DNS as there exist evidence for DNS manipulations
conducted by ISPs [1].

Erik

1:
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pearce.pdf

---

From: "John Levine" <[email-masked]>
Date: 19 Aug 2019 16:39:47 -0400

In article <[email-masked]> you write:
>Telcos use their DNS resolver to aggregate such user profiles.

Actually, no, it's not plausible.  The mechanisms described in these
papers are nothing like DNS queries.  If they could get enough data
from DNS queries, why would they bother rewriting HTTP headers?

There are issues with DoH but conspiracy theories about implausible
data mining of DNS logs really are not helpful.

---

From: Erik Sy <[email-masked]>
Date: Mon, 19 Aug 2019 23:35:37 +0200

> from DNS queries, why would they bother rewriting HTTP headers?
They do not use the HTTP header for data collection. Instead, they use
the injected HTTP header to  communicate the tracking identifier between
the ISP and the advertising company as shown in this figure:
https://jonathanmayer.org/stable/blog_images/verizon_header/verizon_header.png

Erik

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Aug 2019 07:03:35 +0000

On Monday, 19 August 2019 16:10:48 UTC Anne Bennett wrote:
...
> are available over transports other than what is defined in

ah. that's my misunderstanding then. i thought "has policy" was one of the assigned 
indicators. it should be.

> such a description would essentially almost *be* the filtering.

i would not, and we could not, export that policy. it's often proprietary. only the existence 
of policy, which ought to disable any "app doing DNS" (ADD) from doing DNS, is needed.

> DNS filtering is, well, polite.  ;-)

the resolverless people are, like the DoH people, noncriminals with good hearts lacking 
only some understanding of how criminals use the internet (and the subset of the 
internet called the web, and the fact that the web is a subset of something). i believe that 
they will write a spec that recommends respect for the choices made by system and 
network operators, and i believe that vendors will implement it that way. 

which means i believe that netflow will continue to be useful in finding malware, because 
it won't follow the rules. (for a great time, find somebody from sony and ask how much 
money they would pay in modern dollars to move to the timeline where they knew about 
north korea the day after they got in.)

> .... which brings us to:

i think our ships are passing in the night. "traditional dns resolver" means one you run on 
your campus, on your LAN, on your hypervisor, on your endpoint. this whole "public DNS" 
bullpucky is entirely non-traditional. 

see also:

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

> suffer from a similar problem, is disingenuous.

resolverless is questionless. no knowledge of user intent is leaked, only knowledge of 
user probable next steps. this is an important difference, though it's entirely 
noncompelling. my network policy is that i be able to monitor and filter DNS. if that 
means i end up outlawing some web browsers or some web server IP addresses because 
they want to sneak their DNS translations through as questionless unvalidated 
unmonitorable unfilterable assertions of pseudo-fact, then that's the war i'll be in. note, i 
won't choose it, but i won't shirk it either.

> or a commercial web site where most likely, I *am* the product?

again, resolverless means there are no questions. so while it's a huge problem for 
internet security unless it respects the existence of filtering by local resolvers and unless 
it respects the same-origin policy, it's a DIFFERENT problem than the one that DoH claims 
to solve using Big Lie techniques.

-- 
Paul

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Aug 2019 07:04:50 +0000

On Monday, 19 August 2019 17:07:49 UTC John Levine wrote:
> In article <CAMOjQcFmqs-s19nd+i-
> what my filtering policy is.

you mustn't, of course. but, anyone who is capable of asking your local RDNS a 
question should also be capable of finding out, reliably, that there _is_ 
policy, so that they can shut down any DoH or resolverless logic they may 
have.

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Aug 2019 07:16:03 +0000

...
> Can you please share your evidence?

i've taken some time to think about this question, because it's as if you've asked a fish, 
"what is water?"

every customer, shareholder, competitor, family member, friend, colleague i have is 
concerned about bad DNS bindings being consumed by unsuspecting apps. they don't 
call it by that name, but they think of domain names as "owned by" someone and they 
want the answers their apps consume to be "authentic" and they know that there's a 
great risk to life and wealth if this equation doesn't hold.

you could if you were interested in learning the extent of how DNS is used and how it is 
evolving study the deployment of DNSSEC and DANE, both among OS providers, name 
owners, DNS implementers, and DNS operators. if your mind were open, you could 
consider the possibility that DNS is larger than the web, is used by many non-web apps, 
and that any web-only solution is too small to be worth bothering about, and not just a 
vector by which attackers fool victims.

but your mind seems not to be open. in the days since you wrote the above question i've 
watched you systematically dismiss all arguments that threaten your ideology. i'm making 
this reply to you because i'll be in hamburg shortly for elbsides and i hope that you will 
meet me and discuss this in person. but, my hope for this outcome has dimmed with 
each knee-jerk dismissal that you have offered this thread.

> analysis of public DNS resolver privacy policies substantiating my claims.

i prefer the traditional approach where we don't blindly give our data away to google, 
ibm, cisco, cloudflare, and anyone else who can print a Quad-N t-shirt. run your own 
RDNS, and use it. for my reasoning, see this article:

i'll hope to hear contact information for you by the sunday before elbsides.

-- 
Paul

--------

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 20 Aug 2019 10:10:48 +0200

Moin!

On 19 Aug 2019, at 23:35, Erik Sy wrote:

>> In article 
>> <[email-masked]> you 
>> write:
But again it has nothing to do with DNS or selling DNS data. I’ve 
worked with
lots of ISP/Telcos around the globe and most of them were very aware of 
the
privacy aspect of DNS data and treated it with great care.

So long
-Ralf
---
Ralf Weber

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 20 Aug 2019 12:23:21 +0200 (CEST)

> Il 19 agosto 2019 19:07 John Levine <[email-masked]> ha scritto:
>  

Also, when filtering is applied for human dignity reasons (e.g. to block racist content, terrorist websites, child porn etc.) you explicitly do not want to publish the list of blocked destinations, as it would be an easy directory for wannabe racists/terrorists/pedophiles...

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

---

From: Anne Bennett <[email-masked]>
Date: Tue, 20 Aug 2019 13:24:41 -0400

PV>>> https://datatracker.ietf.org/doc/draft-sah-resolver-information/

AB>> I took a quick look at the above draft; it specifies a method
AB>> for enquiring about "features of a recursive resolver", but
AB>> gives no ideas or guidance as to what such features might
AB>> consist of, aside from a brief sentence fragment in the
AB>> abstract, "such as whether they perform DNSSEC validation or
AB>> are available over transports other than what is defined in
AB>> RFC 1035".

PV> ah. that's my misunderstanding then. i thought "has policy" was 
PV> one of the assigned indicators. it should be.

It may well become one; the draft states that "IANA will
create a new registry titled "DNS Resolver Information"
that will contain definitions of the names that can be used
with the protocols defined in this document", but since such a
registry is not implemented yet, the reader of the draft can't
assume what's intended.  Likely you've seen another document
or followed another discussion that mentioned it.

AB>> It seems to me straightforward to use this mechanism to supply
AB>> the information *that* a resolver applies filtering, but I don't
AB>> see how it could reasonably *describe* the filtering, since
AB>> such a description would essentially almost *be* the filtering.

PV> i would not, and we could not, export that policy.

We're on the same page there!

ES>>>> we talked about possible privacy drawbacks of resolver-less
ES>>>> DNS. However, did we talk about the privacy risks of using a
ES>>>> traditional DNS resolver? They can monitor the entire browsing
ES>>>> activities of a user and present the real privacy problem.

PV>>> DoT (RFC 7858) corrects that privacy problem and is being deployed.

AB>> I dispute the idea that DNS over TLS addresses the privacy
AB>> problem of the resolver operator having access to all of a
AB>> user's DNS queries.

PV> i think our ships are passing in the night.

Quite possibly, or mine may have sprung a leak.  ;-)

PV> "traditional dns resolver" means one you run on your campus,
PV> on your LAN, on your hypervisor, on your endpoint. this whole
PV> "public DNS" bullpucky is entirely non-traditional.

Ah, I was assuming that "traditional" DNS resolution was the mechanism
of UDP or TCP queries to port 53 (or, now, 853), no matter who was
running the resolver.

I don't have stats on devices on the Internet, but I suspect
that the number of DNS clients on networks run professionally,
with local resolvers, is, at this point, probably small
compared to the number of cellphones, laptops, home systems,
and IoT devices.  Ideally, these would all would use the
ISP's resolvers, but if people are connecting to untrusted
networks (e.g. wireless at the airport or coffee shop), I can
well imagine why using one of the "public" resolvers might
be considered safer, though if DNSSEC validation is used,
a hostile or compromised ISP might matter less.

PV> resolverless is questionless. no knowledge of user intent is
PV> leaked, only knowledge of user probable next steps. this is
PV> an important difference,

Thank you for setting me straight on that; I was indeed thinking of DoH.

ES> Ok, I assume we agree on a traditional DNS resolver being able
ES> to monitor the user's online activities, right?

If here you define "traditional DNS resolver" as the port 53 (or 853)
answerer of questions, then, sort of - that is, most of the user's
online activities will be based on the resolution of hostnames to IP
addresses, and the hostname queries will give the resolver a pretty
good idea of the sites of interest to the user.

But... the ISP can already do traffic analysis, based on the
endpoints of the TCP/IP connections (not to mention sniff the
traffic if it is not encrypted), so if the user is using the
ISP's resolver, there's no *additional* privacy concern there,
I think.

If you're considering that some people use the "big public
resolvers", then sure, those sites could be acquiring
information which a user would prefer to keep private.
It's rather tempting to say "so don't do that" (that is,
don't use the big public resolvers), though.  I'm still not
convinced that a whole new DNS mechanism is a step in the
right direction; it seems to me like just one more attack
surface to have to monitor and protect.

ES> Furthermore, resolver-less DNS is a decentralized approach
ES> where there does not exist a single entity being able to monitor
ES> the full scope of the user's online activities.

The ISP will always be able to do that, even if only traffic analysis.

ES> In resolver-less DNS you do not trust retrieved DNS records
ES> because you validate these records.

At this point, you should probably tell me to Read The Fine
Paper, but I immediately wonder: *how* does the client validate
the records?  I suppose the server may be sending all the
DNSSEC information.

If so, though, your scheme still cuts off my ability, as a network
admin, to use DNS resolution to impose policies to protect my users
from malware (for example).

Anne.

---

From: Erik Sy <[email-masked]>
Date: Tue, 20 Aug 2019 21:08:19 +0200

> Also, when filtering is applied for human dignity reasons (e.g. to block racist content, terrorist websites, child porn etc.) you explicitly do not want to publish the list of blocked destinations,…
The better way to handle illegal content online is the notice and
takedown approach because the provider will delete that specific content
and it becomes inaccessible to all internet user. There exist
organisations such as [1] and [2] where it is easy to report illegal
content and they do the remaining work such as informing providers and
instigating a criminal prosecution. This notice and takedown achieves to
delete about 60% of the reported illegal content within the first three
days [3].

Erik

1: https://www.cybertip.ca

2:
http://88.208.218.79/gns/internet-concerns/overview-of-the-problem/illegal-content.aspx

3: http://88.208.218.79/Libraries/2017_stats/notice-and-takedown.sflb.ashx

---

From: Erik Sy <[email-masked]>
Date: Tue, 20 Aug 2019 21:30:08 +0200

On 8/20/19 10:10, Ralf Weber wrote:
> lots of ISP/Telcos around the globe and most of them were very aware
> of the
Ok, as a matter of fact we have evidence that some ISPs collected data
on their customers' private online activities with the intention to sell
this information to advertising companies. Your standpoint is, that this
has nothing to do with the ISP's DNS resolver or selling DNS data. I
have no explanation why an ISP should apply better privacy protections
to their customers DNS data compared to the customers network traffic
because both enable a significant monitoring of the users' online
activities. Do you have an explanation for this?

Erik

---

From: Erik Sy <[email-masked]>
Date: Tue, 20 Aug 2019 23:10:01 +0200

On 8/20/19 09:16, Paul Vixie wrote:
> i've taken some time to think about this question, because it's as if
> you've asked a fish, "what is water?"
>
>  
>
> every customer, shareholder, competitor, family member, friend,
> colleague i have is concerned about bad DNS bindings being consumed by
> unsuspecting apps. they don't call it by that name, but they think of
> domain names as "owned by" someone and they want the answers their
> apps consume to be "authentic" and they know that there's a great risk
> to life and wealth if this equation doesn't hold.
>
>  
>
> you could if you were interested in learning the extent of how DNS is
> used and how it is evolving study the deployment of DNSSEC and DANE,
> both among OS providers, name owners, DNS implementers, and DNS
> operators. if your mind were open, you could consider the possibility
> that DNS is larger than the web, is used by many non-web apps, and
> that any web-only solution is too small to be worth bothering about,
> and not just a vector by which attackers fool victims.
>
I'm aware of DNSSEC and DANE and their deployment issues. In total, I'm
still missing the evidence you claimed to have on clients validating DNS
records retrieved from traditional DNS resolver. I assume that by
referring to DNSSEC and DANE, you do not want to claim that some popular
client software is strictly enforcing a validation of DNS records using
DNSSEC and DANE, right?
>
> but your mind seems not to be open. in the days since you wrote the
> above question i've watched you systematically dismiss all arguments
> that threaten your ideology. i'm making this reply to you because i'll
> be in hamburg shortly for elbsides and i hope that you will meet me
> and discuss this in person. but, my hope for this outcome has dimmed
> with each knee-jerk dismissal that you have offered this thread.
>
You may have noticed that I'm also giving a talk at the elbsides shorly
after yours. Thus, it will be easy for us to meet each other there.

Erik

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Aug 2019 21:12:53 +0000

On Tuesday, 20 August 2019 21:10:01 UTC Erik Sy wrote:
> records retrieved from traditional DNS resolver.

that's moving of goalposts; i won't follow.

> I assume that by

caching resolvers everywhere, do this. the economy depends on them doing so. 
if RDNS isn't client software from your point of view, you'll dismiss these 
assertions.

> after yours. Thus, it will be easy for us to meet each other there.

that's great!

-- 
Paul

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 21 Aug 2019 09:37:50 +0200

Moin!

On 20 Aug 2019, at 21:30, Erik Sy wrote:
> this information to advertising companies.
They were also fined and had to stop it. Part of the reason here is
probably because unlike web companies ISP and Telcos are regulated in
most parts of the world.

> Your standpoint is, that this
> has nothing to do with the ISP's DNS resolver or selling DNS data.
Yes because I have not seen evidence and certainly not broad evidence
needed to call this a common practice which a lot of people do. I’ve
seen lots of evidence of people abusing HTTP (the once you cite being
one) to invade user privacy. Thus I want my name resolution to go to
my ISP and not to some web server operator I have no relationship
with.

> I have no explanation why an ISP should apply better privacy protections
Yes. ISP/Telcos are usually big organisations. DNS mostly is seen as
a network function and thus is within some kind of engineering department.
Engineers have a different mindset on data then say people working in a
marketing department, which usually is where these advertising programs
originate.

So long
-Ralf
---
Ralf Weber

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 21 Aug 2019 10:25:19 +0200 (CEST)

> Il 21 agosto 2019 09:37 Ralf Weber <[email-masked]> ha scritto:
>  

Also, an ISP's business is to sell Internet access and other connectivity services, which means that if they alienate their users by violating their privacy, users will go elsewhere and they will make less money; sure, an ISP may be tempted to increase their revenues by also monetizing user information, but definitely not up to the point of threatening their core business. On the other hand, the business model of Google, Facebook and most of the web companies is surveillance capitalism: personal information is the raw material for their products, and the more they find ways to invade the privacy of their users, the more money they make.

--

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 21 Aug 2019 10:42:35 +0200 (CEST)

> Il 20 agosto 2019 21:08 Erik Sy <[email-masked]> ha scritto:
>  
> takedown approach

Unfortunately, the notice and takedown approach works only if the content is hosted within the country. It just takes a credit card for the criminal to buy hosting somewhere else on the planet, and at that point, if you are lucky the international takedown process takes a long time, and if you are unlucky the criminal will find a country which doesn't care (there's a big one just east of the EU) or even a country in which that specific content is legal.

For example, the biggest chunk of the mandatory DNS filtering list for ISPs in Italy is made of illegal gambling websites - foreign gambling websites that did not pay the compulsory license and taxes to the Italian government and did not accept to be audited to ensure that the games are not rigged and that they do not do money laundering for the mafia (which is the real business for many of them). These websites might just be legal where they are incorporated, which might be as near as Malta; but other countries still need a way to enforce their own policies when these websites approach their citizens, and their only leverage is the ability to make them unreachable from within the country.

--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2019 06:04:13 -0700

On Aug 21, 2019, at 1:25 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> which means that if they alienate their users by violating their privacy, users will go elsewhere

You are lucky to live in a place where all the telcos do not have monopolies.   I have no choice of ISP: I either take the one I have, or I live my life offline.

---

From: Erik Sy <[email-masked]>
Date: Wed, 21 Aug 2019 21:53:55 +0200

> probably because unlike web companies ISP and Telcos are regulated in
Yes, ISPs and Telcos are regulated and they broke the law and collected
data on their customers' private online activities. In case these
companies break the law again, private user data are still pretty
unprotected.
> marketing department, which usually is where these advertising programs

I appreciate your effort to explain these things to me. However, I did
not understand in which department of these big organisations network
traffic interception is located. Anyway, I think its time to improve the
data protection of DNS before the engineering department gets involved
in those advertising programs.

Erik

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2019 20:03:21 +0000

On Wednesday, 21 August 2019 19:53:55 UTC Erik Sy wrote:
> ... Anyway, I think its time to improve the

because we have to secure the whole internet system, and not just the subset 
of that system called the web, dns itself has been the subject of massive 
change over the last two decades to improve its data protection.

the idea of having a web object tell my web browser which malware server to go 
to in order to download a bitcoin miner, without being subject to either 
control or monitoring by my private network operator (parental controls, or 
corporate security), should terrify pretty much everybody.

we need the internet system to be secure, including its naming system, and not 
on an app-by-app (such as the web, which to the internet is just an app) 
basis. embedding dns content in web object secures against only one attack, 
and only within the confines of one app. the rest of the problem will remain, 
except, the web as an app wouldn't benefit from the rest of those solutions.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2019 16:09:11 -0400

> corporate security), should terrify pretty much everybody.

How would you prevent that?  The web page can always embed an IP address.

---

From: Erik Sy <[email-masked]>
Date: Wed, 21 Aug 2019 22:26:46 +0200

On 8/21/19 10:42, Vittorio Bertola wrote:
> Unfortunately, the notice and takedown approach works only if the content is hosted within the country. It just takes a credit card for the criminal to buy hosting somewhere else on the planet, and at that point, if you are lucky the international takedown process takes a long time, and if you are unlucky the criminal will find a country which doesn't care (there's a big one just east of the EU)

It seems that you claim that notice and takedown is not successful in
Russia. However, I think that the opposite is the case. Based on [1] the
organization friendlyrunet.ru managed to remove child pornography in
14754 out of 15580 cases during the reported year. Thus, notice and
takedown was successful in about 95% of the cases.

>  or even a country in which that specific content is legal.

I agree that notice and takedown requires the specific content to be
illegal in the country where it is hosted.

Erik

1: http://www.friendlyrunet.ru/files/43/2013-Liga-AnnualReport-ENg.pdf

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Aug 2019 01:08:48 +0000

On Wednesday, 21 August 2019 20:09:11 UTC Ted Lemon wrote:
> > the idea of having a web object tell my web browser which malware server
> > to go to in order to download a bitcoin miner, without being subject to
> > either control or monitoring by my private network operator (parental
> > controls, or corporate security), should terrify pretty much everybody.
> 

my experience with HSTS is that dotted-quad links are nearly impossible to use 
from an HTTPS web object, since they point either to an HTTP web object (which 
is a downgrade) or do an HTTPS object whose SNI is a dotted quad (which is 
hard to get a certificate for.)

in any case it's not common and those may be the reasons. defacement attacks 
rely on the ability to move their ultimate payload around and they use a DNS 
name as an indirection layer so that they can keep it available during cat and 
mouse takedown games.

if linking to dotted quads worked securely and robustly, i expect that we'd 
see more of this in the non-criminal web, and less pressure for "resolverless 
dns" as a way to avoid DNS lookups.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2019 21:21:40 -0400

> hard to get a certificate for.)

Thanks, that’s a good point.   So to describe what is going on here, what you are saying is that the browser provides no avenue of endpoint identification and authorization other than DNS?

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Aug 2019 01:47:47 +0000

On Thursday, 22 August 2019 01:21:40 UTC Ted Lemon wrote:
> > my experience with HSTS is that dotted-quad links are nearly impossible to
> > use from an HTTPS web object, since they point either to an HTTP web
> > object (which is a downgrade) or do an HTTPS object whose SNI is a dotted
> > quad (which is hard to get a certificate for.)
> 
> Thanks, that’s a good point.   So to describe what is going on here, what
> you are saying is that the browser provides no avenue of endpoint
> identification and authorization other than DNS?

i don't know that part. i do know i stop a lot of crud with DNS RPZ, for 
myself and my customers, and that if web browsers stop asking DNS questions, 
the defense methods i'm using and recommending will work less often.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2019 22:39:37 -0400

So, for your use case it would be good if there were a way for authorized devices to know that they are connected to your network and use your resolvers, and a way to quarantine devices that have not been configured that way. Or you could just have always use your resolver if they are willing. 

Sent from my iPhone

> On Aug 21, 2019, at 21:47, Paul Vixie <[email-masked]> wrote:
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Aug 2019 03:08:31 +0000

On Thursday, 22 August 2019 02:39:37 UTC Ted Lemon wrote:
> So, for your use case it would be good if there were a way for authorized
> devices to know that they are connected to your network and use your
> resolvers, and a way to quarantine devices that have not been configured
> that way. Or you could just have always use your resolver if they are
> willing.

i don't love the term "use case" for this. the onus of justification is upon 
she who would change from the status quo.

what i've asked is that this behaviour rely on a secure and reliable signal 
from the system's resolver that it has no objections to the use of some other 
data path for DNS. if the system's resolver doesn't signal either way, then 
don't use any other data path for DNS.

its reasons may be filtering, or monitoring, or the principle of least 
astonishment, or moonshine. in other words its reasons don't matter.

-- 
Paul

---

From: Erik Sy <[email-masked]>
Date: Thu, 22 Aug 2019 23:11:58 +0200

On 8/20/19 23:12, Paul Vixie wrote:
> caching resolvers everywhere, do this.
This study shows that only about 12% of the resolvers use DNSSEC to
validate the records [1].
>  the economy depends on them doing so.
I find that only 0.9% of the .com domains are signed [2] and having a
signature does not mean that they can be successfully validated.
> if RDNS isn't client software from your point of view, you'll dismiss these 

RDNS requires the client to trust the used recursive resolver. In my
view, the client should be able to validate the DNS records
independently of the recursive resolver. I think there is a security
benefit for clients in using TLS server authentication to validate DNS
records at least in the context of web browsing.

Erik

1:

2: https://www.statdns.com/

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Aug 2019 21:50:58 +0000

> validate the records [1].

i think that in 2017 when that report was published, their 12% was very well distributed, 
geographically and topologically, and that it represents a disproportionate share of 
lookup transactions.

> signature does not mean that they can be successfully validated.

i suggest you broaden your search for knowledge. for example, this web site may be of 
interest, along with the monthly reports posted to dns-operations@ by the same authors.

https://stats.dnssec-tools.org/[1] 

> > if RDNS isn't client software from your point of view, you'll dismiss
> > these assertions.
> 
> RDNS requires the client to trust the used recursive resolver.

not for DANE work flows. stub validation is not widely implemented or well supported by 
DNSSEC, but it works, and existing DANE TLSA clients do this.

> In my view, the client should be able to validate the DNS records
> independently of the recursive resolver.

we agree.

> I think there is a security

we disagree, for reasons i won't repeat here a second time.

-- 
Paul

--------
[1] https://stats.dnssec-tools.org/

---

From: Erik Sy <[email-masked]>
Date: Fri, 23 Aug 2019 11:37:03 +0200

On 8/22/19 23:50, Paul Vixie wrote:
> i think that in 2017 when that report was published, their 12% was
> very well distributed, geographically and topologically, and that it
> represents a disproportionate share of lookup transactions.
>
I read this as an argument to use one of the more popular resolvers.

> i suggest you broaden your search for knowledge. for example, this web
> site may be of interest, along with the monthly reports posted to
> dns-operations@ by the same authors.
>
>  
>
> https://stats.dnssec-tools.org/
>
>  
>
Anyway, lets assume that all domains and resolvers perfectly support
DNSSEC and that we have transport encryption between the client and the
resolver. In this scenario, the client still needs to trust the resolver
to provide the correct address. Furthermore, having a correctly resolved
IP address does not solve the problem of communicating to the correct
server, which is usually the intention of the client.
> not for DANE work flows. stub validation is not widely implemented or
> well supported by DNSSEC, but it works, and existing DANE TLSA clients
> do this.
>
In my view, DANE TLSA is an approach to do public key pinning. The web
already collected a lot of experience with public key pinning as this
can be also done using other protocols than DNS. In summary, the Chrome
browser deprecated this mechanism last year [1]. Assuming that DANE TLSA
would be widely supported on client systems, I think that Chrome would
not start using this mechanism to do public key pinning.

1:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ

> > independently of the recursive resolver.
Great! Any plans except for resolver-less DNS how we can do that which
has a chance of being accepted by the browser vendors?
Erik

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 23 Aug 2019 13:11:39 +0200 (CEST)

> Il 23 agosto 2019 11:37 Erik Sy <[email-masked]> ha scritto:
> 

According to the message you linked to, the main reason for deprecating HPKP was that it was hard for site operators to make sure that the pinned certificate matched the set of CAs that would be available in browsers at any time in the future, and the chain of intermediate certificates that each CA could use. This is not a problem with DANE, since DANE validates the certificate for the current connection and not for the future (so it's not really pinning it, just validating it every time), and does not depend on CAs and on the browser's acceptance of them. Even "hostile pinning" is much harder with DANE, since it would require the attacker to gain control of both the web server and the authoritative name server, rather than just the web server; and it would cease to have effects immediately once found and remediated.

Actually, moving to DANE validation in the browser would have been quite a reasonable consequence of the analysis in the message.

--

---

From: Erik Sy <[email-masked]>
Date: Fri, 23 Aug 2019 13:50:47 +0200

> Actually, moving to DANE validation in the browser would have been quite a reasonable consequence of the analysis in the message.
Do you think the bullet point "There is a risk of rendering a site
unusable." does apply to DANE TLSA?

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 23 Aug 2019 14:05:41 +0200 (CEST)

> Il 23 agosto 2019 13:50 Erik Sy <[email-masked]> ha scritto:
> 

Sure, but it also applies to normal HTTPS certificates without pinning. How many times did you try to access an HTTPS website and were stopped by the browser, because the certificate was expired and the owner forgot to renew it, or because the certificate was self-signed, even if the site had not been attacked? It happens every day, but it's not a good reason to stop using certificates and validating them properly - it's rather a good reason for the site owner to get a better webmaster. 

Actually, DANE even solves some of these outages, since it will make the certificate valid even if it is not signed by a valid CA, as long as the TLSA record proves that it really comes from the entity controlling the hostname in the DNS.

--

---

From: Erik Sy <[email-masked]>
Date: Fri, 23 Aug 2019 16:27:16 +0200

> Sure, but it also applies to normal HTTPS certificates without pinning. How many times did you try to access an HTTPS website and were stopped by the browser, because the certificate was expired an…
Chrome establishes trust in a certificate if it is issued by a valid CA
and included in the Certificate Transparency (CT) logs. Here, the CT
allows to monitor the certificates issued by the CAs. In this ecosystem,
it is unlikely that valid CAs issue illegitimate certificates because
the trust in misbehaving CAs can be revoked at any time.

Additional pinning of certificates provides the benefit that an
illegitimate certificate can be detected during the server
authentication. Note, that CT can detect this only in the aftermath. As
a drawback of pinning, a misconfiguration of this mechanism always leads
to a fatal error. The trade-off at hand is catching misbehaving CAs
before the connection establishment and accepting hard failures due to
possible misconfiguration versus catching the malicious CA only in the
aftermath of the connection establishment. I think that Chrome decided
for the latter one.

Erik

---

From: Eric Osterweil <[email-masked]>
Date: Sun, 25 Aug 2019 14:03:11 -0400

> On Aug 23, 2019, at 5:37 AM, Erik Sy <[email-masked]> wrote:
> 

<snip>

> server, which is usually the intention of the client.

I feel like this kind of misses the point of DANE.  DANE specifies the authoritative model for creating and verifying security associations.  One of DANE’s core observations is that if the A record is securely resolved, then that same security substrate should be used to resolve the binding of that name to a certificate/key.  Said differently, the binding of a TLS certificate to a domain name (via the TLSA record) gives the client its assurance that is talking to the correct server.

> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ>

I would say this argument also misses a fundamental point.  Architecturally, DNSSEC uses a single root TA to make domain names unambiguous (i.e. collision-free) and verifiable, and DANE adds security associations to certificates by the same infrastructure.  It’s the single-rooted verification hierarchy that makes name-to-object verification collision-free and unambiguous, as opposed to solely leaving it the hands of the multi-rooted Web PKI (though DANE's selector field allows synergy w/ that model).  These assurances are not (afaict) provided by key pinning alone.  

There is a fair amount of writing that discusses this, and numerous presentations.  I’m happy to provide pointers if anyone would like.

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Sun, 25 Aug 2019 14:03:30 -0400

> On Aug 23, 2019, at 10:27 AM, Erik Sy <[email-masked]> wrote:
> 
> 

The past is prolog:
	https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/ <https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/>
DANE keeps the control of associating TLS certificates with a domain in the hands of the domain holder/operator.

CT is not a panacea, and concerns about it are still evolving.  For example, it exposes all certs from all participating CAs, and this has been shown to have negative consequences when people do not want all of their domain names (such as internal names) necessarily exposed for discovery:
	https://dl.acm.org/citation.cfm?id=3278562 <https://dl.acm.org/citation.cfm?id=3278562>

> aftermath of the connection establishment. I think that Chrome decided

If I follow your logic here, then I think this is a statement that is at least break-even for (but likely actually in favor of) DANE.  If a certificate that is proffered over a TCP connection does not match the TLSA record, it is proactively detected and the session initiation fails, yes?

Eric

---

From: Erik Sy <[email-masked]>
Date: Sun, 25 Aug 2019 22:40:50 +0200

On 8/25/19 20:03, Eric Osterweil wrote:
> If I follow your logic here, then I think this is a statement that is
> at least break-even for (but likely actually in favor of) DANE.  If a
> certificate that is proffered over a TCP connection does not match the
> TLSA record, it is proactively detected and the session initiation
> fails, yes?
>
Here is a quote from Chris Palmer on this issue[1]:

"The strength of PKP ― run-time enforcement with hard-fail — is also
exactly its weakness. Some people are OK with the risk, but overall I
think the market has spoken: HPKP has seen close to no adoption. People
don't want to brick their sites.

As for DANE, it would at best have the same strength/weakness of HPKP,
but with the additional problems of DNSSEC."

In total, it seems like Chrome does not want to deploy DANE.
Erik

1:

---

From: Eric Osterweil <[email-masked]>
Date: Sun, 25 Aug 2019 17:29:18 -0400

> On Aug 25, 2019, at 4:40 PM, Erik Sy <[email-masked]> wrote:
> 
> 
> but with the additional problems of DNSSEC.”

I think this consideration is fundamentally too narrow.  As I pointed out (elsewhere in the previous message), DANE is part of an architectural solution ( https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf <https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf> ).  While browser security is a very important space, it is just one potential application.  While DANE does offer an elegant security solution for HTTPS connections, that does not mean its benefits are limited to that venue.

To reiterate earlier points: DANE securely binds associations to names in a generalized architecture.  The architecture is composed of a non-stationary suite of solutions.  In regards to TLS, its protections go beyond just for the browser.  For instance, consider opportunistic transport layer cert/key learning for SMTP (RFC-7672: https://tools.ietf.org/html/rfc7672 <https://tools.ietf.org/html/rfc7672> ).  The deployment numbers for this use are up-and-to-the-right ( http://secspider.net/pix/tlsa-growth.png <http://secspider.net/pix/tlsa-growth.png> ).  However, what I think really illustrate's DANE’s true potential (my own 0.02 here) is the fact that it also enables certificate/key learning for object security suites like S/MIME and PGP ( https://cs.gmu.edu/~eoster/doc/2015-03-24-ietf92-libsmaug.pdf <https://cs.gmu.edu/~eoster/doc/2015-03-24-ietf92-libsmaug.pdf> ).

> In total, it seems like Chrome does not want to deploy DANE.

It continues to be a shame, but there’s always time for people to see look at growing evidence and reconsider previous decisions. ;)

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Aug 2019 14:29:33 -0400

> In my view, DANE TLSA is an approach to do public key pinning.

The analogy is deeply flawed.  HPKP has keys pinned by *clients* that
may contact the server sufficiently infrequently to make stale keys an
intractable problem.  HPKP is also provides no protection on first
contact.

With DANE, on the other hand, the keys are published in the server's
DNS zone, and refreshed by the server operator's DNS administrator
independently of any client activity.  TLSA record TTLs are typically
an hour or less, and otherwise rarely more than a day.  A client that
implements DANE is protected on first contact.

> The web
> can be also done using other protocols than DNS.

The inevitable failure of HPKP was obvious (to me and doubtless not
me alone) from the outset.  Stateful client-side key pinning does not
scale.

DANE does not share the problems of HPKP.  Yes some server operators
may be negligent and publish stale TLSA RRs, but *they* can fix this
promptly, just as they would with expired certificates (a TLSA record
is essentially a trust-anchor, it may directly designate a trusted 
leaf key or in many cases a trusted issuer).

Any perceived similarity between DANE and HPKP is largely the result
of lack of familiarity with DANE.

DANE is currently employed on 6000 SMTP MX hosts serving 1.22 million
email domains.  Only ~500 domains have stale TLSA records, and the
number should go down as more senders enable DANE, making broken
deployments more visible to negligent operators.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Aug 2019 14:45:28 -0400

> but with the additional problems of DNSSEC."

False analogies tend to lead to irrelevant conclusions.

> In total, it seems like Chrome does not want to deploy DANE.

Yes, the browser vendors are presently not looking to implement DANE.
The initial deployment of DANE is instead happening in SMTP.

DNSSEC adoption is held back by process barriers at the registrant to
registrar interface.  We need a widely deployed less burdensome way to
initially publish and subsequently update zone KSKs.  I'd also like to
see better automation of ZSK rollover.

More work remains to be done to lower the barriers and increase the
incentives.  Ideally, more of the critiques of DNSSEC would be in
the form of positive contributions to improve the tools and promote
interoperable KSK management.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Aug 2019 15:23:27 -0400

> On Aug 22, 2019, at 5:50 PM, Paul Vixie <[email-masked]> wrote:
> 
> I suggest you broaden your search for knowledge. for example, this web site may be of interest, along with the monthly reports posted to dns-operations@ by the same authors.
>  

While the .COM zone has 0.95% DNSSEC adoption (1,349,030 domains out
of 141,522,129 in yesterday's zone file), other TLDs, especially in
Europe, have a much higher adoption rate.  For example, the .CZ, .NL,
.NO and .SE TLDs have >50% DNSSEC adoption.  Below is a recent (end of
May) snapshot of the top 10 TLDs by signed domain count:

TLD	#Domains	#signed		#Source
----    --------	-------		-------
.NL	  5864458	3184849		https://stats.nic.cz/stats/domains_by_dnssec/
.COM	140169031	1273294		.COM zone file
.BR	  4056813	1079522		https://registro.br/estatisticas.html
.SE	  1453459	 769879		.SE zone file
.CZ	  1328201	 746689		https://stats.nic.cz/stats/domains_by_dnssec/
.EU	  3661899 	 513324 	Eurid reports
.PL	  2615437 	 499529 	dns.pl website
.NO	   772052 	 448640 	norid.no website
.FR	  3388943 	 402472 	afnic.fr website
.BE	  1287130 	 288876		DANE survey

Overall, in the DNSSEC survey, there are ~10 million signed domains
(delegated from "public-suffix" parent domains) out of ~260 million
sampled, so the "adoption bump" in Europe brings the overall rate
closer to 4%.

[ FWIW, with the website updated daily, I've stopped sending monthly
  summaries to the dns-operations list, but could do it again if
  there's popular demand. ]

> not for DANE work flows. stub validation is not widely implemented or well supported by DNSSEC, but it works, and existing DANE TLSA clients do this.

The DANE implementation in Postfix and Exim leaves DNSSEC validation
to the loopback (local) resolver, rather than duplicate (poorly) the
code already present in BIND, unbound, etc.  A local resolver is also
useful for caching MX RRsets, RBL results, ... so is already best-
practice on an MTA.

While applications might use libunbound or similar to directly validate
DNSSEC records, there still needs to some sort of OS service for keeping
the root (and any other) trust-anchors fresh.  This could of course be
much more light-weight than a local caching resolver...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Aug 2019 15:29:24 -0400

> On Aug 23, 2019, at 7:50 AM, Erik Sy <[email-masked]> wrote:
> 

No more so than with an expired certificate, or similar server operator
negligence.

-- 
	Viktor.

---

From: Erik Sy <[email-masked]>
Date: Tue, 27 Aug 2019 23:20:07 +0200

Hi Eric and Viktor,

> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ

It seems to me, that both of you are OK with the risk of DNSSEC + DANE
TLSA leading to hard failures. I share the view of Chris Palmer, that
the security improvements of Public Key Pinning (PKP) in browsers are
not worth the caused usability issues.

I like to point out, that resolver-less DNS can be extended to support
DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in
case browser vendors decide to support DNSSEC + DANE TLSA the browsers
can receive the corresponding records also via resolver-less DNS.

Erik

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Aug 2019 17:39:47 -0400

> On Aug 27, 2019, at 5:18 PM, Erik Sy <[email-masked]> wrote:
> 
> TLSA leading to hard failures.

I also deny beating my spouse...  Seriously, the premise of the question
"are you OK with the risk of DANE leading to hard failures" is flawed.
Hard failures are the purpose of security mechanisms.  Of course I am
OK with a security mechanism that may deny access, that's not the
right question.

The right question is whether a given mechanism is sufficiently robust
to be usable.  HPKP fails that criterion, but DANE does not suffer the
same design flaws.

Like anything not yet widely deployed for years, DANE still requires
some operator experience and improved tooling (monitoring and
deployment) to further reduce opportunities for operator error, but
there is no fundamental obstacle to robust DANE deployment as there
was with HPKP, and DANE is already considerably more robust in
practice.

> I share the view of Chris Palmer, that

HPKP is irrelevant to the discussion.

> can receive the corresponding records also via resolver-less DNS.

Actually, we've been down that road already (TLS DNSSEC chain
extension fiasco).  There is no clean way to provide downgrade
resistance in such a protocol, or even properly ensure that
answers are in bailiwick.  I doubt you are proposing that servers
MUST always return a full DNSSEC validation chain for the returned
RRsets (or denial of existence proofs for the associated DS RRs).

My take is that cache-poisoning-as-a-service is unlikely to be a good
idea.

-- 
	Viktor.

---

From: Erik Sy <[email-masked]>
Date: Thu, 29 Aug 2019 16:36:42 +0200

> OK with a security mechanism that may deny access, that's not the

I disagree, that this question is flawed. It assumes that DNSSEC + DANE
is an optional security mechanism in the context of web browsers. Note,
that for example a valid TLS certificate is considered a mandatory
security mechanism and should be enforced by hard failures. Thus, the
question is more like "are you OK with optional security mechanisms
leading to hard failures".

> to be usable. 
At least the given mechanism needs also to provide a significant
security benefit. In my view, the additional benefit of DNSSEC+ DANE
compared to Certificate Transparency + Strict Transport Security (HSTS
or MTA-STS) is for the majority of server operators or users not relevant.
> RRsets (or denial of existence proofs for the associated DS RRs).

In my view, supporting DNSSEC + DANE TLSA in resolver-less DNS makes
only sense if the server provides a full DNSSEC validation chain because
everything else seems to introduce significant delays. However, given
the significant size of full DNSSEC validation chains such feature
should be deactivated in a default configuration of resolver-less DNS.
Anyway, as long as no web browser intends to support a validation of DNS
records via DNSSEC + DANE TLSA, there is no requirement for
resolver-less DNS to support this practice.

Erik

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Aug 2019 10:59:22 -0400

Or, the client could explicitly request the validation chain.   But of course this has implications for padding: it may be that the size of the output will be more helpful for guessing.   Or it may be that it makes no difference, because the bulk of the data is signatures, which are in principle always the same size (assuming that the client specifies the signature algorithm it wants, and the server sends only those signatures).   This would be an interesting thing to investigate.

> On Aug 29, 2019, at 10:36 AM, Erik Sy <[email-masked]> wrote:
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Aug 2019 11:34:42 -0400

>> Of course I am OK with a security mechanism that may deny access,
>> that's not the right question.
> 
> is an optional security mechanism in the context of web browsers.

Do or don't, there is no "try".  Optional security mechanisms are
largely pointless.  Presently browsers don't support DANE, some
day they may.  In any case, the issue at hand is DNS(SEC) bypass,
not DANE.

Resolver-less DNS as proposed disregards long-standing defenses
against address forgery by third parties, breaks geo load-balancing,
breaks local filters that protect networks against known bad actors,
and IDS systems that detect compromised nodes.

It introduce a new cache-poisoning channel, and surprising differences
between the IP addresses a browser might use to reach a site from cold
start vs. after visiting some unrelated site.

In the case of IPv6 it can be used to fingerprint and track clients by
giving them ephemeral client-specific addresses (in the server's /64
or broader prefix) for third-party servers, and then proxying their
connections (at layer 4) to the real server, while tracking the
client's access to each site.
 
> or MTA-STS) is for the majority of server operators or users not relevant.

Let's not mix up HTTP and MTA-to-MTA SMTP.  In SMTP, DANE has significantly
broader deployment (protected domains) than MTA-STS.  The latter covers more
users of the big three centralized free email providers, but I am not a fan
of over-centralization of the Internet, and prefer open federated architectures.

> everything else seems to introduce significant delays.

In any case, the issue at hand is DNS, not DANE.  A client that wants TLSA
records is not going to obtain them via resolver-less DNS, which IIRC is
just about IP addresses.

-- 
	Viktor.

---

From: Erik Sy <[email-masked]>
Date: Thu, 29 Aug 2019 23:28:13 +0200

On 8/29/19 17:34, Viktor Dukhovni wrote:
> against address forgery by third parties,
Can you please explain this point?
>  breaks geo load-balancing,
No, there are no new issues with geo load-balancing compared to using a
public DNS resolver.
> and IDS systems that detect compromised nodes.
If you think there are any new issues compared to using a public DNS
resolver, I would appreciate you explaining these points.
> start vs. after visiting some unrelated site.
Also traditional DNS resolvers are vulnerable to cache-poisoning attacks.
> client's access to each site.
This tracking mechanism is also feasible using traditional DNS.
> broader deployment (protected domains) than MTA-STS.
Please note that MTA-STS is still a very young protocol.
> records is not going to obtain them via resolver-less DNS, which IIRC is

Resolver-less DNS is also concerned about the validation of the obtained
DNS records. Independently, of DANE TLSA which Chromes does not intend
to support there is still a security benefit of using DNSSEC to validate
the integrity of the received DNS records. If it is technically feasible
to integrate a DNSSEC validation in resolver-less DNS, then this sounds
like a good idea to me.

Erik

---

From: Joe Abley <[email-masked]>
Date: Thu, 29 Aug 2019 18:15:49 -0400

Hi Erik,

> No, there are no new issues with geo load-balancing compared to using a

I am usually pretty wary of absolute statements, especially those that declare the absence of something. I haven't seen a comparative security assessment of both (and it surely depends on precisely what model of resolverless DNS you mean), though, so I will not take a side in the entertaining debate that seems likely to result from that.

However, I do think it's also worth pointing out that geo load-balancing using the DNS today is already a terrible mess and it will be a joyous day when it can be replaced by something less bad.

(soapbox noises)

The general process by which a DNS server responds to a query for a (name, class, type) tuple that is configured with geo-specific answers is to process a set of rules at query time, consulting general-purpose databases maintained at the DNS edge that map an address to something like a (provider, city) pair, and then doing additional database lookups to determine the response that should be sent to the client for the particular service whose name (one of whose names) the client is looking up.

The complexity of the code at the DNS edge is significant, and significant failures have been observed. In an enterprise DNS provider, the code that does this stuff is often not available for public review, since it constitutes secret sauce that tastes of competitive advantage. This stuff is really hard to do without failure and introducing customer-enraging latency; it's not unreasonable that people try to protect their investment.

Centralised resolvers need to make use of the EDNS0 client-subnet option in order to allow the user's real location to be exposed to the server that is geo-answering. The EDNS0 client-subnet option has unintended consequences (see David Dagon's recent descriptions).

The database that maps addresses to (provider, city) pairs is either frequently inaccurate (watch *NOG lists for pleas for help from operators whose customers are being served from nodes far away) or is accurate because it is maintained by mining other data sources. If you have a really broad anycast network you might be able to imagine doing this based on routing and answering node location; for everybody else those data sources are real user monitoring scripts running in browsers on not-obviously-related web sites, all performing performance measurements and centralising the results without the users of those stooge web sites necessarily being aware, or at least being given the option to opt-in.

Complicated web services, perhaps especially those with complex UX, use all of these techniques together with a litany of short-lived, non-repeated DNS names intended to customise and optimise the performance for the end-user. The end result in some networks has been the observation that these short-lived names consitute such a high proportion of cached data (e.g. in campus resolvers) that "we don't have the RAM to handle another Facebook".

Some big access providers configure resolvers with hundreds of exit addresses so that they will source queries for particular names towards enterprise DNS servers from dedicated sources, as a workaround for when the geo-ip on the server is known to fail. This might seem like a ridiculous optimisation until you appreciate that your entire network's capacity planning might depend on decisions being made by CDNs and enterprise DNS providers, and anything you can do to avoid mistakes in those third-party systems is another week you get to keep your customers.

In short, the status quo is extremely slippery, architecturally messy, frequently non-deterministic and high-overhead, one that has been observed to put the burden of performance measurement and reporting on unrelated third-party Internet users, chasing an end-result that is often still not doing a very good job.

As far as DNS geo-mapping for the purposes of content steering today is concerned, the only way is up.

Rearchitecting the whole enterprise DNS and CDN industries is a task on a scale larger than moving from IPv4 to IPv6. However, what we *can* do is take specific components of the problem space and find more-elegant solutions. It seems to me that resolverless DNS has the potential to be one of those. The status quo here is almost not worth defending; some kind of change is needed.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Aug 2019 22:51:42 +0000

On Thursday, 29 August 2019 22:15:49 UTC Joe Abley wrote:
> ...
> 
> ..., I do think it's also worth pointing out that geo load-balancing
> using the DNS today is already a terrible mess and it will be a joyous day
> when it can be replaced by something less bad.
> 
> ...

see also:

_What DNS Is Not_, Paul Vixie, Internet Systems Consortium
ACM Queue; Volume 7, Issue 10; November 5, 2009
https://queue.acm.org/detail.cfm?id=1647302[1] 

-- 
Vixie

--------
[1] https://queue.acm.org/detail.cfm?id=1647302

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Aug 2019 01:30:23 -0400

> Can you please explain this point?

IIRC the protocol allows any authenticated server (with Let's
Encrypt, that's everybody) to return "out-of-bailiwick" answers
(for any unrelated domain).

Yes, a client's designated resolver can also do that, but some
clients perform local DNSSEC validation, and in any case there's a
big difference between trusting name resolution to a set of dedicated
resolvers, vs. each and every server one happens to visit (by
clicking on a malicious link for example).

> No, there are no new issues with geo load-balancing compared to using a

Well, the public DNS resolvers (which I do not use on my network)
typically pass an EDNS0 client-subnet option to the upstream
authoritative server.  I don't recall anything similar in the paper.

But if we're doing away with geo load-balancing, and moving to only
using anycast IPs to reduce latency, that's fine by me, there are
other more important problems.

> resolver, I would appreciate you explaining these points.

There are a lot more resolvers than the public DNS resolvers that
you seem to expect the whole world to be using.  The resolvers at
the office and on my home network are local, I don't use "public
DNS resolvers".

> Also traditional DNS resolvers are vulnerable to cache-poisoning attacks.

Not with DNSSEC validation, and modestly difficult off-path.  But
with this proposal, you get cache poisoing by design from any
off-path server the client happens to visit.

> This tracking mechanism is also feasible using traditional DNS.

But not available to every off-path server I visit.  My resolver
does not do that.  Your proposal would delegate this ability
to every random server I visit.  That's a security fail.

> Please note that MTA-STS is still a very young protocol.

It is not getting much support from either Exim or Postfix, any
time soon it is mostly a cloud-provider <-> cloud-provider walled
garden.  If you like your mail centralized and mined for targetted
ads, use email from these providers and MTA-STS.

But again the issues with resolverless DNS (for web browsers) are
unrelated to DANE vs. MTA-STS for MTA-to-MTA SMTP, or even DANE for
the web.  DANE and PKIX are concerned with peer authentication, not
integrity of IP address records, and modulo traffic analysis provide
a secure channel even if layers 1 through 4 are compromised by the
attacker.

-- 
	Viktor.

---

From: Eric Osterweil <[email-masked]>
Date: Sat, 31 Aug 2019 15:11:17 -0400

Jumping back to this (focusing on just DNSSEC for a moment):

> On Aug 27, 2019, at 5:20 PM, Erik Sy <[email-masked]> wrote:
> 
> Hi Eric and Viktor,
> 

Here’s a quote (and write-up) from Geoff Huston:
	``Failing to secure DNS is 'savage ignorance’’' - https://www.zdnet.com/article/failing-to-secure-dns-is-savage-ignorance-geoff-huston/
ymmv ;)

> can receive the corresponding records also via resolver-less DNS.

To be a little more blunt (or maybe not): I think it’s false logic to treat this as a choice for new protocol development.
DNS is an infrastructure protocol.  In it, authorities and resolvers _both_ play a role (through their stated/deployed security postures) in how they want security to be enforced.  DNS' security extensions are part of how rightful resource holders (authoritative zones) express their desire and intent to secure their resources, separately from how resolvers verify security.  It seems to me to be poor engineering if a newer protocol encourages resolvers to ignore authorities' stated desire for security.  I’d posit that newer protocols that intend to _interoperate_ with the DNS can only correctly do so by conforming with that protocol’s specification (and those of its standards-track extensions), of which DNSSEC is one.  That is what protocols are for: interoperation of heterogeneous implementations/systems.  The idea that cherry-picking which part of DNS a new protocol suite wants to embrace is a suspicious approach to engineering protocols, imho.

Eric