Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ted Lemon <mellon@fugue.com> Sun, 19 August 2018 19:36 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3A5130EA8 for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 12:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 WNub9U9uwXn1 for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 12:36:46 -0700 (PDT)
Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 3DDE0130EBD for <dnsop@ietf.org>; Sun, 19 Aug 2018 12:36:46 -0700 (PDT)
Received: by mail-io0-x243.google.com with SMTP id w11-v6so10929779iob.2 for <dnsop@ietf.org>; Sun, 19 Aug 2018 12:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dRWntwKMr+CKXMAWCZUXRr+jtwv8Lv5s0PAveLMuEt4=; b=kHCiwFKkqooAmdHBzHFOiKNKBgeJ2Z/I02gnhlPXJiU+GpaT9ZlxnQ2Bi8UtRz9EoR LjJxkjsh/YfiuL9eQcV5p4CWdKvAcRb0A7O0ERPITN1UCVFXjIgYTndNkRfnNEllRvSh YIc+/kb3etRgQ4X8ZBw2qNceZ/vtr4um9he2/8qXFUd9mT+e+5zsGX+z1q0433UfW4qb PaL/E11QLaRdA5jTG4TMn8xtFoSvQ38IJEY18Q2zvsb11B1pmoJoZfs3NqZwnDVe6Glz 6P5z3v7aKWlJhwgDOfH6GgZ9FMaGdVvExX7ACppvo5D5LLompQ/w4lM2UxvKVoELbZW/ aj/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dRWntwKMr+CKXMAWCZUXRr+jtwv8Lv5s0PAveLMuEt4=; b=o9tJink+qDmpwydoai0fX50v4epjMTi+gi/OEezhucHPV58paP5A1ZCLmK2QFcTVmF OXGiaypPoCfm9b1wbhv2CXCJTRQ/CjTyBcw9dWI+ZuE52vJdyW0ZOcGwuW0coMdWA4WA ybQ3LPFrhCMgtUhPP5J8LYwG356VOLiZtiOKaAXDHCqVkKdeTHSkXANY5JCLqVNltW8G RZhM/mCvgsWVtsJzP+LHDDCjTLwdB1El6OAByLi7fquuCT6bxw1NXPtx/leCX7UhAXcb wYcMSb+K9Vdh+kOSnIMOdjJFoVRvbmvygqh4qqp8j12Kk71F0MR8X76lFMNE987jkuUz J0Tg==
X-Gm-Message-State: AOUpUlFAeMJcGqbckjDy6ac3wTVa6FXF4PvMlbOk1974BnBPo/c6u5Eh LV+hXp2hgwWCqQk4UAFG4D+bwLqs4K4XABtTE3BG3w==
X-Google-Smtp-Source: AA+uWPxwSQfQTw0iCFG5AHTkrUaKWq2H+vidL7ZCLP1aU495FCuSsNZjc9/SgD9jv5wt0TVPGH6sp7ovzj6C+asTTDA=
X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr35932828ioc.45.1534707405303; Sun, 19 Aug 2018 12:36:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 12:36:04 -0700 (PDT)
In-Reply-To: <CAC=TB11vqikV_xjBtX0K9kiYO7DUEEJZu_MCgnOeZSzT=Lkffg@mail.gmail.com>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <20180818230319.GA32131@server.ds9a.nl> <5374C85A-D26B-4B20-817D-5363F9807C2B@cable.comcast.com> <90828859-A7C0-462C-8772-58FB143A871A@bangj.com> <CAC=TB11vqikV_xjBtX0K9kiYO7DUEEJZu_MCgnOeZSzT=Lkffg@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Sun, 19 Aug 2018 15:36:04 -0400
Message-ID: <CAPt1N1mDpHRRKJfk80_Dhe5W1YaOKTg-byAkXkvN-9DM2mxFSg@mail.gmail.com>
To: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa@cloudflare.com>
Cc: Tom Pusateri <pusateri@bangj.com>, "Livingood, Jason" <Jason_Livingood@comcast.com>, bert hubert <bert.hubert@powerdns.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ba4cea0573cee9db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2CWOZwxfW9br5Au-_uqJpObGUO4>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Aug 2018 19:36:49 -0000

That may indeed be correct.   If it is correct, then the next step would be
to try to design a trust model that we can agree on, that addresses both
use cases rather than requiring us to choose one or the other.   E.g., we
could say that if you are Chinese, then your device is required to trust
the GFWoC; if you are not, and you never go to China, your device should
not trust it.  If you aren't Chinese but you travel to China, you should
probably be asked to make a policy decision.   And now when the network
operator hands you a DoH or DoT server, you should be able to validate what
you've been handed.   Am I willing to trust Paul Vixie's network?   Then I
can configure that, and then when I am on Paul's network and his network
hands me a pointer to his DoH server, I'll use that.   When I'm not on his
network, I won't.   Right?

On Sun, Aug 19, 2018 at 2:46 PM, Marek Vavruša <mvavrusa@cloudflare.com>
wrote:

> Interesting. This approach is similar to the lists curated by Frank
> and people from dnscrypt-proxy: https://dnscrypt.info/public-servers
>
> Assuming that separating protocol change from trust model change is a
> no-go, then the trust would need to go both ways - the network
> operator would need to push the list of resolvers that she considers
> trusted, and the client would crosscheck that list to its provisioned
> configuration (or list downloaded from a public service such as this
> etc.). This is conceptually similar to NPN/ALPN.
>
> Marek
>
> On Sun, Aug 19, 2018 at 11:35 AM, Tom Pusateri <pusateri@bangj.com> wrote:
> >
> >
> > On Aug 19, 2018, at 9:29 AM, Livingood, Jason <
> Jason_Livingood@comcast.com>
> > wrote:
> >
> > On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert"
> > <dnsop-bounces@ietf.org on behalf of bert.hubert@powerdns.com> wrote:
> >    Especially when such a move will incidentally kill intranets, VPNs,
> split
> >    horizon, DNS monitoring & DNS malware detecion and blocking.
> >
> > It seems to me that the underlying protocol is separable from the
> > operational implementation, and the latter case is likely where most of
> the
> > concerns lie. Thus, the issue is likely less DoH itself but rather how
> it is
> > likely to be deployed.
> >
> > I am considering starting work on a draft along the lines of 'potential
> > impacts of DoH deployment' to try to document some of this, if for
> nothing
> > else than to organize my own thinking on the matter. This is because I
> also
> > share concern, given the apparent deployment model, around what may
> break in
> > enterprise networks, malware detection & remediation, walled garden
> portals
> > during service provisioning, parental controls, and the impacts of
> > eliminating other local policies. The CDN-to-CDN competition case is an
> > interesting one as well, with respect to passing EDNS client subnet or
> not.
> >
> > JL
> >
> >
> > In the DRIU BOF, I mentioned establishing a reputation service for public
> > DNS resolvers. With a JSON interface, this could lead to users conveying
> > some trust of a public service or more likely, the inverse of trust for
> > operating systems or stub resolvers to whitelist/blacklist public DNS
> > resolvers.
> >
> > I tried to summarize it here:
> >
> > https://dnsdisco.com/reputation-post.html
> >
> > Or you could go listen to the proceedings of the DRIU BOF.
> >
> > Thanks,
> > Tom
> >
> >
>