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

Ted Hardie <ted.ietf@gmail.com> Thu, 15 August 2019 21:03 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2321200DB for <resolverless-dns@ietfa.amsl.com>; Thu, 15 Aug 2019 14:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvNWeoVUfvLg for <resolverless-dns@ietfa.amsl.com>; Thu, 15 Aug 2019 14:03:45 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A831D1200C7 for <resolverless-dns@ietf.org>; Thu, 15 Aug 2019 14:03:45 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id q22so1994166iog.4 for <resolverless-dns@ietf.org>; Thu, 15 Aug 2019 14:03:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <20190815163938.CF9CB85D108@ary.local> <CA+9kkMDtGt0hMPv1szjoLuHsO1h5wPrsY-5LkJdDU5FcVKFSkA@mail.gmail.com> <d32e9589-c9f7-593d-b0f6-0e842a461c43@informatik.uni-hamburg.de>
In-Reply-To: <d32e9589-c9f7-593d-b0f6-0e842a461c43@informatik.uni-hamburg.de>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Thu, 15 Aug 2019 14:03:17 -0700
Message-ID: <CA+9kkMCg3ohS4fLzR6DznFQEZnZkn3ZvAg995C-XpovMvb5NWw@mail.gmail.com>
To: sy@informatik.uni-hamburg.de
Cc: resolverless-dns@ietf.org
Content-Type: multipart/alternative; boundary="00000000000088dd0205902e35be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/FzJMLvtI470A_Mg-gQ7JuFsVKQ4>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=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 <sy@informatik.uni-hamburg.de>;
wrote:

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


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

regards,

Ted


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
> Resolverless-dns@ietf.org
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>