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

Ted Lemon <mellon@fugue.com> Tue, 21 August 2018 03:02 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 D7FB8130DF6 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 20:02:32 -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 GMcR4SupcMbr for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 20:02:31 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 67819130E02 for <dnsop@ietf.org>; Mon, 20 Aug 2018 20:02:31 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id d10-v6so2271644itj.5 for <dnsop@ietf.org>; Mon, 20 Aug 2018 20:02:31 -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=froAhd7hpsNyCKhwDFH9P4xIm9RoncqvIqXktKhuyis=; b=zOmSvkOh7rFH8EBBsLJnmuRyv7NDIz/Aj9UGAiPxr5JjG7RunCx6SnMTKOZeWPWGLt LTeash04Fi9jlyyjWwnm4W+Zjep5IvlPBEXDyDrcGPd2iZQJRCYEAC0jDR/ZXUDlNQZs U6/iCC+9OQdDQch0SFTnwM/j0gj6Q33PrBMR+f11QmfxeaS/2uWJURRHi9cH8t5pmdDQ JGc1OeFf3G+gAQAeF7oFCDiFPXZlxJ1189KQ409hplSeQfc9Ir7B7Y6IWMG8z+aDpky5 TEPYjcXqpdurvsxGXyNHoQ4JEpL4OxtpQNxwkLQI8/Qijz4C7dC9p6ifA/6rQrAnw0cp Q9fg==
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=froAhd7hpsNyCKhwDFH9P4xIm9RoncqvIqXktKhuyis=; b=jU8WB5LbtxtwIP3CVHLNL5xuyRCgMkCqGaPSwuCx9EETSShqAT6UEXNAdVmZtUjhEf 1DnfaYNmiJqbZjnshbMjN5lBiLLlSyHrWGmqEY80uGASB8+DJ/WGbo8akhQLe/MJEVQv Z1ws8s4UhRhpNvy6/W5RUr1uni6cgkSWLYizroXvKL6d3RkBz0fg/ZhSVUvgmdmCaGti 1WQ8UIN8WsbtuMCzEB85+Aa02T5Hmiwo+VeYjfhluTFR0xo0ttcdXjsGDX7umN5VT2Su sw+Y5bvGJCMXPpfzGgk2CvA+IC0oQElqPmLObTOaHcH13i7jD4fF9n494yKK5LeZ9sQY BX4g==
X-Gm-Message-State: AOUpUlF5J8PfgSoWF0JxOHFzRvI0CReTib8wnm5IDrqUd2EVVyealRta PilY94PRbYCB1XhD0KAo9TTgjLe6AevtOHobwSB3fQ==
X-Google-Smtp-Source: AA+uWPyT5EVA+a8ravOIeQvFLSa/aIOR39GqWVVnsQnvB8wbLH+CeFvpTT0ImXwwdK07jEBgrbO7yGzI0rzEn/TbnrI=
X-Received: by 2002:a24:374d:: with SMTP id r74-v6mr35964202itr.57.1534820550683; Mon, 20 Aug 2018 20:02:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 20:01:50 -0700 (PDT)
In-Reply-To: <5B7B7E3B.3060006@redbarn.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk> <23C2BA0B-B4A7-49F2-9FFD-90B90E2928B5@bangj.com> <56B7EA81-A840-4320-BDD0-781E9D999904@vpnc.org> <B5CCB149-BEE2-46D4-BF3C-C32D5BCA3EA3@bangj.com> <20180821014030.C2678AD6354@fafnir.remote.dragon.net> <922DCF48-BA8A-42B8-99BA-2B367D981568@bangj.com> <20180821022627.50A64AD6A31@fafnir.remote.dragon.net> <CAPt1N1np9KdMmqE09AhsvH-macAer2dMxsUUpF4AYVSeB0g-oA@mail.gmail.com> <CAC=TB11NMbSbKfw0hMLrW6vywmYDp_T5mYgUFUBc7n7o+axAQw@mail.gmail.com> <5B7B7E3B.3060006@redbarn.org>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 20 Aug 2018 23:01:50 -0400
Message-ID: <CAPt1N1m9hf31ZLwq9TAnoD0teB+dycQCiAZ4jZu+c3WFGJWNuw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa=40cloudflare.com@dmarc.ietf.org>, Paul Ebersman <list-dnsop@dragon.net>, Tom Pusateri <pusateri@bangj.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7c8e10573e941ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Pr4-4TyVPwd89oHWEaBxlreg0pA>
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: Tue, 21 Aug 2018 03:02:33 -0000

I think we've gone way off track here.   DoH exists, and you can't undo
that.   Maybe it was a mistake, maybe it wasn't, but that ship has sailed.
 I think you're implicitly arguing that the IETF should have done a better
job of modeling the threats before advancing the protocol, and if we had
done, perhaps we wouldn't have advanced it.   So why are you now arguing
that the IETF shouldn't do a similarly good job of modeling the threats
around configuring DoH using DHCP?

On Mon, Aug 20, 2018 at 10:51 PM, Paul Vixie <paul@redbarn.org> wrote:

>
>
> Marek Vavruša wrote:
>
>> ...
>>
>> I'm still not sure that IETF should define the provider of trust, as
>> the trust is relative. But you're right Ted, it should definitely be
>> at written down andformalized if we want to move forward.
>>
>> I have to compose my thoughts on this first. I'll try next weekend if I
>> get
>> some of that bravery or willpower back.
>>
>
> if you write down trust assumptions you'll be enumerating disjoint sets of
> same as actually practiced by different users and different operators whose
> reasons should be treated as valid rather than challenged.
>
> mine is, i monitor and control the network path between my dhcp client and
> my dhcp server very much more carefully than i can monitor and control the
> network path to RDNS servers. therefore i am comfortable having the former
> introduce me to the latter. other perspectives differ.
>
> --
> P Vixie
>
>