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

Ted Lemon <mellon@fugue.com> Sun, 19 August 2018 02:43 UTC

Return-Path: <mellon@fugue.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 3FF15130E16 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 19:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 UMAsUc6r1yPc for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 19:43:48 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6262C128B14 for <dnsop@ietf.org>; Sat, 18 Aug 2018 19:43:48 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id w11-v6so9969941iob.2 for <dnsop@ietf.org>; Sat, 18 Aug 2018 19:43:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W8SzseXfZ3TYgYYFvHC/lf3hUw5qRycMknUtAUohuCo=; b=JdOJXDUet3gpnf0t1+VI00KIAaVvlqEe5hGNIbJDnLRSML59jHsK+WHN3+6RXgy10o vmd+YqQQru7JAlD3+38fgajO2ly3t2f1JCMYjBrN2XDOgNe/xLi7FRG57RwqC99YS6Hg owqpjY4UB0UfX/V+ZOIGSMU2AjhnE+6KxzYZgmOsi3G+S/gif/6BSY75Kkr6smLsQbVA iUnnVuCgU88oxu7Vjiz3rKLY+heuyTnfHPfc+kdgUxDuwM1YSky4nNYY8UeRyY8WfF0x GUdZQCIy8v63IsyuS2BdZMyoxkm0G0f2wg2QqgaS2tAVj44ptCaiMjULudI4eABCBrb2 AArw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W8SzseXfZ3TYgYYFvHC/lf3hUw5qRycMknUtAUohuCo=; b=npRKCDnF9ZnJMSrxOADD0A0nPlWFkeaIuhyhfns3UjQQrqZnhpH4ErG3wG18aVFo7S ZicuXJtpV/6WzW8RukmFsJyWTN3+aptOHj31IJa0DWnOui4vCv0vnoCJIqugm0hmI+n1 fA/dJASSCSPOt+oMV8yUoC/h9galmauPFmTiKO+aY3vpmH7V78KyroHr5EpCNOsqLRP0 EtEnC/cDGEWUXO2jxw9H165YyLFOxrwNBp0pmQqOxq+JjlflxMDSWafz4sJZBbp0WNEu 5KX0I0N2rIois4uvUG4oyOpeyKjCzi/AURKxZXG88McpTqrrzlXNta6LhqgNfu35QzT2 +gsw==
X-Gm-Message-State: AOUpUlHncYbLSTayA4coZw/q09MWVcOMWRWxd8rN+CTzYTp9VGvdpXgK 0YKC+S2eotkHkD2g2Mx91DGEWYsJQ8cYQP7rvrcu4Q==
X-Google-Smtp-Source: AA+uWPz4yZWdZJYD8OFEJTNL+KP3RelXxYQEi57piS67octc3fChLt2HecNHIcmQetVokl02FhojB3N5opwk1mRvBAM=
X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr35947393ioe.85.1534646627437; Sat, 18 Aug 2018 19:43:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 19:43:06 -0700 (PDT)
In-Reply-To: <5B78CE86.8030004@redbarn.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> <5B78CE86.8030004@redbarn.org>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 18 Aug 2018 22:43:06 -0400
Message-ID: <CAPt1N1=Mx7Xc7+q2C=96WotJCY9FUVa=ivMRKOn4r9VS9rwRsQ@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Marek Vavruša <mvavrusa@cloudflare.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000015a1cf0573c0c395"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/i-nPsF76U55jcLNV6AWZR4woNWc>
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 02:43:50 -0000

Well, if that's true, Paul, then I guess DNS filter lists are totally
unnecessary and you should stop working on that.   Maybe you already have?

On Sat, Aug 18, 2018 at 9:57 PM, Paul Vixie <paul@redbarn.org> wrote:

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