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

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Tue, 21 August 2018 15:34 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.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 E574E130E76 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 08:34:49 -0700 (PDT)
X-Quarantine-ID: <pMQg7N82zWvz>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "To"
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.999] autolearn=no autolearn_force=no
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 pMQg7N82zWvz for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 08:34:49 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A1C130E45 for <dnsop@ietf.org>; Tue, 21 Aug 2018 08:34:48 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fs8g9-0000GpC; Tue, 21 Aug 2018 17:34:45 +0200
Message-Id: <m1fs8g9-0000GpC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
From: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@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>
In-reply-to: Your message of "Tue, 21 Aug 2018 17:01:17 +0200 ." <63b113eb-9372-b622-b346-5d926f0b5d9a@nic.cz>
Date: Tue, 21 Aug 2018 17:34:44 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eEEcesYO6e2FoimluncKfEHGufA>
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 15:34:50 -0000

>Then you have a problem that's not solvable in DNS itself (yet).  That's
>what people usually forget to consider.
>
>The hostnames are clear-text in https hanshakes (so far), and it seems
>relatively easy to collect those.  So, by tunneling *only* DNS you don't
>make it much more difficult for the ISP, and in addition you share the
>names with some other party.  That doesn't sound very appealing to me
>personally, from privacy point of view at least.  (On the other hand,
>big resolvers will have lots of cached answers, etc.)

This is too some extent a chicken and egg problem. Without encrypted DNS 
there is no point in encrypted SNI and vice versa.

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.

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

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