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

Philip Homburg <> Tue, 21 August 2018 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E574E130E76 for <>; Tue, 21 Aug 2018 08:34:49 -0700 (PDT)
X-Quarantine-ID: <pMQg7N82zWvz>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "To"
X-Spam-Flag: NO
X-Spam-Score: -0.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pMQg7N82zWvz for <>; Tue, 21 Aug 2018 08:34:49 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 73A1C130E45 for <>; Tue, 21 Aug 2018 08:34:48 -0700 (PDT)
Received: from (localhost [::ffff:]) by 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: <>
To: Vladimír Čunát <>
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-reply-to: Your message of "Tue, 21 Aug 2018 17:01:17 +0200 ." <>
Date: Tue, 21 Aug 2018 17:34:44 +0200
Archived-At: <>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

>After SNI encryption gets widely deployed, tracking through IP addresses
>only will be somewhat harder, so there it will start getting

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

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.