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

Ted Hardie <ted.ietf@gmail.com> Fri, 16 August 2019 15:51 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 1B184120824 for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 rgBUeKWRutPq for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:51:09 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 0F42912029C for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 08:51:09 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id j5so7105298ioj.8 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 08:51:08 -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=GX08mOwtrfEyzcHOsEOsOv2bDBnnmbFS+LDZhhX2Kq4=; b=tUOQiatE/HUb5xzqCY1vQWfKMOIcX1hq1g9sIOWL3VXy4SfBYYGZdQG5IpXctEq9PW XGQhV1fbx4OJE/irVjalSPW0qQWJAEgS9kPkSDmiAV7RqJLWS4ycG34JeEnucqWXqAvU PojW/azHgcIsEcFIehlnzPr+I/HHozeVrSh1QOOBoOPuITT4jc8CPEuzO5MirP6kOxap DY1RHC9V+v+FLDC74AcqjZHqidVKSltXPebhLxqtucRG+Lu5fMSoc+vKsHKZxSYxnozb RDsc76LfcsWPECj1ykYNm2RYW5bS+gg+8m/W/hxQtwMdUW+GY9p8yLy3q23G7nGhWwdF YtpA==
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=GX08mOwtrfEyzcHOsEOsOv2bDBnnmbFS+LDZhhX2Kq4=; b=abZFgnzvVQDfNWfV+zDD4ThSesitooGObm7c1cGF5EFB+8AQ+uddsk+/PAAqIJeFqZ m2ZPoSIiH777ruZS9vkjxZIbIRteMsR3Q68NtoFCYGeuYX/czTAdaP66x6S+E07I4r8T hg0tYALzQn1rPankiYIcaCKQQhvsRfQrbtHLJ8Pgcpfg/lgY+rboIZ5xMag/1u5bgVfu Jjg+ctMkCMU/1cMAtWH4FS5QOy4LQbf9PH9Upke3bCl+yMrLr6fm5Ds4NatEXyZQrWIJ U3RvmeQzifHhTcd9aSz4nzIphbR3NONCKcbs9msTrA2fK5JnyXqVMFNwZTs2Wi3Qx6oW 23Zg==
X-Gm-Message-State: APjAAAW7DgNZr0XBfDnNVv8zoFXG8FlYG/OrPItOnxToFz95Edma4lr1 b4+5raE0CD/1JAWFswnCQDU3LLLBNHRCuB6UOoU=
X-Google-Smtp-Source: APXvYqzhmlFERBR9foPoPcR0u5otsPpMiR57RQmS41qhvvu/hwgHAw/jHuSwvcS7+8yJ8hTsssvBreRvQY/XpwRMhUM=
X-Received: by 2002:a6b:720e:: with SMTP id n14mr12311409ioc.139.1565970668007; Fri, 16 Aug 2019 08:51:08 -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> <CA+9kkMCg3ohS4fLzR6DznFQEZnZkn3ZvAg995C-XpovMvb5NWw@mail.gmail.com> <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de>
In-Reply-To: <470d23bf-92f2-6e92-60ed-3adea1a5efad@informatik.uni-hamburg.de>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 16 Aug 2019 08:50:41 -0700
Message-ID: <CA+9kkMBLJPzgadJN3sFVoRKB7Zb=z0-Sxm3t2F1Pv8RM0PGoAA@mail.gmail.com>
To: sy@informatik.uni-hamburg.de
Cc: resolverless-dns@ietf.org
Content-Type: multipart/alternative; boundary="00000000000065356305903df5d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/J1GXwvB-fmXGW3IR-AyRzAOxFsI>
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: Fri, 16 Aug 2019 15:51:12 -0000

Howdy,

On Fri, Aug 16, 2019 at 12:28 AM Erik Sy <sy@informatik.uni-hamburg.de>;
wrote:

> Hi Ted,
>
> On 8/15/19 23:03, Ted Hardie wrote:
> >
> > 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.
> Ok, we can include this into the privacy discussion of resolver-less
> DNS. In detail, an adversary providing tampered DNS records for a
> specific hostname can possibly learn that the user agent had established
> a connection to this hostname in the past. A successful attack requires
> the user agent to posses valid state of that prior connection allowing
> an abbreviated connection establishment such as QUIC source address
> tokens or TLS session resumption tickets.
>

Yes, this is true, but I thought you asserted that it would
opportunistically attempt to use the provided records.  That means it could
also leak the interest of the client in a specific resource to a
potentially malign collector at the instigation of any web site providing
the malign DNS record; that's the increase in attack surface for the
existing attack.  At the very least, that appears to require clients to
cache where DNS records came from in their cache, so that they can build a
reputation for sources that supplied bad data and ignore data from sources
that gave bad data.  That's a far from perfect mitigation, of course, but
it helps some.


> >
> >  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.
>
> The problem you are describing is not introduced by resolver-less DNS.
>

Agreed, but it also can't be ignored that the new source of supplied DNS
records gives a new opportunity to line up the facilities needed for a
successful attack.

regards,

Ted


> The fact that the client may receive a server authentication from a CA
> not intended by the domain owner applies also to the traditional DNS. As
> mentioned earlier, I think attacks assuming a broken PKI cannot be
> effectively mitigated by DNS.
>
> Erik
>
> >
> > 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 <mailto:Resolverless-dns@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/resolverless-dns
> >
> >
>
> --
> Resolverless-dns mailing list
> Resolverless-dns@ietf.org
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>