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

Ted Hardie <ted.ietf@gmail.com> Fri, 16 August 2019 20:29 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 D10F41200F5 for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 13:29:30 -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 0pF8vuev50lL for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 13:29:28 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 562AB1200C5 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 13:29:28 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id 18so8758639ioe.10 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 13:29:28 -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=3q33XgZTG+flkN52AMmXnkxSUZLYimpFwzJhW03tuXs=; b=DB2auFAVEQYsNltuUCc7IcUJv3knM4GbIXHxKItWDunBYc9BULHVozqyJoGIzonEwV TvBi6Xtk1gBTdGJCCGC7aqKJA85/gK/29tLFnGHrCYlCLtVfawxAW3vYmLFrruM8rgCi cPQznS6z7n6wm05opI1ZlCaTqxPsnugEG6E7Y9IjWK1NHwCSX9hiNZ/N9aXi8rAHOdFJ WJhbuK5Ssz/gOIHeEoHqJLOLEx41RslOgp2sJEhX9XxBn+WB73IK7+zlt8EQd7hvdo7n tj+AFNFukxNQYSlr8g78P2EO+2mzTiDG2aNiASj1FWZpnU/YJHbpjKObLHzbuB29Ai2O A4tg==
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=3q33XgZTG+flkN52AMmXnkxSUZLYimpFwzJhW03tuXs=; b=eCxJkxidoFOcInQO8xLzoP2UwlcK7gMIcFmP7eeputzDlNC9LtZouU0WtZkasTPPyz GsFyC1wpjV/fe9iKj+ENq0vk7eZNeo0wav5mqPB/gR2pc4nsEViH54KTElbBfQ5/eVz9 DcrMfRhzUsnANuTFfx7brmQ1j94bo9M8iUAfLG9sNKkAckP2r/wRrJ4ynsAfcrNQdVVV sfFYeAIrYV2pOMUjX9bSHw/kGERhRMINE65z3HtVG9JP8Ck6KxKgyaejQnVFbD7pdJ86 9eHj9UowoKTF0MEw97c+JkOnA5WuVeUGiNXUZ04ch4lD0/Si+mCiSDJL7B8K5QMKIqxJ rp9w==
X-Gm-Message-State: APjAAAUVfLV673BRofpv6vcGDs34nIEA8E45fAv7vLtrqrj3FgVYzqYP 8kqwKjGSbK6ATImp4SGM0TbHpB2V11tCEJMYJORxwg==
X-Google-Smtp-Source: APXvYqz7GsPljpNcR3Nv/fD7XzMmzrjM7PL1LeqCi9oi7WivzsLkI7j3XsM3NFzKJcRg0KxEE6W+vo60et+bp/qmHfU=
X-Received: by 2002:a6b:790d:: with SMTP id i13mr12537847iop.27.1565987367399; Fri, 16 Aug 2019 13:29:27 -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> <CA+9kkMBLJPzgadJN3sFVoRKB7Zb=z0-Sxm3t2F1Pv8RM0PGoAA@mail.gmail.com> <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de>
In-Reply-To: <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 16 Aug 2019 13:29:01 -0700
Message-ID: <CA+9kkMALH_mcjcG0hQJyHkE0OpQNMzSE4G5pBR=XcxzmdOorYQ@mail.gmail.com>
To: sy@informatik.uni-hamburg.de
Cc: resolverless-dns@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c1b6d1059041d8e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/ksqFPcgTaYPx10Uvbuw7NBLnW9g>
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 20:29:31 -0000

Hi Erik,

Thanks for the time you've taken with your replies.  It appears we simply
disagree, as I believe the measure does increase the attack surface,
especially in the cases where the measures to limit the supplied records
are not (for example, I think "same browser tab" is too lax).  I appreciate
the opportunity to discuss this, however, despite our disagreement.

regards,

Ted

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

> Hi Ted,
>
> On 8/16/19 17:50, Ted Hardie wrote:
> >
> > 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.
>
> Today, websites can already learn something about the interest of their
> clients in specific resources. For example, search engines learn which
> results a client clicked by providing the client redirects instead of
> direct links. Thus, I think the described attack surface does not
> increase with respect to links directly provided by the website
> supporting resolver-less DNS.
>
> Beyond this, I describe in Section 3.2.2 of the paper restrictions for
> DNS records retrieved via resolver-less DNS. Here, it is recommended
> that user agents restrict the use of unvalidated DNS records retrieved
> via resolver-less DNS within the context of the same website or possibly
> the same browser tab. This measure prevents the described leaks beyond
> the applied context of a website or browser tab. Thus, I do not agree
> that resolver-less DNS contributes to the described increase in the
> attack surface.
>
> Erik
>
> >   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
> >
>
> --
> Resolverless-dns mailing list
> Resolverless-dns@ietf.org
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>