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

Marek Vavruša <mvavrusa@cloudflare.com> Sun, 19 August 2018 01:10 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 D8A80130DD1 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 18:10:51 -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 3R4Eqkoy_pYn for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 18:10:50 -0700 (PDT)
Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 CCA1F130DCF for <dnsop@ietf.org>; Sat, 18 Aug 2018 18:10:49 -0700 (PDT)
Received: by mail-yw1-xc2c.google.com with SMTP id y134-v6so1886329ywg.1 for <dnsop@ietf.org>; Sat, 18 Aug 2018 18:10:49 -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=Go9uneuEVG87Ajx0EfAUM9YMaEZgtfF+fHQCRWWazas=; b=dVRixUOmEBf3D9sP54WlGu3F+2BF5XYh76wH5RarrNORBCXsq2qcQF6R1RnnEO4cbW iHV7O8PBylkaX9gmYBwPz90h0nUxfok5f81VwMcqXjpUeZ0+1cU/7lANo6okcdDG/pJJ cGsuDZITumVCyPxiYKwhw+50kVO0l++vJzLec=
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=Go9uneuEVG87Ajx0EfAUM9YMaEZgtfF+fHQCRWWazas=; b=DlRd/uyRU+79muuyvc0TeyRCuX2Rdy9QyhoWif6E5KVsg7XP2HefZ8b3QsAwQ6MTOQ NV0IpYX5xgtgiGsjNYiCsi+P6vCDs0mhBGFashRrcFO/XVyHWAkJFFOTk58N6iYMNpj+ 6tgDTWChqF2CQVsvhFk4qXD5lOun3qWXuzBX7iZnq1PjqB+DPZD76hUZKbM6iL/uPTan wHJdkkfFqcRXFxZHJtouyd99AqEp1oLIhJ4HZrLaitIgdMsJLwZ7HEY7ZtHN/B49Giio HTad97Z5uGOCEERYhLwJDNwQzI3WWPkg8wWA1sv5jND0jkPekc/OB99viiAV/n+hLeWc 1nlA==
X-Gm-Message-State: AOUpUlGp6be3Je7MQYdYULWVJUik1mC+wgoS1JGIK4oGOt78xeymL1V9 quPuTi1vb6zrHxRFDDliSOBiUWYup6oW/h61koDWOg==
X-Google-Smtp-Source: AA+uWPzyjOLznRf4hsMKYuLobOm1v91u0OT4Ovlt2rPJ+sbfDj0yMx5KV5q8HLflawJXxKkKl/lB7YnXu/CC1OVb/5Q=
X-Received: by 2002:a81:130b:: with SMTP id 11-v6mr22117369ywt.332.1534641049007; Sat, 18 Aug 2018 18:10:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:18c:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 18:10:48 -0700 (PDT)
In-Reply-To: <C0B1B752-044F-4F2B-9769-6468A2113EB4@bangj.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> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <CAC=TB10Nfp0r=-vWx1cr9Fo22LAGHev9Fqi5ZMSCOpOw-56Zcw@mail.gmail.com> <C0B1B752-044F-4F2B-9769-6468A2113EB4@bangj.com>
From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa@cloudflare.com>
Date: Sat, 18 Aug 2018 18:10:48 -0700
Message-ID: <CAC=TB13H-CH_46Q0GK9H7Z-AcG9G_B5+xMDVn=XT0EwYUz_ORQ@mail.gmail.com>
To: Tom Pusateri <pusateri@bangj.com>
Cc: Ted Lemon <mellon@fugue.com>, 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/7aiEo7enRzGjLFqQgk4VcYe7wyg>
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 01:10:52 -0000

Thanks Tom, this is what I was asking for. I'll take a look!

On Sat, Aug 18, 2018 at 6:09 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>
>
> On Aug 18, 2018, at 8:53 PM, Marek Vavruša
> <mvavrusa=40cloudflare.com@dmarc.ietf.org> wrote:
>
> On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon <mellon@fugue.com> wrote:
>
> On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša <mvavrusa@cloudflare.com>
> wrote:
>
>
> 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
>
>
>
> The document explicitly says that it doesn't have a trust model for DHCP.
>
>
>
> The "DHCP authentication" does exist, I believe you're referring the
> deployment status.
>
>
>
> No, I'm referring to it doesn't exist.   There is no deployable DHCP
> authentication.   The DHC working group tried to come up with one, and
> ultimately concluded that it was not worth it, because the only thing that
> should ever be trusted from a DHCP server is information about the local
> network.   DoH and DoT are out of scope for DHCP according to this
> reasoning.   Bear in mind that we were more optimistic about authentication
> when we did RFC 3315.   RFC 8415, which is in AUTH48, and which supersedes
> RFC3315, is not as optimistic, and only provides for authentication using
> IPsec between server and relay, and authentication for the purpose of doing
> Reconfigure; this authentication is not sufficient to provide assurances of
> trustworthiness.   It's about as secure as a TCP sequence number.
>
>
> 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.
>
>
>
> There is a way forward: seriously figure out the threat model.   Tom
> Pusateri and another author already did a DHCP document; the reason we
> didn't advance it is that we weren't able to come up with a threat model
> where configuring DoT or DoH made sense.   Until someone does that, there is
> no point in doing further work on a DHCP option.   If we do do further work
> on a DHCP option, Tom's document is more complete than yours.
>
>
> Can you share the link for the draft for a reference?
>
> Marek
>
>
> Marek,
> I sympathize with your desire to deploy DNS over TLS. That was the
> motivation for Willem Toorop and I to go down this road and present it at
> Montréal IETF DRIU BOF. Ted challenged me as well but I didn’t understand
> his point before I presented our work. Ted gave an excellent rebuttal talk
> after mine that was very clear about how DHCP should really only be used to
> bootstrap configuration information enough to then talk to more trusted
> services due to lack of authentication and lack of trustworthiness when
> connecting to unknown networks.
>
> You should first of all go listen to Teds talk (not a TED Talk) from the
> DRIU BOF. The video is here: https://www.youtube.com/watch?v=cfEX8zuoRAA
> Ted’s talk starts at 33:18.
>
> Willem and my draft is here:
>
> https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00
>
> My talks on threats and this draft are in the archives of the DRIU BOF and
> in the same video as Ted.
>
> Aside from Ted, there was a strong consensus in the room to not adopt our
> draft. You can listen to the comments at the microphone for more
> information.
>
> Thanks,
> Tom
>
>
>
>
>