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

Ted Lemon <> Sun, 19 August 2018 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 564F1130F4D for <>; Sat, 18 Aug 2018 17:04:26 -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 6a3cv13cV554 for <>; Sat, 18 Aug 2018 17:04:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 701A4130F0F for <>; Sat, 18 Aug 2018 17:04:23 -0700 (PDT)
Received: by with SMTP id d16-v6so4834657itj.0 for <>; Sat, 18 Aug 2018 17:04:23 -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=HVo7wjXWf3AvKVSmmhvyX7ibV1BLABzVCtdqTLKIg8c=; b=d8bTofm4PPatm9Th/fqM9Y6u4FyUQ/mRvUZN8fZy4YchMSDafPl6HlExBMaUw72Wab y0U5C9It0b76ndosGK29B94fAz/xKcyxugqzXjpbp0x5MnBHweow8EGIipyJ2+PDLXDP MG0xHESiKCObF7K13Cs8Mirm6ADMAhm9KuHH5ZMG+q19vnZJZoez+8zHHW2qDhXSQbU/ JdnppjUElHFBYQ0MkUPBMuRT0v4nV1vbI6g01OZ/tRYfou4+OYcbyvzwSv+TRgUPqX3g Fiv9S040ff6+SXMo0XAvcN1aJgJ+6qDalDmziGcynnuLOfdGUGe6FoVySPbFfCQm0nkQ rATA==
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=HVo7wjXWf3AvKVSmmhvyX7ibV1BLABzVCtdqTLKIg8c=; b=diezY7fkiHbDbx9P6NzgI+DPZaJG2TNSAS9Olf30OrGEBJIC8FaHCVI2Cy6IkrDhWN YawHEsNexhXakvq8TMpXK/DxCvhHaEEh6AtOWyeP4rIFxi0rAwYLAKrSPZzjVe8tGLvv stCk10wk9JNjjdqweMWjbR9Zqeb9Si6ynGOSaj/J5g+gX8YoRfj4rk0raKv5bbeK8AZw ZoYMSSB9S760yOw8Tr0YuiyqD6Hbd8vos8DG7IMMOmG5EyAuuaHCFtXDwP8ynKHSKBlA aVHTOtLtD50aDSoJ3sfra+jy8J7/93jXZbw14MoX+h17CUP6cqnjU4+dWM6YPDv5Vbza XFdQ==
X-Gm-Message-State: AOUpUlFF673MmLbgHMZQLxeW79i7tT9HTAPQ2b3w25on6GWFTpH8An9H mBBZ8NaPsolSDE5rswXkFJOR7jVmcmDl4d+Fu98/xQ==
X-Google-Smtp-Source: AA+uWPyPV6eLa8JAFUKAqM/gBpi0kEW3OePgGhFDLghkDDU42606PX2Pw1VqCXlIH7Vgd601MblpkpoXZPFuit3QATQ=
X-Received: by 2002:a24:c445:: with SMTP id v66-v6mr29856296itf.110.1534637062620; Sat, 18 Aug 2018 17:04:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 17:03:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Ted Lemon <>
Date: Sat, 18 Aug 2018 20:03:42 -0400
Message-ID: <>
To: Marek Vavruša <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000fa1dbd0573be88fa"
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 00:04:26 -0000

Marek, forgive me for being blunt, but your reply was completely
non-responsive.   DoH and DoT are being used because they address a threat
model, or because, as Bert rather bluntly put it, they allow content
providers to study our query stream.   They are not being used "because
they are standards track documents."   If you don't have any reason other
than that to use DoH or DoT, then you shouldn't use them.

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
that whatever configuration the user or service provider has set up be
replaced by information received by DHCP, and that "DHCP authentication",
which doesn't exist, be used to validate this information.   This is a
completely different trust model than the current trust model.   Maybe it's
a good idea, maybe it's a bad idea, but it's completely different.   So you
need to figure out the existing trust model and figure out how your
proposal impacts that trust model.   To define a DHCP option before you've
done this is putting the cart before the horse.

