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

[Ted Hardie <[e-mail]>]

Howdy John,

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

> In article <
> [e-mail]> you
> write:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >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.
>
> 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.


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
> 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
>
> --
> Resolverless-dns mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>