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

Ted Lemon <> Sun, 19 August 2018 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FF15130E16 for <>; Sat, 18 Aug 2018 19:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UMAsUc6r1yPc for <>; Sat, 18 Aug 2018 19:43:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6262C128B14 for <>; Sat, 18 Aug 2018 19:43:48 -0700 (PDT)
Received: by with SMTP id w11-v6so9969941iob.2 for <>; Sat, 18 Aug 2018 19:43:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Sat, 18 Aug 2018 22:43:06 -0400
Message-ID: <>
To: Paul Vixie <>
Cc: Marek Vavruša <>, dnsop <>
Content-Type: multipart/alternative; boundary="00000000000015a1cf0573c0c395"
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 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 <> 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