Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

Matthew Pounsett <matt@conundrum.com> Tue, 19 March 2019 00:50 UTC

Return-Path: <matt@conundrum.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 03B48130EA1 for <dnsop@ietfa.amsl.com>; Mon, 18 Mar 2019 17:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-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 vdlRDPjFlz5b for <dnsop@ietfa.amsl.com>; Mon, 18 Mar 2019 17:50:27 -0700 (PDT)
Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 E10A7130EA0 for <dnsop@ietf.org>; Mon, 18 Mar 2019 17:50:26 -0700 (PDT)
Received: by mail-io1-xd44.google.com with SMTP id b9so9544294iot.13 for <dnsop@ietf.org>; Mon, 18 Mar 2019 17:50:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=osbGCx9CTwW1EEJmPFdOVofldFUdch/krTEjk7gTiME=; b=r0OaS9bYEgctR/49m6rwvPAl4wbTIuuDV0hLBv8xH+LOf27Drl8/c94jRsxK+KFlKJ D2T3bL72dQaGu16ecMWNHPv+xUvOfsjtgfUgHne5z0MX9zSqJW7O/OcLMj69s/ZW09FP dUtyqCLwzUdW8+Rq4uFI8iMTs2EkJ5WLF5NZjFlxNwKJXHMUKhbvrax71rnuQMBJTAMY K967vp4IHMzvDFTZjquv0GH8J99IoLbkBTjHe/3s2ZpRE0lj9WNkhUbk1ShZXcvUJcHI BXPLnV90eCoxIgk7OrsyHGW5s04jaxdbFm5XGBh61Y5RBNKA4K9hu0gu+cTSf4mZbc6I OxFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=osbGCx9CTwW1EEJmPFdOVofldFUdch/krTEjk7gTiME=; b=VBb0aICFMCMApEdI9gVcvYNCCRj18Q48XFxx7L+N/BFBRjvs4/Ob8G+EklI0Sy3Kp5 EO/fEkrQSQ7fMQnUTV1qFQwkCHJzu+O3AJt88fMmCesyiR9YOItyIatNtw/2NQSXsVYE p9n3ES/28Lwo7r77HOYkXagJUnxB4ulw1DQVpoWXWrx7ehyQcC7vGzF29wchp+VrVPLS V0m8XKT2VO0z7kiYWKxXDkTmXYW74SiFqWVvJfgTav0pWGbXrqEulysjuIacuNB2IfV3 YWipZTab19SqUhYfYNkKVMMyL8GRlaKpH+onZyX8hOzbXent/WwIkxPCIHfe1jHdUEi6 Dgng==
X-Gm-Message-State: APjAAAWQXo6103Xvf9IRivFLhN5TlziJF/TQOpaowFE7EaLvYcLNmkBH uOM9Ld0ya8U/w3zkaSJRGyifpmSfFdm6DeYrnStunQ==
X-Google-Smtp-Source: APXvYqxM3o6nAQgYe21w/vdTMs3wVvn07JdnFeJHAgdVKm3mXAfvtCTyqKzF+AMZU0EosOJouRJBpFY0tQ1ocAA9+6E=
X-Received: by 2002:a6b:ec15:: with SMTP id c21mr13919943ioh.152.1552956626040; Mon, 18 Mar 2019 17:50:26 -0700 (PDT)
MIME-Version: 1.0
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <1900056.F7IrilhNgi@linux-9daj> <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com>
In-Reply-To: <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Mon, 18 Mar 2019 20:50:15 -0400
Message-ID: <CAAiTEH_umx5Xqa24TywQ_BX_Lpo6piwRWPLWhADkh-PnM20vcg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000c0ee0058467e46a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/11BKMNWZ29O_KvBNFmIPJOMVFDM>
Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Mar 2019 00:50:29 -0000

On Fri, 15 Mar 2019 at 14:37, Ted Hardie <ted.ietf@gmail.com>; wrote:

>
>> The past five years have not been the IETF seeking to become a king or
> king-maker.  They have been spent responding to an attack while still
> building out the facilities of the network.  I am glad to find you a ready
> participant now, as there is still work to be done.  But I do not believe
> we have said that you may not have these facilities; the new methods simply
> mean you must have a relationship with the users and devices on your
> network sufficient to effect configuration to use them.  An on-path
> adversary does not, but you do.  Yes, that adds a step and some complexity,
> but dealing with a new class of attack was never likely to be free.
>

This, again, conflates users with attackers.

I'm going to take a stab at restating the positions of several people in
this thread, Paul included, because it really seems like the argument is
not understood.

I have a relationship with my users and I can control the configuration of
their *known* applications.  I do not have a relationship with the malware
author that is trying to steal their data, and cannot control the
configuration of that (unknown) application.  By running DoT on my borders
and blocking all other DNS and DoT traffic, I can provide privacy for my
users while still preventing malware from doing its thing.  With DoH
available at endpoints that my users want to reach using some other
application, it is orders of magnitude more complex for me to block the
malware while still allowing my users to reach those endpoints.  Phrased
another way, a DoH endpoint at the same IP address as a popular website
gives malware the ability to resolve names I was previously able to
prevent.  The only recourse I know of, if DoH is adopted, is to proxy all
traffic toward that example site (including requiring me to engage in a
MitM decryption attack on my users' web traffic) in order to continue to
prevent that malware from circumventing network security.  And because I
can't predict which web sites will launch their own DoH endpoints, that
means I need to proxy (and decrypt) all web traffic in order to maintain
the same level of security I can today.

Somewhere up-thread it was suggested that there are other reasonable steps
that a network/security operator can take to maintain the controls over
resolution that we have today, but so far I haven't seen them enumerated
anywhere.