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

Marek Vavruša <mvavrusa@cloudflare.com> Sat, 18 August 2018 22:01 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 3598D130F67 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 15:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7ApzONWRNo8 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 15:01:36 -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 9CFB9130F23 for <dnsop@ietf.org>; Sat, 18 Aug 2018 15:01:36 -0700 (PDT)
Received: by mail-yw1-xc2c.google.com with SMTP id l189-v6so5640630ywb.10 for <dnsop@ietf.org>; Sat, 18 Aug 2018 15:01:36 -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; bh=1Z/kHYhl/vjUQfSpjBNHO2OJMsEOhAshoOhYpG20ZbE=; b=qAaVQBcS5HtFb3Wmaea9UXrbw/PlxqZxHT1QsJ/q1Vr2nj7Ws5w4G+njKZsv3O9GcY q/dy6bRkGUl50pxkth16fGO3aOH3jfWE1BvRbwo0IlHRqhLTnOckPQu8ozFKAnHlBBof tNtsmDDiIyHzpzZKJPe2ZaLpU9BvZ4gHZC9sg=
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=1Z/kHYhl/vjUQfSpjBNHO2OJMsEOhAshoOhYpG20ZbE=; b=fEkMqT7BtAAlO/g2iyYdoh4IY4uO4CDbuOgu7Y+cLkRQamgE4k630oBpUh4s2aIHk7 6OOGoKVyEUIbjq56WVF2tBYlSKhGQ3R7e/BB+k5jaSi63soYe83WepbJETkFrenKD6Vj DVlKda5CnTkk4jQsNDstIuNLQIBpxcJ3qtv1+Ygt/H3fuvyWP2MyiYVEztmx8P7VbC9V 7FJyJzuyzXATAz4Bu/n48fKHwsqZQHpvyLGNHz7TiPcpzPtsYkLwgreCflCz003dnHn5 hzoPaJUco6QhXGAe9CmCcsMom5X4dASRscynG7jmnBoiFYA3mbdWYYtrCYzLcDYrD4uo Eq2g==
X-Gm-Message-State: AOUpUlF5E948TOVzen8NN6kqwhcRB430mB+CRM3hgzlB8llojv4DbVCA bKeGzEXpteRpzyIIVLuoMpVodpFfqXeE9XOvdAuQHjevXVE=
X-Google-Smtp-Source: AA+uWPw1q5cL3b9QjhlX9Dvvol19asfBQDduybk51XxSyn8pBVGA93zsZerc+76YHMGfXM4AuXwQx1u22H1Asi9t4nQ=
X-Received: by 2002:a0d:db50:: with SMTP id d77-v6mr5101060ywe.150.1534629695823; Sat, 18 Aug 2018 15:01:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5b:18c:0:0:0:0:0 with HTTP; Sat, 18 Aug 2018 15:01:35 -0700 (PDT)
In-Reply-To: <5B7893C9.7000703@redbarn.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <5B7893C9.7000703@redbarn.org>
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Sat, 18 Aug 2018 15:01:35 -0700
Message-ID: <CAC=TB13WjNJG+Sk8kcudcs9G3dDQcvOyg0ywBJY=90vAynUJLw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Ted Lemon <mellon@fugue.com>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_Z-n4GXrHYXHkyTqJcJAXtaEcvQ>
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: Sat, 18 Aug 2018 22:01:42 -0000

Hi,

thanks for comments. This draft has little to do with DoH (the primary
focus is DoT), and its comparison to other technologies. It's about
network operator being able to advertise that its recursive server
supports DNS on more than just port 53. Please let's stay at least a
bit on topic.

Marek

On Sat, Aug 18, 2018 at 2:46 PM, Paul Vixie <paul@redbarn.org> wrote:
>
>
> Ted Lemon 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?
>> 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?
>
>
> the DoH use case is for web users and web apps who do not trust their
> network operator and who are not trusted by their network operator, so it's
> a policies-in-the-night model where data can be imported from The Web
> without approval or permission or control or observability by a network
> operator. it is in other words a thin DNS-only way to do what Tor does.
>
> as a network operator, i oppose this thinking. i predict a long war in which
> web users and apps who want to use DoH to reach an external DNS resolver
> will be treated as attackers, and either banned or blocked. in some parts of
> the world such use will be illegal and even punishable, much as Tor is
> today.
>
> this is what happened after edward snowden flew to hong kong: the pendulum
> swung so far the other way that many of us saw only absurdity.
>
> the possibility that large CDN operators will colo a DOH endpoint with their
> high-value hosting, in order to discourage network operators from blocking
> it, raises the stakes. _i_ will block it. most corporate networks will block
> it in some form. some countries will block it. no DNS content will enter my
> network without having passed through my RPZ rules. if a CDN operator wants
> to play "chicken", i guess that we will.
>
> --
> P Vixie
>