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

Ted Lemon <> Mon, 20 August 2018 02:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46AEC130DD9 for <>; Sun, 19 Aug 2018 19:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 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] 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 Z85cZz3mrCWu for <>; Sun, 19 Aug 2018 19:17:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A47D3130DD7 for <>; Sun, 19 Aug 2018 19:17:55 -0700 (PDT)
Received: by with SMTP id e14-v6so18591063itf.1 for <>; Sun, 19 Aug 2018 19:17:55 -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=fB0gcX6EX+p2nrShYFJor1b4l9+DwvOFgjbgpLvLXS0=; b=1eo6gnrR38frsGHiKPcLBYB95/dCNyJufK2Ocg/UrQFx0+sp2EnQMAHRJFdDXk8EpX LPJ/fOioE+0KatDsI7BsZMkb3Dcfz/zGs4eU90ez+2GwSo8srmoW6BTqYFO7TXIbo0hO zlfnZRWjgqgJTP+YysZoTIQm/0y+bVN3yRfqqpfNgma6P/9yHk71knNeJyetZ3CaHoCX z10LXrqtz0kyKyXvOSd01HZNOGlVNZmcR18dnUiP7IMkjS5pJYZ0/THJ4EwHzu4wY4Kf NW9pYjtyBvjOvFJ6d0u9QOc9TKF/44oMdMjnMFlZeSeiVY+lZbXVWZt7zUXpLuwVDx7W C6GQ==
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=fB0gcX6EX+p2nrShYFJor1b4l9+DwvOFgjbgpLvLXS0=; b=jNZbyFjDigOsF2Wy6yfZELtXUu/CD84SVBwKmRsUpaP3sNzcBSVP9d0Y1o2ejrCmtT iNnqEBO7XdBNyrBUokfJunRWfvedI3wcaVcjQKV6OcwcQKczJQ8yJh/vO/qEIjh1arqo WUmcLqBu+xbTQpRpOZZ3VIfGRFwiq/77Y5nz3o8Fs9nNgM7xKZX+Dl7Sgxmy6hsFMghw iXUAVzQAK7n2gHb7HLphfaKQ5cBh717+M1L8Zuh4J0QTLtO3f6AZlD5NTRt5ZLU0pe7N s+KrEZ2OLmYeIeRfIqh8t7+Xbjw6T1OQPJo4tVRxzavgFYYD8ScdwvT8++J9BIwU8aJ1 /mPA==
X-Gm-Message-State: AOUpUlGJwR74umzz0uhz9G2p6s+fm13QxXBH4rTvl0F62fx0ZXcvLFIM jqFCbI5IbgMEtplKoKFZFd8D2GpcvrTApYKoMmvYLWkR
X-Google-Smtp-Source: AA+uWPwtTSXrtFruYKIi6+JW93MUD8Z5yrTS8lrylhAT6qA3zACoaXKNZLxdfxSyU0g3efIslQAmHAmxqwpgTCFR75I=
X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr37391330jad.38.1534731474737; Sun, 19 Aug 2018 19:17:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 19:17:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Sun, 19 Aug 2018 22:17:14 -0400
Message-ID: <>
To: Doug Barton <>
Cc: dnsop WG <>
Content-Type: multipart/alternative; boundary="00000000000060b4c70573d484f4"
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: Mon, 20 Aug 2018 02:17:58 -0000

No, I think maybe I haven't been communicating as well as I should.   What
I have been saying is that we need to decide what our threat model is, so
that we can figure out what to recommend.   What you are saying is "we
should recommend this."   What you are proposing to recommend has a
perfectly valid threat model associated with it.   I'm just saying write
that up, don't just leave it unstated.   Let's get clarity on it and decide
that we're okay with it, or not, before we write a standard based on it.
 I don't think this needs to be a heavy-weight process—I'm just objecting
to the handwaving.   And to be clear, the model that Paul has been
advocating actually is not what you just said—it's a different, also valid,
threat model.   The problem with Paul's model is that it assumes a user who
is able to reason clearly about threat models; I don't think we can do
that, and I would object to a spec that was based on that threat model.   I
think we need to do that work, and not leave it to the user.   We've all
seen what happens when you demand that users be security experts.

On Sun, Aug 19, 2018 at 8:28 PM, Doug Barton <> wrote:

> On 08/19/2018 04:57 PM, manu tman wrote:
>> On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon < <mailto:
>>>> wrote:
>>     A user who relies on the dhcp server for dns server info is no worse
>>     off. The problem is that if your host lets the dhcp server override
>>     the DoT or DoH configuration you entered manually, you are a lot
>>     worse off.
>> This seems to be a static vs dynamic setup. Either you use dynamic and
>> you will happily accept what you get from DHCP and possibly upgrade to
>> (HTTP|TL)S or you have set your resolvers statically and you are already
>> ignoring the nameservers provided by the DHCP server.
>> If you do not accept the servers provided by DHCP, there is no reason you
>> would accept extra attributes for those same snameservers.
>> Manu
> Yes, those are my thoughts precisely.
> I don't see a risk model where a user configures DOH or DOT servers
> explicitly, but does not disable DHCP configuration for DNS. Am I missing
> something?
> _______________________________________________
> DNSOP mailing list