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

manu tman <chantr4@gmail.com> Sun, 19 August 2018 06:42 UTC

Return-Path: <chantr4@gmail.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 12724130F7B for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 23:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bXYSaa1vfkwU for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 23:42:28 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 D39A3130F47 for <dnsop@ietf.org>; Sat, 18 Aug 2018 23:42:27 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id e14-v6so16609784itf.1 for <dnsop@ietf.org>; Sat, 18 Aug 2018 23:42:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oYfAvBlIcFQblPzKP2DarPzmEmaSBuo6MXkYrtp8wvE=; b=AtQxu0GUlkXPmodaV3vc61PmpMVCodqu62DB5EE+bLclxErgvuIR2wJob30xAsDWQs c/25p+qPo31Jx9q6dsj7DYX8PaXUcKU1KpUz87Nu6kryNSH0DyCmHUNwqoMAuUOH6/h4 PpFEzFXyKMVenQxqSzpQgpfmtRgKh1BB1GtoUabdhyPGM3JVVeps878Uso26yCsFFFP/ erCaHhvqLhK2hxk8SbTa7sLZSYUPYuhiGx8dkQVtcEO2ui8zakGVCW2HW6C2DWqSQOiF 48ZjpodZOz3nPETleVtJPvjfapZQQ/u0ff1rjHP0KaN88lVjH5h7I7cxHaL5M0osCMc1 zw8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oYfAvBlIcFQblPzKP2DarPzmEmaSBuo6MXkYrtp8wvE=; b=E4WX/shp91f+zMSV2Whp+SXxJEJbx9HxV8fRrRuZbtsPufd8GY2Dbqh+KZM2lUXTTh UCJqL7ZPp5UM/4fTSJbG3NwOFHVdfZEaZ7ULJuM67xcJYZwelUW1n478DwRxNEQiseIA r26SyPnzSjzDD/wi0SDBPwN1Qd4VCNmo71reR01t3irkxoMhf0UUbivEzD76FU0eC/Qt 5iMNuv9Qj4EvzitsvGWPfvwNWcTdrKQ/bmi+YcIP1YLqJXFxau3lwTEzBMP1BRSuxknd lJ2IdPI87cXdCZ5VXCFHa3pNM72wTOxbWfXNyFeaxNSE47o1As/2aUM3IvWYeQ/kcAPJ /c8A==
X-Gm-Message-State: AOUpUlEIiOCTjSRBMm+7/HrrS0SmQi41XlR2SMhaiwgD7efj1K5jrFbP ugq5WmR9gPJidKeVTfZCf3swni4gRkLaBXpKUsZsF/I4
X-Google-Smtp-Source: AA+uWPw9bO5evXV6VW7gkRhTc38a5E/tPbiqg3pUd2h4iPYgvDnzqmcFVKaHfcMRYSIpXU+VWYSEa+xoUzrzQ/refEg=
X-Received: by 2002:a24:7f87:: with SMTP id r129-v6mr9372927itc.107.1534660946937; Sat, 18 Aug 2018 23:42:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com>
In-Reply-To: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com>
From: manu tman <chantr4@gmail.com>
Date: Sat, 18 Aug 2018 23:42:15 -0700
Message-ID: <CAArYzr+jjAkZZ8GJz4gdfxZDSi6dvpwuyU_6H9nwusDiDDXRbQ@mail.gmail.com>
To: mvavrusa=40cloudflare.com@dmarc.ietf.org
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000097cf6c0573c41846"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/98Mh9_Ea9F9WBYEulJ7iy9vhvl0>
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: Sun, 19 Aug 2018 06:42:30 -0000

I am going to focus back on the draft itself. While the discussion around
centralizing DNS to 3rd party vs local ISP (or any other alternatives) is
worth having, it is a fact that most people get their DNS server set using
DHCP.
the current state is that all you will get are addresses that you can use
to query DNS over port 53.

With the advent of recursive DNS servers that can support encryption, it
will be useful to signal that to stub resolver. Some ISPs may want to
provision their CPE to advertise DoT to their recursive resolvers with cert
pining. Other ISPs in regions that heavily offload their DNS to so X.X.X.X
provider, would be able to let their customer use the service from such
providers, but over an encrypted channel. "power users" may want to
configure their home router to publish a set of DNS servers to be used
using DoT or DoH.
This is definitely not a bullet proof solution, but it seems better than
what we currently have and with minimal protocol change (just adding an
option).
The way I read this, the network owner that in the past would have made the
hosts in their network use unencrypted DNS, will now be able to easily
promote encrypted DNS.

As for feedback on the draft options.
- Section 2.3: Why DoH has no option data? The IP from the DNS recursive
name server option merely provide an IP to connect to. DoH server may have
a cert that will validate for a hostname. The endpoint may or may not be
/dns-query . How about alternate ports? It seems a having the URI as part
of the data would be useful ( e.g https://dnsserver.example.net/dns-query ,
https://10.10.10.10:8443/dns-query , https://2001:DB8::1/doh ...)
- the draft as is, assumes that port 853 will be used for DoT, 443 for DoH.
Being able to provide alternate ports could be a plus
- It is not clear to me if the options apply to all nameservers from the
dns recursive nameserver option, or if there needs to be 1 option for each
nameserver. I could for instance have nameserver1 which does DoT + DoH
while nameserver2 does none. In this case, I would get option 147 with
option len of 2 for the first server, followed by option 147 with option
len of 0 for the second one.
- A DHCP option should be able to be set multiple time, so one can
configure TLS_SPKI with multiple values. May be useful for rotations and
such.

Manu


On Sat, Aug 18, 2018 at 2: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
>