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

[Viktor Dukhovni <[e-mail]>]

> On Aug 29, 2019, at 10:36 AM, Erik Sy <[e-mail]> wrote:
> 
> On 8/27/19 23:39, Viktor Dukhovni wrote:
>> Of course I am OK with a security mechanism that may deny access,
>> that's not the right question.
> 
> I disagree, that this question is flawed. It assumes that DNSSEC + DANE
> 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.
 
> 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.

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.

> 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.

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.