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

Ted Hardie <ted.ietf@gmail.com> Tue, 12 March 2019 19:15 UTC

Return-Path: <ted.ietf@gmail.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 543731278CF; Tue, 12 Mar 2019 12:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 64UCa9sB_vzd; Tue, 12 Mar 2019 12:15:43 -0700 (PDT)
Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 8A1491277E7; Tue, 12 Mar 2019 12:15:43 -0700 (PDT)
Received: by mail-it1-x12f.google.com with SMTP id l139so6346102ita.5; Tue, 12 Mar 2019 12:15:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X8izjUOM1gchIZFMDQDXwkO7AYVfeoBVKxbDflkDpYM=; b=tlGADYt5x5h+0wDRWUxcisBCddaLmLvTe9a+i8CZe+P73q3sPYdj9SE0XbOK/gkQsx f0+1776SzJq8UAz0sSK1CRaWpBnHIUWrt9xdEO2eAd4I6QgRzGhAEi3Ks79NMBSZ4uRG Da21T4Wo0bsl5SYW8WN2ANX/B6jwsZGrhrdvk83niLsoCA7tfuSCurTmI28Wrx8g5qv4 Jxvqj6hBOos0a666FJsYcNmHy5UcPFcFL+pmPaz+w7mhls6+hN3rhf3oEq1OffBR3+bS LQmyw2Ie8+KgwHp0FSNZeUpUq7edZ/sWtIwK3xlBwzmuMFF0xyHpBjq6nNxlHWJZmQuf gDRQ==
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=X8izjUOM1gchIZFMDQDXwkO7AYVfeoBVKxbDflkDpYM=; b=c7OQaK+DH65hmILluD+j3ZE7275tHW3fZSoUmVKr0KTVmse/n1SVx642hyTNSucxgG UBaYDASF4H9XR/u7hI0rPWmWfeMsBjmtkI0mGFVk2ppyFerK+892QZx/NhjGrMNRcnmL zmAa26/LnGgRgxvPNXbszL8xLOMlYLrSTvJAlf3b0ob2JbdkORlw61E7oM+eRuUbTrSX 5kzxITUQKZbEx5v7rUvIKYkP7NQXbDXUoiojkZpZ4QeyETdLm0Q/IvNY76iBJmWtChLB C+UuGZwh9bIMsrMKOLVf4IcByjuji/caCy5n6m7ykW2zmRnQ7nnCNEdOTkEgX7gYE07D FTRg==
X-Gm-Message-State: APjAAAUFAhSLQxX+M55keAoy7UT59smVb56y3ZfOcyg2DQvcBrxXE+Fx uQ3vSiSYVROrDs8xBcT7H+DrB7C55/eCrKml45M=
X-Google-Smtp-Source: APXvYqxC6F2z8o0Lm133z9ToZ7I61goec8Aq6pxi4UE6ekDjcCq6JiE9g+VeZfkRHzhHIANk2hGXOCJ8Mg8l7efZevE=
X-Received: by 2002:a24:4741:: with SMTP id t62mr2928175itb.110.1552418142613; Tue, 12 Mar 2019 12:15:42 -0700 (PDT)
MIME-Version: 1.0
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <5456b9d9-844f-f410-3935-2b2d3ae22745@redbarn.org> <CA+9kkMDo54N=DoL1HAQoMYSe1jrexXXrA3ZXkkve0CJ2-bvd4Q@mail.gmail.com> <3457266.o2ixm6i3xM@linux-9daj>
In-Reply-To: <3457266.o2ixm6i3xM@linux-9daj>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 12 Mar 2019 12:15:16 -0700
Message-ID: <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Warren Kumari <warren@kumari.net>, Jim Reid <jim@rfc1035.com>, DoH WG <doh@ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eef9ae0583ea833a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FtPZBnBCvf1tF2IWlb89XacXt7E>
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, 12 Mar 2019 19:15:45 -0000

Hi Paul,

Comments in-line.

On Tue, Mar 12, 2019 at 11:27 AM Paul Vixie <paul@redbarn.org> wrote:

> On Monday, 11 March 2019 18:30:51 UTC Ted Hardie wrote:
> > On Mon, Mar 11, 2019 at 11:06 AM Paul Vixie <paul@redbarn.org> wrote:
> > > DoH will moot that approach.
> >
> > Any system that actually checks the credentials presented by the
> responding
> > server will also moot that approach.
>
> yes! but it will fail "closed". thus, no unauthorized exfiltration risk
> will
> exist.
>
> > Given how easy it is to pin
> > credential characteristics in applications distributed as binaries, this
> > seems to mean that your method will either continue to permit
> applications
> > other than browsers to use their own resolution systems or it will hard
> > fail all such applications it can identify.  No pass through will work,
> as
> > far as I can tell, in that scenario.
>
> that's precisely the goal, because very few network operators can
> preordain
> the users and apps that will connect through their networks.


I do not believe this goal is met by what you describe, since an
application can use a proprietary resolution service in its flows.  Imagine
for a moment an application on a smart TV that wants to provide content
from the closest server which contains that content.  It can use a redirect
from the original server when a new, closer server comes online (or when a
different server has that content), and it can provide the mapping between
that server and one or more addresses for that server with the redirect, in
whatever format its individual cache can store.  All of this can take place
within its confidential channel, using whatever proprietary format they
find convenient.  In that case, the local network will see new flows to the
new servers without having observed the resolution event.  Blocking
destinations for which you have seen no resolution events will work for a
subset of these cases, but it won't work when the resolution points to a
common CDN destination.  That approach will, of course, also have a wide
variety of failure modes when the resolution event data is incomplete for
timing or other reasons; it will also block all of the flows which MUD
would handle.

to the extent
> that monitoring ('dnstap') and controlling (DNS RPZ) dns lookups by
> connected
> users and apps is considered a vital local security policy, attempts at
> such
> "pass through" must be made to fail.
>

Those are security mechanisms, rather than policy, and it may be worth
teasing apart what the actual desired security policy is.  You may find
that it is more easily implemented at the routing layer than the resolution
system in the light of proprietary resolution systems and DoH.

regards,

Ted Hardie


>
> >
> > Perhaps, though, I am missing something about your intent.
> >
>
> i think you've restated some key points of my position with perfect
> accuracy.
>
> DoH wants to empower users and apps to make decisions about their RDNS
> which
> cannot be interfered with by on-path actors such as their own network
> operators. by doing this, DoH makes a false equivalence between a
> dissident
> (who may be considered a criminal in some places) and a criminal (who is
> always considered a criminal in most places) and private users in a hotel
> room
> or coffee shop or on their home broadband connection, and malware which
> gets
> inside a network and wants to avoid detection/mitigation while performing
> lookups or exfiltration.
>
> those are four very different things. demanding identical treatment for
> all of
> them is, in the best possible interpretation, naive.
>
> vixie
>
>
>