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

Marek Vavruša <> Sat, 18 August 2018 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1560F130F21 for <>; Sat, 18 Aug 2018 14:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 xOcqhIxefZhq for <>; Sat, 18 Aug 2018 14:58:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67B80130F1D for <>; Sat, 18 Aug 2018 14:58:40 -0700 (PDT)
Received: by with SMTP id d34-v6so3288977yba.3 for <>; Sat, 18 Aug 2018 14:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8oW7JT3p0pJlKlxtpZrp4W/kVjAeag3hHebCLOU38RA=; b=EVCb8SczY3GzZgEij/8Q4o33gJQmq2ZAtJsdJatgEaSxyBY+Hs615zTrdMg4jt2r0W KuhIOoreHykd6yupZv/nYeDQe1Ajg8GtbJf8MGQ64eAhX5AzlA97EApvXVAjkoI17gLA SOrSsm3tVYne/70ujTlz8lSvoCLMUzpm7473w=
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:content-transfer-encoding; bh=8oW7JT3p0pJlKlxtpZrp4W/kVjAeag3hHebCLOU38RA=; b=HoqapR+Avd2mi+qQiUSIkvzj+BUCBNRmrB6luoa/v4gspH9tbSD346ETlmh+2D2fr8 ODd7LG6/4RY/cvuohiFEjqaQC6ySIhA+2F059vS7wiC3xgwpEOU3h/8ZbGcHTuU96l5y DOZ4p1rzWd48nJ0htxixZiC24PhgY4rM7qfRwoC+7uDT4BF2Ax/MmTA0o4nMl/atCyDu g25Awa/q7blNmz4Rodtnun60dDmPybdmAfdseKBDY1eG41/MtORx/hrdpdVLiCOPEv3z 8dSKBDqLukug+3Va4y6dMxsTflJTSwUHyXbu8ToT3qsW6ZaWzArdvoA4CnHmKWvk9puY 2f3g==
X-Gm-Message-State: AOUpUlH4vUAQovK0D/NiLNOP0HZUDvHXmj4QIS6znST8rd/SzlYNKddt gqKfeFW5UJPECjBbDKLO0HI8hhL0mLJph4ZGQnqKHQ==
X-Google-Smtp-Source: AA+uWPzXoW8PtPGmiNIC6re0caHp2Pb2dG2Uk8V5Qcv+sM4WF2AkdFsCl9brRV0VmcHkgiAdyKsjrAannZJDpgCyJA0=
X-Received: by 2002:a25:6e41:: with SMTP id j62-v6mr14670203ybc.89.1534629519607; Sat, 18 Aug 2018 14:58:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:18c:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 14:58:39 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Marek Vavruša <>
Date: Sat, 18 Aug 2018 14:58:39 -0700
Message-ID: <>
To: Ted Lemon <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sat, 18 Aug 2018 21:58:43 -0000

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

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


> 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:
>> Marek
>> [0]:
>> [1]:
>> _______________________________________________
>> DNSOP mailing list