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

Paul Vixie <> Sun, 19 August 2018 01:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DACB7130EC2 for <>; Sat, 18 Aug 2018 18:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PhsxM8tukU5x for <>; Sat, 18 Aug 2018 18:57:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3E9A130EAE for <>; Sat, 18 Aug 2018 18:57:29 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62] (unknown [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id CEE3B892C7; Sun, 19 Aug 2018 01:57:27 +0000 (UTC)
Message-ID: <>
Date: Sat, 18 Aug 2018 18:57:26 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <>
CC: Marek Vavruša <>, dnsop <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Sun, 19 Aug 2018 01:57:31 -0000

Ted Lemon wrote:
> If you are trusting a "pre-shared key," why not just pre-share the DoT
> server information? ...

because my preferred DoT server may not work inside someone else's network.

> The reason it's not drama-free is because you can't just hand-wave the
> threat model.   What you just said is a fine way for you, Paul Vixie, a
> knowledgeable user, to configure your device, but I can't explain this
> threat model to a typical end user, and they have no basis for deciding
> what they should do.   You mention the GFWoC, and that's certainly a use
> case we need to consider, but we also need to consider the use case of
> the malicious coffee shop network that wants to harvest your passwords.

i thought we'd spent 19 years on DNSSEC to deal with that threat, along 
with DANE and TLS 1.3. if it's still an unsolved problem, then i dare 
say that we won't be fixing it by telling people not to use RDNS stub 
servers that are recommended to them by their address provider via DHCP.

>   I don't know if you have friends who've been taken by this scam, but I
> have, and it cost them a /lot./   So how does my host tell the GFWoC
> from the malicious coffee shop server?   Assume that it can't ask me to
> figure it out—it has to follow some decision heuristic that is
> programmed in at the factory.

when i go to defcon, my software updates all fail, because signatures 
are wrong. luckily, the vendors of my software understand this problem. 
even my bios vendor signs their updates in a way that the recipient can 
tell there's a forgery. i would _not_ expect to be able to mitigate any 
of those risks by changing who i received my DNS responses from.

P Vixie