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

Ted Hardie <> Thu, 15 August 2019 17:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88DA11200EB for <>; Thu, 15 Aug 2019 10:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gz8esMeCdfF2 for <>; Thu, 15 Aug 2019 10:58:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A82ED1200FB for <>; Thu, 15 Aug 2019 10:58:10 -0700 (PDT)
Received: by with SMTP id s21so876697ioa.1 for <>; Thu, 15 Aug 2019 10:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kotho2NwstlcBWfurCZLiBhrYbvadihFTabnqyYKzhk=; b=pVBRiI8pMuFVIxeLjSysgLBb0Sh5EEDSZOeJQkD5lx6caEFjAJTOIiXwcXs6BJ0f85 eISjYiB/hBdcy24swZDL0iz7JkVnlF3EoelMhFB7qe1DDeXC0LfxuJPUQLh7XxCatecR 3y8Z926oO75/ZPMSXqB1t5BPr5NkAIf4ZSyVbyikC1FK6m9fh2zyO/h1nhm2FFKvf7Dp CzzoovQxfV14dYnVSvGoEf262/F61uDKpDzzKPkRDtT9qxBJWNZkaEgSnawF0fRDiILo 8GwdpUPMPSZjCzhB9pwbCCS9EBoXqJwc0teia+0RQQ5QQMAWc64HZlfMziQwF0M/+dOp aGeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kotho2NwstlcBWfurCZLiBhrYbvadihFTabnqyYKzhk=; b=s4i3KpLthiuIkWWrOTB4/lhqtzoxcQ0P9tEO19uBjcTVBqh+krBdckfqliDMPO148g 4FA39+xqHv1Rtxunv3JS9wvUtRtN59nF2BcHq7Teh2FccAY6KXknl7B7QResmjktNo3V zFxyMRk3fdpOWEkz/QoJ8A7LvSnMzX+q/WPfqFj5fU3vp7R3QqYmwh+uMCxni95YVjXc hw5heMuK/j3cA9axv0N/hWkSwdiwRY8q1hW1IYG03CT+ayDsDP1icavCXzoq07PHz0op ZdI1N4Buzg9qQzM5ksHGEVkis+l35dgMmKNDk8HTT6NzD7JlduIpu6g7JOicn0/7b+6m goQw==
X-Gm-Message-State: APjAAAWftCD5jdKpT5ypsCIWCwEjKI8cxAQyeXrqs9SG4j1cQQhBytww Ggc+OSHIMypnFVFwab3uyPwHhPQoiOAZWOye9es=
X-Google-Smtp-Source: APXvYqw57BB1QJIxTKrmF+e1GumjGHnzNGCYwVPi7zFLkbwVgRUwjNQa9s1zxcIV7y63u8W9Wz8kjtFJa0Wmcg+xVrI=
X-Received: by 2002:a5e:c113:: with SMTP id v19mr5044766iol.219.1565891889714; Thu, 15 Aug 2019 10:58:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <20190815163938.CF9CB85D108@ary.local>
In-Reply-To: <20190815163938.CF9CB85D108@ary.local>
From: Ted Hardie <>
Date: Thu, 15 Aug 2019 10:57:42 -0700
Message-ID: <>
To: John Levine <>
Cc:, Ben Schwartz <>
Content-Type: multipart/alternative; boundary="000000000000d7d8e005902b9d36"
Archived-At: <>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Aug 2019 17:58:15 -0000

Howdy John,

On Thu, Aug 15, 2019 at 9:39 AM John Levine <> wrote:

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


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

> 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