Re: [Add] When Two Worlds Collide

Ted Lemon <mellon@fugue.com> Fri, 16 August 2019 19:55 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A6B1200D6 for <add@ietfa.amsl.com>; Fri, 16 Aug 2019 12:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_HELO_NONE=0.001, SPF_PASS=-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 p3pM_FH3lzMM for <add@ietfa.amsl.com>; Fri, 16 Aug 2019 12:55:11 -0700 (PDT)
Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 86E2D120090 for <add@ietf.org>; Fri, 16 Aug 2019 12:55:11 -0700 (PDT)
Received: by mail-qt1-x841.google.com with SMTP id t12so7362589qtp.9 for <add@ietf.org>; Fri, 16 Aug 2019 12:55:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rmbMpCZJmybyItBy0ZVfOxoe/6+3wQ3au1iQ//hL5F0=; b=cQE4HfPc3wWG4U5oxFSFmdvZLYk3OmNveLdIcFAuOw4JzXozmNsW37N0PXsN++7NVb XzwtGNljnkKiNPJz3UgSXm/tw5o8Nb2QdpypjzV6Yy3U6HOV4K29MKuTlx2TcVmKDomz aevGaU0B7ap2VWFkdHAZFbsOlHDuqf9XWH/g3FnALxEdJVv9oDp0EqiF+8H3a4jPwxKk Mupbs31RafKTXJ4W7goKLTJkt1/IyX7OCZyPuY9I1Qunsr+dddK7d/4oiiuN15hb78VW GobUQo7EUv/skkwNqJVTH6x6lhOBvmhzbi/vY/14NpXrwibcKkcNt8wTwvrP+gAZtQRI 2NXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rmbMpCZJmybyItBy0ZVfOxoe/6+3wQ3au1iQ//hL5F0=; b=g9l8seocKZjpvzBAfYqWLgUxvi50U+4lbExhFyLxQsEw8ufAQExFswIFEUrfTptRYF c1SeKFuCVxbTrmaMLsIs9M1jOL5yQShu7d06NKd7esDINBUTPLkbvLMfHw7vC/JUek70 t1BMHuuuS7KZ1wl+tlTtdo7rCunAQDEoTDgVVeYqOwLGzzl4gAGkZDD1JO0C0DIe9ic5 cbomvoZJzaDy9wNsvagyoPx/oLHP1L5JKwmAdyDfueBvjEfXkVUEGS5z3l1XT4SqF2Qv tyhO7H/8WJs3SxK5UjBRLAB0Eiph2GrmZg2wqJ9ODJOdGTpIO45gdvCDgIEQT/pjmznt uHBQ==
X-Gm-Message-State: APjAAAX0+B3eUIlcEjuqgrZRvkA5X6E07R4NhPEfK+7wYgtKA0GUQIFc j+O/33OGWzDQZT450og5B5tJiA==
X-Google-Smtp-Source: APXvYqxoEC+fYi1mJMIi+I/nY8b8f8AZXD+3d04TGM4V+VToxq7jrC4kr/bNBj/M7iQ4/K2/+c57xQ==
X-Received: by 2002:ac8:44c4:: with SMTP id b4mr10204576qto.224.1565985310579; Fri, 16 Aug 2019 12:55:10 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:7ded:86d1:e927:7777? ([2001:470:c1a2:1:7ded:86d1:e927:7777]) by smtp.gmail.com with ESMTPSA id y26sm4374621qta.39.2019.08.16.12.55.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Aug 2019 12:55:09 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <7172E0DB-7782-41DD-B344-02694035BD20@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E9EFA07-4219-4C3B-94DA-8AF12A5536DA"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 16 Aug 2019 12:55:06 -0700
In-Reply-To: <2ECE253B-00C9-4857-A659-83BA3322FE5C@gmail.com>
Cc: ADD Mailing list <add@ietf.org>
To: Bret Jordan <jordan.ietf@gmail.com>
References: <LO2P265MB1327CC055667B8F972AEDC04C2AC0@LO2P265MB1327.GBRP265.PROD.OUTLOOK.COM> <CAH1iCiqt0YODvxuQf-_Wm3zdC0HAcyRTJ-jMYLe-kMKeLEy9zQ@mail.gmail.com> <09178E42-08B2-4958-A1C8-AF507AEE8834@fugue.com> <LO2P265MB13270AAEC9901FB41632D2F0C2AF0@LO2P265MB1327.GBRP265.PROD.OUTLOOK.COM> <0BDD4F7F-7301-476A-80DA-0CC84EE4557D@fugue.com> <B0B173E7-DA2F-40B9-9DE5-412D4808E9A2@gmail.com> <2BE3565E-4D1D-4C3D-8E5E-9BBF0A6C76EC@fugue.com> <2ECE253B-00C9-4857-A659-83BA3322FE5C@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/6pEW9K90jG73DpErAxVVVobu6i0>
Subject: Re: [Add] When Two Worlds Collide
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 19:55:15 -0000

