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

Ted Lemon <mellon@fugue.com> Sun, 19 August 2018 01:04 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 88933130E9B for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 18:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] autolearn=ham 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 lQ7xKw8MPd_V for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 18:04:34 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 0FE1D130E22 for <dnsop@ietf.org>; Sat, 18 Aug 2018 18:04:33 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id y12-v6so123243ioj.13 for <dnsop@ietf.org>; Sat, 18 Aug 2018 18:04:33 -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=LN4HSrje1xxT/DSU43xJiDVZo2goh39kzsqtFQeFMRA=; b=Y++XI3CnqtJJHR+QbBu5Qh1yEx+QGWkgh2mJSiygPd9c0M3kYWqCO1MjQJhDvR0Ns3 zcsYwOVpfSgTsLu3Z2JCStiqPnoPenmL/1Ib/suGc5VSy9KKr87Q4KR5GodZPr9BTnPZ GpLuHr2RlQuF8ffgaqIg0kwpZ+P6eeTInr1UWZg3ggG5boyDjJ3BRPxBDCMK9pQRpzq/ hhi9yeM8AOzmpWSHV7tjdY8RBrnL3ev9s6ErjBGV5BL0CAeF0UmGMGY5OtqSJNwHViba WZhr5iVd67/2O7Y0aZ50Dnh9vBAv9DK0YE4tRVwrmyjZDACuyWbmOFxUx6ojs9C04udH 7ecQ==
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=LN4HSrje1xxT/DSU43xJiDVZo2goh39kzsqtFQeFMRA=; b=h9OTmXxrSz3Xf6tBDOABbrbhNW+jX2ELHJKhbK+1lXI/YaalAWGxZXEOpcJR9mJ1mj fuC1uHMnWlp3JE9tzbGjuewK/cl4OL+02NbV/wATOsy+oMUxnQ1vlZHp0HB21A9naK3a gYQq2QLqAUWy02Z/hSv/3c3R93cGJfzO/0FqxI+ok9EqnzGrWAbLMwqHEObmkDLYV4aZ UAiZZ0bOomTBKfwor2CIavRivxdHZXcCg9IJqbROhTbvGk9hr/cHcvmxJ9rN6tUcGRLs PcrVSKI12vcenwyuvy/nZD9h0NXEiSJ89QKX3NlSZCGTPy8Ku2Rkezx8cpZFT46V+KjY fNcQ==
X-Gm-Message-State: AOUpUlFkofaJPaZ9SITxdWXCPykvDK6rIBQeZSy81+3ut/NX5Q4HOX9P l4t+uHtMQAv9TIxxV6icLx5gqHrZZERNCFrUP+xQpQ==
X-Google-Smtp-Source: AA+uWPxmWzm286B5X0LOjLHBnhWE+Q9qfuCh36zFXVYvAVH2QowswXTl7zOf66zVJbMERbHUGoju4Ymt/R/izg5/wVE=
X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr35924689ioe.32.1534640673173; Sat, 18 Aug 2018 18:04:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 18:03:52 -0700 (PDT)
In-Reply-To: <CAC=TB10Nfp0r=-vWx1cr9Fo22LAGHev9Fqi5ZMSCOpOw-56Zcw@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> <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>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 18 Aug 2018 21:03:52 -0400
Message-ID: <CAPt1N1kr_ANrynMceXpE2zei8Tv13VsmKu7xWqz6-fcXtnio2Q@mail.gmail.com>
To: Marek Vavruša <mvavrusa@cloudflare.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ec8040573bf60a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wfdZTl7SWWwazAhuoLxj07bEYak>
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:04:37 -0000

https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-13

On Sat, Aug 18, 2018 at 8:53 PM, Marek Vavruša <mvavrusa@cloudflare.com>
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
>