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

Doug Barton <> Mon, 20 August 2018 05:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47CBA130E27 for <>; Sun, 19 Aug 2018 22:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qDq9kItruO1E for <>; Sun, 19 Aug 2018 22:53:49 -0700 (PDT)
Received: from ( [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65D86130DE9 for <>; Sun, 19 Aug 2018 22:53:49 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 079DB79C for <>; Sun, 19 Aug 2018 22:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1534744429; bh=Dsnmh8l2NVZ3ZKWnBkVA4wrAYm8jRIakjO2lJ8luiX4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kdOK0Ojjrw3JoP3vJGKk3YrwuXRMYvZD3ZdI5jmMNCp7Ww9DMpA5uh3o5dP53j3qn C7Nh8JnTLdZEed/YsZGnxLmMReGEsOrsizVb+jaWstfepVdfHkKOeSb7xnSWmo/l+l R2itt3aQKP6z9lQFBB9UOE4nJng9AWgUffmpB4QI=
References: <> <> <> <> <> <> <> <> <> <>
From: Doug Barton <>
Message-ID: <>
Date: Sun, 19 Aug 2018 22:53:48 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
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: Mon, 20 Aug 2018 05:53:51 -0000

Resorting to in-line responses to reduce the amount of talking past each 

On 08/19/2018 07:17 PM, Ted Lemon wrote:
> 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,

You've been very clear on your numerous repetitions that this is your 
perspective. I and others have quite clearly disagreed with that. Please 
don't mistake lack of agreement with lack of clarity. I understand your 
argument, I just don't agree with it.

> so that we can figure out what to recommend.   What you are 
> saying is "we should recommend this." 

No, I'm definitely NOT saying that. I and others have expressed surprise 
that you feel that the existence of a DHCP option constitutes an 
endorsement. I've been in the business over 20 years, and have never 
heard this line of reasoning, for example.

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

I think Paul's threat model and mine have more in common than you 
imagine, but I'll leave that aside. What confuses me is the idea that a 
given option can only be deployed to address one threat model. Clearly, 
for any draft the security section needs to weigh the pros and cons of 
the approach.

What it seems like we do agree on is that there is no additional risk to 
the user who would have been relying on the unencrypted resolver anyway 
to rely on an encrypted one.

While your three security models have distinctions to a person who is 
knowledgeable about such things, the only time they matter to your 
normal, non-security-aware user is when they intentionally configure a 
resolver (DOH/DOT or not). If they do this, they are taken out of the 
realm of DHCP resolver options entirely.


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