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

Marek Vavruša <> Sun, 19 August 2018 00:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBCAC130FA9 for <>; Sat, 18 Aug 2018 17:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 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, URIBL_BLOCKED=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 3_gZzFB-8vy6 for <>; Sat, 18 Aug 2018 17:33:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CA52130FBA for <>; Sat, 18 Aug 2018 17:33:20 -0700 (PDT)
Received: by with SMTP id q129-v6so5696252ywg.8 for <>; Sat, 18 Aug 2018 17:33:20 -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=ZzWpH/p51p/qfhrdNcm7PvgkdK8jchasZJrtmk8sZvw=; b=X7BFX3ME1STKJODfqGwkW4pClW48CGeD6VGd5p7P06tzczttkuUAe3RGImLiq6hXZU I/K+ONRnv4uMeNa4RE6Bu4Rs+P4lCUPci7efIqhwLMoIPwwK3ILTboUqxbklUw/hnSi4 ccODl/bt5OsODdLR+njPE591UZE7/NjWNGIgY=
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=ZzWpH/p51p/qfhrdNcm7PvgkdK8jchasZJrtmk8sZvw=; b=uVS3gf41wrGBkCtPSc+OuINcSmDDZO7C83UmwEineZbApdMMUYwBReOh3GmI13yjLk /XSRzosneLq8cUfFREPMiscPeuYHrT3tkzimWtl5EvHtzqBbY74D4tndM3nP7N6IWcXe KpmTvW9NiWg/LkoYWMOizQw9K4aoG02/s4y7Uh4QFhqAAQRC4lhK+u+rMiYYPMuX11wF 7+4rs9pWWxuU5ej7S7OsvyyCWNIKTTN8cgK9BtvIaKuVxzB7S9wAVx5QUHpVW2tjRW0O BeQ2NCjnMxah+qbW1VQCpS7v5QB20LOK74sC5b0Wxi7cY9bqHqRBCypjlLYdjzD6J9Qt zmhQ==
X-Gm-Message-State: AOUpUlEzyc4YfUW3ta2BP/+RY/aEenDjacmtkWMnIkDp5J+RvytQt9zm b33VQeq/A0quC3RRLdN5OG+HDo/gDfBDOFHQSUBzQXZeOS6PyQ==
X-Google-Smtp-Source: AA+uWPxq+SxAIi1Vir5oJnk8/D4OYpWSHq+DTyp24VGGwGLnPA+n+czH24QTCnOsyO20Lz+a9wjiDS4aEtvpu3IP4oQ=
X-Received: by 2002:a81:250a:: with SMTP id l10-v6mr21451636ywl.222.1534638799640; Sat, 18 Aug 2018 17:33:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:18c:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 17:33:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Marek Vavruša <>
Date: Sat, 18 Aug 2018 17:33:19 -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: Sun, 19 Aug 2018 00:33:33 -0000

On Sat, Aug 18, 2018 at 5:03 PM, Ted Lemon <> wrote:
> 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.

No worries, I hoped I described the use case, but perhaps not well enough.

> 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

> 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

The "DHCP authentication" does exist, I believe you're referring the
deployment status.
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.

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

I described one possible way how clients could interpret the
advertised information using a trusted CA bundle.
At the very least, if my ISP or office network advertises resolvers on
port 853, using those is arguably better than
the same resolver on port 53.

> On Sat, Aug 18, 2018 at 5:58 PM, Marek Vavruša <>
> wrote:
>> 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:
>> >>
>> >>
>> >>
>> >>
>> >> Marek
>> >>
>> >> [0]:
>> >> [1]:
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> DNSOP mailing list
>> >>
>> >>
>> >
>> >