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

Ted Lemon <> Sat, 18 August 2018 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68B48130F23 for <>; Sat, 18 Aug 2018 14:23:37 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pLq2WQThf-qX for <>; Sat, 18 Aug 2018 14:23:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 640B7130F1E for <>; Sat, 18 Aug 2018 14:23:34 -0700 (PDT)
Received: by with SMTP id m4-v6so9692626iop.3 for <>; Sat, 18 Aug 2018 14:23:34 -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=r5wDk4J5OB3TM/lahUM7/zeyybRkEIo0Vsf+mQrKb3s=; b=dSNZrN8zoIVUUk4xcAJA9hCAILIkLgudc9YHQ7uDc+4cuok0SoAMrWBRMXl2ZoZJfi TyfkS/VnpEb7Os+B+zqeASHWtRTEdITkTaq4n/2ZqbAYTYqOtB8/p/aVoMmv8iwuGbgQ tjiVs46WvISTj47c58zeKQlg8EiYMBKKsSz4jEYxaFDvMApFw+Yk3gNONL0rfjKvOFgX NKyrEFFWJV9QCHNiO21RmdP6anrHu5dJT5iLy9JGs0UhPThR3qiRNb0X1KovQVYTBUaR CX4zFI9I/XuvcHM61RZEdLjmSNM0TMZcfzcX4+Z/8eXSqHj/zT2mvOQ5BdFzTO16t5+t mwHw==
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=r5wDk4J5OB3TM/lahUM7/zeyybRkEIo0Vsf+mQrKb3s=; b=qtjNkox0a4RlWn5Y2KhLlVCKWSVSzqlNcLFgrHfBgI/qlCsBVNyFXKKnvnGAoIqUiy dEH+yfowVI+y8gLw+satYo/gLX+LlnBP/JIobkFSV+A2B0C5rtz6BQFCG5ZR1Cbq7+xT ym/KsqGPBelvinuYAFLRTg+yUVvMrAezhPD7WVIz+yKm2Sp0SIINBt2qVzq1oNx1GOhl ulYZujoLDIjtmQ34W8UaDWC4AhMYkhkyNP9oN0DgRABW3kv5hmNXQiwtmKgDhNFDrJxK +w9VxT7345yYTXkCvDye3emRieZPgAsapF/o9E/UkYje+a8Rpv6Bam8wbE0d1nUkhQ4J ig4A==
X-Gm-Message-State: AOUpUlGfTkUYpKWEN3FaUWYdfatgYx/4/y2eOHiZ7g7x9w3bzzfywZNi h2OEcBJFYP9cEWvRDGL4z+gVmnJ6Ix9Enl8JMbdDBgPB
X-Google-Smtp-Source: AA+uWPw+E85ZLPl9nzyuq2JWA2yCORlvvazedA1XCGS/pk1y4Pe6DT1me1keWk1jy+vOOFcMjM0xuDIz19pamt3Ymoc=
X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr33563183ioc.45.1534627413537; Sat, 18 Aug 2018 14:23:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 14:22:53 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Lemon <>
Date: Sat, 18 Aug 2018 17:22:53 -0400
Message-ID: <>
To: Marek Vavruša <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000d8ce160573bc4930"
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:23:37 -0000

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

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