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

Tom Pusateri <> Sun, 19 August 2018 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C542130E22 for <>; Sat, 18 Aug 2018 18:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3KEifgacMm_X for <>; Sat, 18 Aug 2018 18:09:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58B46130DD1 for <>; Sat, 18 Aug 2018 18:09:15 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D05F7272E; Sat, 18 Aug 2018 21:05:22 -0400 (EDT)
From: Tom Pusateri <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_69B5ABA6-3806-4265-A3F5-C8547A3A1960"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sat, 18 Aug 2018 21:09:13 -0400
In-Reply-To: <>
Cc: Ted Lemon <>, dnsop <>
To: Marek Vavruša <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
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 01:09:18 -0000

> On Aug 18, 2018, at 8:53 PM, Marek Vavruša <> wrote:
> On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon < <>> wrote:
>> On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša <>
>> wrote:
>>>> You say that your proposal does not impact DoT's ability to address the
>>>> threat model or use case that is the reason it is being used.   But this
>>>> is
>>>> doesn't make sense to me.   The trust model for DoT and DoH right now is
>>>> that they are configured by the user for the user's reasons, or by the
>>>> service provider for the service provider's reasons.   You are proposing
>>> This is the issue that the draft is trying to solve. The service
>>> provider doesn't have a way
>>> to configure DoT on the stub resolver. This problem is described in
>>> What I'm trying to address more specifically is
>> The document explicitly says that it doesn't have a trust model for DHCP.
>>> The "DHCP authentication" does exist, I believe you're referring the
>>> deployment status.
>> No, I'm referring to it doesn't exist.   There is no deployable DHCP
>> authentication.   The DHC working group tried to come up with one, and
>> ultimately concluded that it was not worth it, because the only thing that
>> should ever be trusted from a DHCP server is information about the local
>> network.   DoH and DoT are out of scope for DHCP according to this
>> reasoning.   Bear in mind that we were more optimistic about authentication
>> when we did RFC 3315.   RFC 8415, which is in AUTH48, and which supersedes
>> RFC3315, is not as optimistic, and only provides for authentication using
>> IPsec between server and relay, and authentication for the purpose of doing
>> Reconfigure; this authentication is not sufficient to provide assurances of
>> trustworthiness.   It's about as secure as a TCP sequence number.
>>> I'm happy if we say the draft must depend on RFC3315, or discuss the
>>> trustworthiness of the responses,
>>> but surely there must be a way forward if we want to keep the
>>> recursive DNS (last mile) decentralized and free from tampering.
>> There is a way forward: seriously figure out the threat model.   Tom
>> Pusateri and another author already did a DHCP document; the reason we
>> didn't advance it is that we weren't able to come up with a threat model
>> where configuring DoT or DoH made sense.   Until someone does that, there is
>> no point in doing further work on a DHCP option.   If we do do further work
>> on a DHCP option, Tom's document is more complete than yours.
> Can you share the link for the draft for a reference?
> Marek

	I sympathize with your desire to deploy DNS over TLS. That was the motivation for Willem Toorop and I to go down this road and present it at Montréal IETF DRIU BOF. Ted challenged me as well but I didn’t understand his point before I presented our work. Ted gave an excellent rebuttal talk after mine that was very clear about how DHCP should really only be used to bootstrap configuration information enough to then talk to more trusted services due to lack of authentication and lack of trustworthiness when connecting to unknown networks.

You should first of all go listen to Teds talk (not a TED Talk) from the DRIU BOF. The video is here: <>
Ted’s talk starts at 33:18.

Willem and my draft is here: <>

My talks on threats and this draft are in the archives of the DRIU BOF and in the same video as Ted.

Aside from Ted, there was a strong consensus in the room to not adopt our draft. You can listen to the comments at the microphone for more information.