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

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Tue, 21 August 2018 19:43 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 23324130ECC for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 12:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 8IvZEO0QoR0Z for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 12:43:22 -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 9EB55130EC5 for <dnsop@ietf.org>; Tue, 21 Aug 2018 12:43:21 -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 m1fsCYi-0000GnC; Tue, 21 Aug 2018 21:43:20 +0200
Message-Id: <m1fsCYi-0000GnC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
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> <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>
In-reply-to: Your message of "Tue, 21 Aug 2018 18:19:39 +0200 ." <20bfadaf-05bf-d564-9c90-bd1464b23328@nic.cz>
Date: Tue, 21 Aug 2018 21:43:19 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/voZ94wBKfKhJWdVTnB3QxhVEuGM>
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 19:43:23 -0000

In your letter dated Tue, 21 Aug 2018 18:19:39 +0200 you 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

There are still plenty of use cases. An ISP may not want to run a recursive
resolver and instead refer to a public resolver using DHCP.

Additionally, on an open wifi, encrypting DNS traffic can help against 
snooping. So it is in the ISP's interest to announce that the local
recursive resolvers support DoH

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

For DNS, code is not enough. You need to get admins of recursive resolvers
to upgrade. And there are lots of those resolvers. Many of them almost
unmanaged.

DNS is for a large part not end-to-end. You have the recursive resolvers
as middle men.

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

DNSSEC is part of the puzzle, but leaves a lot of holes:
- Currently very few systems ship with locally validating resolvers. So
  most systems can be attacked on the last mile.
- Many domains are not signed for one reason or another. 
- Even with DNSSEC, an on path attacker can see the queries and selectively
  mount a denial of service attack.

DoH protects the last mile from all of those attacks.