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

Ted Hardie <> Thu, 15 August 2019 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B2321200DB for <>; Thu, 15 Aug 2019 14:03:49 -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 uvNWeoVUfvLg for <>; Thu, 15 Aug 2019 14:03:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A831D1200C7 for <>; Thu, 15 Aug 2019 14:03:45 -0700 (PDT)
Received: by with SMTP id q22so1994166iog.4 for <>; Thu, 15 Aug 2019 14:03:45 -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=BpUHEE2wS40UjAyPqKpkfovX492JesU0uh1b0UPMdmE=; b=EzwvYefuaVkcCJMgekthbowemMlT3AUIgl8Kx/guWujtF9YLsGCueiIEMsy+M5Eo4z zzpt/iUCE09WnWkzznUxMyKpgeTlodT1hE0RvfEeIGiOiOlMh/kgJL/SNXyEbVpKld6R ZBsywvvn4Sgf2Zp4qQGZOF8kl8uvhIWlCbJCd2WzuFhBRj6qrlXcL1uw8Hk0SVFZw2Fh RrCTb/tB5cXaRZhZnzfEsLYIMRfVL9ytVWgueOg+/ybYv0Ogyp6lDNZBFdvgTedRujjG 23qWofIKyOwU7gWtqk6Qx0qQ/uFHwXMv3IBpef6HgPjVPijQgsRpAUPpOzR+iR2fxklI JpIw==
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=BpUHEE2wS40UjAyPqKpkfovX492JesU0uh1b0UPMdmE=; b=Q1JS+d3BkydUkxVdxTuBWHxdRrHPJXz0eZr+5T9sISCRgZPphOMdAdYisSE2e7f7Wy 082sW58s5NhzuQTz+tbWxdav2MliJ0dofbDolbGxstwSFzndtzfzztTiTCo2GZ6dTbxZ Yo5KVdDQTUI7FP+JYgHhijmhWXZf/IdeY0yCyjZM1p2/gPyFNzNfM+9ISVWHmxcO6TH6 7E28TP82p3WfebwWx3/37tg/SsJzZiKelMQTGVQvYviHFxLA1OUzrHyw31hM77YpmLN8 TkdqvT9ZzKGm8p1QbR8Dr/iS4IqSyB+KWyZwinMUCYiiZmU3Yg9ZzQ8VEGWTQPDqZJFt ETog==
X-Gm-Message-State: APjAAAWR78i5HJlvabNQ5sB6oR27FlOGcqCPssAAq3VWDuNSi4TdSOkK E512Xop0K5df+ilj6Vv0OjRbZlpop1dD9wfKMDo=
X-Google-Smtp-Source: APXvYqzyulwkhKrswstDGWkJOOnMO+SFpPOo7z6mZeSLprNS6RFUPt4cjwLiY+81o5yoVMDE7Hm/biuM0E3d0BYaCQw=
X-Received: by 2002:a05:6602:22ce:: with SMTP id e14mr7572778ioe.290.1565903024606; Thu, 15 Aug 2019 14:03:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <20190815163938.CF9CB85D108@ary.local> <> <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Thu, 15 Aug 2019 14:03:17 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000088dd0205902e35be"
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 21:03:49 -0000

Hi Erik,

Thanks for your reply.

On Thu, Aug 15, 2019 at 1:25 PM Erik Sy <>

> 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:
> >
> >     First, clients are only allowed to send application data over an
> >     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.
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.

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

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

> Subsequently, if the connection does not provide
> server authentication, the client evaluates a fallback DNS record
> 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.



Thus, I do not understand why an
> interdependence with the ticket lifetime is created.

> Erik
> >   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.
> >
> >
> --
> Resolverless-dns mailing list