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

Ted Lemon <mellon@fugue.com> Sat, 18 August 2018 21:23 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B48130F23 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 14:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLq2WQThf-qX for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 14:23:34 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640B7130F1E for <dnsop@ietf.org>; Sat, 18 Aug 2018 14:23:34 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id m4-v6so9692626iop.3 for <dnsop@ietf.org>; Sat, 18 Aug 2018 14:23:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 18 Aug 2018 17:22:53 -0400
Message-ID: <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com>
To: Marek Vavruša <mvavrusa=40cloudflare.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8ce160573bc4930"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1xzJCn3XK6DlKX0UNmmaHWQKHYs>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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 <
mvavrusa=40cloudflare.com@dmarc.ietf.org> 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:
> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/
> draft-dhcp-dprive.txt
>
> Marek
>
> [0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1
> [1]: https://download.dnscrypt.info/dnscrypt-resolvers/v2/
> public-resolvers.md
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>