On Aug 16, 2019, at 12:19 PM, Bret Jordan <jordan.ietf@gmail.com> wrote:
>  It is your opinion that a QuadX DoH resolver is less dangerous than the DNS (DoH or Do53) that is provided by your internal network. 

I’m sorry, maybe I haven’t been very skillful in responding to you on this.   I think I see where the disconnect is now.   I don’t actually think this.   Let’s enumerate the players here:

Do53 resolver on the local network
DoT resolver on the local network
DoH resolver on the local network
DoH resolver on QuadX, as you put it
DoH resolver on my home network, reachable from outside
DoH resolver on my ISP’s network, reachable from outside

And:
Locked down host, can’t access any resolver other than that configured by the operator
BYO host, not controlled by the operator

If we have host (1), is it better off communicating with resolvers (1), (2), or (3)?   That is, what should the local operator configure?

The answer is that it depends on the network.   If the network is locked down as you say, and the device can’t leave the facility, then it’s probably just a matter of whether the operator cares that the queries are going over the wire in the clear.  If, on the other hand, the network can’t be locked down quite that tightly, then it may be worthwhile to have PKI authentication.   If I were setting this up, I’d install a cert on all site-owned devices, and use that to validate that I’m really talking to the DoT or DoH resolver I intend.   Now, whether to use DoT or Doh is just down to whether I’m concerned about blocking.   If I’m concerned about blocking, DoH is better; if I’m not, I think it’s about even.

Now, what if we have device (2) on a locked-down network?   The operator has two choices.   Either allow the device to do DoH, or block all outgoing connections that aren’t explicitly permitted, including connections to port 443.   If such hosts want to connect out, they have to go through a proxy that can look at the HTTP traffic.

Now, consider the case of your own device.  If you are carrying it around, there will be places where your traffic can be snooped.   But it’s not going to be easy to aggregate it (probably, depends on the operators of the networks amongst which you wander, and the configuration of your handset).  If you connect to resolver (4), then your queries can be aggregated and perhaps correlated with your web traffic.   I agree that that’s bad, and something to try to avoid.

I also agree that a resolver on your home network that you connect to from off-site may be better than (4), even though it allows your ISP to track your DNS traffic.

But what I was talking about was not this sort of modeling.   What I was talking about are simply the security properties of the various players.   Any DoH or DoT resolver can be authenticated, because you are connecting to it over TLS.   No Do53 resolver can be authenticated.   If you are able to authenticate the network, meaning that you are using 802.1X and evaluating the cert in a secure way (which is not trivial to configure), and you know that it is operated in such a way that a rogue Do53 resolver would not be reachable by your device, then when you are on that network, that resolver is equivalently safe whether you are talking to it with Do53, DoT or DoH.   When you are on some other network, it is only safe it you talk to it using DoH or DoT.

Another security property: DoH can be used on any network where HTTPS traffic is allowed to exit without being examined.   Sure, you can maintain a blocklist, but this is going to be a losing battle: the people who are motivated to make DoH work will figure out ways to make it work around your block list.

Another security property: DoT can be blocked, because it doesn’t look just like HTTPS traffic.

These security properties are facts.   Which resolver is safer to use is an opinion.   I have a great deal of sympathy for your opinion about QuadX resolvers, and had no intention of arguing with you about that opinion.   Where the disconnect came in is that it appeared that you were contradicting facts in the process of arguing your opinion.