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

Marek Vavruša <mvavrusa@cloudflare.com> Sun, 19 August 2018 00:33 UTC

Return-Path: <mvavrusa@cloudflare.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 CBCAC130FA9 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 17:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 3_gZzFB-8vy6 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 17:33:20 -0700 (PDT)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 8CA52130FBA for <dnsop@ietf.org>; Sat, 18 Aug 2018 17:33:20 -0700 (PDT)
Received: by mail-yw1-xc29.google.com with SMTP id q129-v6so5696252ywg.8 for <dnsop@ietf.org>; Sat, 18 Aug 2018 17:33:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; 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; d=1e100.net; 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: <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com>
From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa@cloudflare.com>
Date: Sat, 18 Aug 2018 17:33:19 -0700
Message-ID: <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5hxTeUxC0jSAr9XuWww3-y6fJ4Q>
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 00:33:33 -0000

On Sat, Aug 18, 2018 at 5:03 PM, Ted Lemon <mellon@fugue.com> 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
https://tools.ietf.org/html/rfc8310#section-6.7
What I'm trying to address more specifically is
https://tools.ietf.org/html/rfc8310#section-7.3

> 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 <mvavrusa@cloudflare.com>
> 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 <mellon@fugue.com> 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
>> > <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
>> >
>> >
>
>