[DNSOP] Draft for dynamic discovery of secure resolvers

Marek Vavruša <mvavrusa@cloudflare.com> Sat, 18 August 2018 21:17 UTC

Return-Path: <mvavrusa@cloudflare.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EBCC1130F17 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 14:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Yg1nkPrkWmpz for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 14:17:18 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 5457F130F18 for <dnsop@ietf.org>; Sat, 18 Aug 2018 14:17:18 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id o17-v6so3265961yba.2 for <dnsop@ietf.org>; Sat, 18 Aug 2018 14:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=U1QNdvGxKludoLMOJAg45sRlUzCm9oWBNUyqCyqstVU=; b=m/DmBGbZGZdpfLDxraBb9IQgpLzZ2CFO9ptVjqpUbJFDLhfmLOce3DxWTLSsyB7nsz 9m8Q4XOmIILXzu3RZaFPLvl4vfX2HtkBk39wjZNDU7wBPsWgpdEISEFugTIAM+JSFVu9 5pKDJzrFJ34e+Z9M3oS1kpDpa6Cq89lww6iPc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U1QNdvGxKludoLMOJAg45sRlUzCm9oWBNUyqCyqstVU=; b=f2z5wfTRPEe5PjUSlY9PmzHp7YUWIbdppQ7OcvUuRxVFGk1kHzDkWvqmSNkHLAWgVF W17H2laDNLB4g8MDePxomoXBTiHItOBmpmBRjvda902wX+tL7oJ7ffE6WApAx8dOOqBN 2GYa/KjGDQeEHG1FknY7Viz7tEXwyQ7tXOUxm6C1RSVGpWEoDA83hQhATw5Jn70JMK2H vRGy7ZagG8pqirjMgWqgIQWROcR/VKwwXemPf2t8UdRCuThq/z5wgxmYK4IPC1/M1zvu feh7vGYJvKJV0eE6du5iyjHeZoX/JJUZ8NaAR8pTBp+f3cxXdPJJvMnNL4/M61kc8Inc 8DOw==
X-Gm-Message-State: AOUpUlHXaAoSmWTayfd//S/Vz/aDB7E9vz52umns/lGlsMRgG+yEcxUN Hk/PRdrZqFHMalXR/qudgLeuzHldmwZmEmvdp4SIPqTCwFLjvA==
X-Google-Smtp-Source: AA+uWPwfPJWOnVnNEhwx6V0h7r2209Zi1ybJbK8LBR7KJsizbF9sJDV0U95VKTOOI8KrXJt9RyKVzhxYeN6e869d36A=
X-Received: by 2002:a25:68c9:: with SMTP id d192-v6mr23183647ybc.276.1534627037293; Sat, 18 Aug 2018 14:17:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:18c:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 14:17:16 -0700 (PDT)
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Sat, 18 Aug 2018 14:17:16 -0700
Message-ID: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ws0wfMgjLpRsjt9x2kxzJHpFlnc>
Subject: [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:17:20 -0000


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:


[0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1
[1]: https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-resolvers.md