On Sat, Aug 18, 2018 at 5:58 PM, Marek Vavruša <>

> Hi Ted,
> thanks for comments. As said, the draft doesn't try to change the
> trust model or fix DHCP authentication, it merely offers network
> operators the ability to advertise secure resolvers for their network.
> The added "danger" is that recipient inherently trusts the
> information.
> On Sat, Aug 18, 2018 at 2:22 PM, Ted Lemon <> wrote:
> > DHCP authentication doesn't exist.   We already rejected a draft that
> > described how to set up DoH with DHCP.   Yours is a little more
> complicated,
> > but doesn't seem any less dangerous.   Before you go any farther on this,
> > you might ask yourself a couple of questions:
> >
> > 1. Why is DoH being used?
> The DoT and DoH are being used because they're both either standard or
> on a standards track and have deployed client software.
> > 2. What is the thread model that DoH is addressing?
> > 3 How does adding this configuration mechanism impact DoH's ability to
> > address that threat model?
> It does not. In both cases, determining whether the resolver (or its
> capabilities) provided by a DHCP server can be trusted is up to the
> client.
> The current model is that either OS or applications like browsers
> install a curated CA bundle with CA's the client should trust.
> When a DNS stub resolver receives a request, it looks into the
> resolv.conf (simplifed) and picks a resolver to send query to.
> Currently the most common method is to pick first, but it might prefer
> resolvers with secure capabilities first.
> If a resolver is advertised as secure, the stub resolver may do a TLS
> handshake and check the certificate.
> Now at this step, it may:
> a) only trust certificates issued by a CA trusted by the application
> with the resolver IP address in SAN (trust system configuration)
> b) ditto, but certificates with advertised ADN in SAN or matching
> SPKI pin (this presumes the client trusts DHCP offering, or is okay
> with TOFU)
> c) bail and talk to the resolver over port 53
> In a), the resolver can be trusted. In both b) and c) the trust in the
> resolver doesn't really change from current status until DHCP
> authentication happens, but the query stream is hidden from other
> devices on the same network. Either way, the benefit is that stub
> resolver can make a decision based on a multitude of factors. Is there
> a merit in this, or am I perhaps missing something?
> Marek
> >
> > On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša
> > <> wrote:
> >>
> >> Hi,
> >>
> >> this is a bit off topic, but I figured it would be useful to solicit
> >> some early feedback. The current status is that for secure (as in
> >> RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism,
> >> and it's also out of scope for [0]. At the same time we're seeing real
> >> world deployment of clients which either:
> >>
> >> a) Probe port 853 and use DoT in opportunistic profile, or probe 443
> >> and trust WebPKI
> >> b) Statically configure ADN and/or SPKI pins with well known public
> >> resolvers
> >>
> >> This approach works if there's someone maintaining the statically
> >> configured information, as with the dnscrypt-proxy stamp lists [1].
> >> However in most networks the default resolver configuration is pushed
> >> through DHCP, so it's the network operator that's in charge for
> >> providing default DNS resolver configuration (unless the user is a DNS
> >> aficionado and overrides it), but there's currently no good way to
> >> provide information required to identify and securely bootstrap a
> >> connection to a resolver using DoT or DoH.
> >>
> >> This draft adds an option to provide a capability list for each
> >> configured resolver. The three defined capabilities are TLS with SPKI
> >> pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this
> >> information and stores it similarly to resolver list and domain search
> >> path for applications to read. Another possible solution for this is
> >> to use the system of stamps from dnscrypt-proxy, but it's probably
> >> less legible for clients and duplicates information that's already in
> >> the recursive DNS nameservers DHCPv4/v6 option.
> >>
> >> The draft does not change the trust model, an end-user or an
> >> application can still disregard DNS recursive nameserver list from
> >> DHCP, for better or worse.
> >>
> >> Here's the draft:
> >>
> >>
> draft-dhcp-dprive.txt
> >>
> >> Marek
> >>
> >> [0]:
> >> [1]:
> >>
> >>
> >> _______________________________________________
> >> DNSOP mailing list
> >>
> >>
> >
> >