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

Ted Lemon <mellon@fugue.com> Tue, 21 August 2018 16:26 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 F0BA1130DC2 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 09:26:14 -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 ko4zaY79pAo3 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 09:26:12 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 011D9130EBA for <dnsop@ietf.org>; Tue, 21 Aug 2018 09:26:11 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id 72-v6so4936992itw.3 for <dnsop@ietf.org>; Tue, 21 Aug 2018 09:26:11 -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=p+aNUSpCmynxUNUDddD92iMWsF1kgTBmsO4tHbvpTMo=; b=YCQFWfz2B8GeB10xF7IXH34Mc0z6LxMVUY+TtNWQu33kx+cGcIWXg3tWWqjd4i5Hs1 HUT2ZVwPiLs4akKMzGOVWpjxfcRNjU4FZUQKLJ0A6260Kt9a5hLz8KbhDiB/YMvkV8/s CeCQW8rTktlcjre01Ds8pnR+RrP3LcHmz1G93gTrocf2bXWHVPNbG38vYKMU4wxSpVyJ 95sNe6J5waI3XyMFpqD0XhO0JUHHjLdBwjeGKE0vM4cQhvVvb11Gs2O1m9+ojD9D/i6d 2Auo2533XqjDXqsRW9b3nW10PnLYnSBg4dFDQHs0WETFlmsMVpbKGovwVIFhM72CPnkK UKRQ==
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=p+aNUSpCmynxUNUDddD92iMWsF1kgTBmsO4tHbvpTMo=; b=kHxM7SWXOzU8jpqBXIyr1jxSX2h5SSp21rJfjADiVAK3YNuuU+TSFr4Kmx1n1FEFw4 RP9mx1YIm1xyPPqKJ5cnzwLyWDhwOof0EXuMiDI9Fvh1aKwuopnfr4Dg/EMFYNRixzjk gURkiJ06Ic03/kBxBVA38/5ruIq7JQYIm8XW5kCmf3Ft/gf344Mu9T6EoVI1IBqdNGgy fzbZ72GKrtl33prD/hVhuC73n9h/ErvuSuBVmPeXZRC8SHQYWBd+xWQrs+uuzsNyy6er cR+eZt3OmovLs8sowvQzyLnR+k+jqZ9UNzThWKY3ELmalF+vy8gpcsKF1NMfN0zeWOKy JPdw==
X-Gm-Message-State: APzg51ByQANZI38lmEIFCBBDFyeTYEGzb50myX2fR4+Vv9VQ8bktLE0s IUlfPaJ9smyS+3tk/N61uTfC9290gpR1y7l3MZyrgQ==
X-Google-Smtp-Source: ANB0VdZJEFJRt0P9SsRU8P2bgJ31nOhzNawMikBeoIwLFsMK/t4SIO4W20iLfcYdQEqH7SucDQUygHsjjVxken9cxM8=
X-Received: by 2002:a24:374d:: with SMTP id r74-v6mr54504itr.57.1534868771177; Tue, 21 Aug 2018 09:26:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 09:25:30 -0700 (PDT)
In-Reply-To: <20bfadaf-05bf-d564-9c90-bd1464b23328@nic.cz>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com> <471139805.18285.1534847636363@appsuite.open-xchange.com> <m1fs7wB-0000GtC@stereo.hq.phicoh.net> <63b113eb-9372-b622-b346-5d926f0b5d9a@nic.cz> <m1fs8g9-0000GpC@stereo.hq.phicoh.net> <20bfadaf-05bf-d564-9c90-bd1464b23328@nic.cz>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Aug 2018 12:25:30 -0400
Message-ID: <CAPt1N1k0fYZMgLqmmPjc7obJ1_NnsA24+mRPgMg2a4AMwhJxFg@mail.gmail.com>
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Cc: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>, dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2140a0573f47b8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Pb3hAiKpXPdzaSYaxZ25vJwcPo4>
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: Tue, 21 Aug 2018 16:26:15 -0000

DHCP is automatic, so the question of what to do when you have
configuration information that conflicts with DHCP needs to be addressed.
 It isn't "simple" simply because it addresses only one specific use case.

On Tue, Aug 21, 2018 at 12:19 PM, Vladimír Čunát <vladimir.cunat+ietf@nic.cz
> wrote:

> Ehm, we somehow forgot that this thread is supposed to be about DHCP, so
> that's only the "uninteresting" case where you do trust the ISP and want
> to use their DNS over a secure channel :-D
>
> On 08/21/2018 05:34 PM, Philip Homburg wrote:
> >> Then you have a problem that's not solvable in DNS itself (yet).  That's
> >> what people usually forget to consider.
> >> [...]
> > This is too some extent a chicken and egg problem. Without encrypted DNS
> > there is no point in encrypted SNI and vice versa.
>
> Yes, partially.
>
> > I expect that encrypted SNI will be relatively easy to deploy. It can
> happen
> > as soon as both endpoints support it.
> >
> > In contrast, DNS is a very complex eco system. So it makes sense to start
> > deploying encrypted DNS now, under the assumption that encrypted SNI will
> > follow.
>
> Well, DoT has been standardized for some time, and we now have multiple
> open-source implementations for client- and daemon-side, and some large
> public services support it.  DoH is a little later, but it might gather
> more speed eventually.  From *my* point of view the SNI is the biggest
> hindrance ATM; other technical issues don't seem bad, at least not for
> most motivated users.  (Finding a trusted service might be problem for
> some people, I suspect.)
>
> >> After SNI encryption gets widely deployed, tracking through IP addresses
> >> only will be somewhat harder, so there it will start getting
> >> interesting.
> > We have seen already that 'domain fronting' is can be a very effective
> way
> > to bypass filters. For large CDNs or cloud providers, filtering based on
> > IP addresses is not going to be effective.
>
> Centralizing most of the traffic to a few CDN providers would solve
> that, but somehow I don't think privacy should depend on that.  And I
> don't think it's so easy to significantly reduce the information leak -
> you just *move* it to somewhere else (someone else), and it's not really
> clear to me in general who is more trustworthy.  Still, such
> possibilities certainly are nice to have.
>
> >> Until then, IMHO you just need to either trust the ISP or
> >> tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted
> >> party.
> > True. But we can take small steps to reduce unwanted interference from
> ISPs.
> >
> > From a security point of view, it helps a lot if you can just trust DNS.
> > Instead of always having to take into account that somebody may
> interfere
> > with DNS replies.
>
> Defense against changing DNS is something else than privacy - we have
> DNSSEC for that, so you don't even need to trust the server sending you
> the data, but I think we're getting too much off-topic anyway...
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>