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

Paul Vixie <paul@redbarn.org> Sun, 19 August 2018 01:57 UTC

Return-Path: <paul@redbarn.org>
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 DACB7130EC2 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 18:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhsxM8tukU5x for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 18:57:29 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E9A130EAE for <dnsop@ietf.org>; 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 family.redbarn.org (Postfix) with ESMTPSA id CEE3B892C7; Sun, 19 Aug 2018 01:57:27 +0000 (UTC)
Message-ID: <5B78CE86.8030004@redbarn.org>
Date: Sat, 18 Aug 2018 18:57:26 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: =?windows-1252?Q?Marek_Vavru=9Aa?= <mvavrusa@cloudflare.com>, dnsop <dnsop@ietf.org>
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> <CAPt1N1nEH86yPvtoNqJ+xM-OFunEqr2x8s2LV_yFU1fkVt9WUQ@mail.gmail.com> <5B78C60E.4010307@redbarn.org> <CAPt1N1kxspYrAHF_L57im+W_5qVV=gYjg4ObVMwpQj60ASnL4w@mail.gmail.com>
In-Reply-To: <CAPt1N1kxspYrAHF_L57im+W_5qVV=gYjg4ObVMwpQj60ASnL4w@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PDTG3ZvEpbl97IcasmnY48NvMoY>
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: 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