Re: [Add] Trust and control on the Internet (was Re: fixing coffee shop brokenness with DoH)

Ted Lemon <mellon@fugue.com> Wed, 24 July 2019 15:05 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 584EB12023D for <add@ietfa.amsl.com>; Wed, 24 Jul 2019 08:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, 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 UmN1xbapWgp0 for <add@ietfa.amsl.com>; Wed, 24 Jul 2019 08:05:12 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 669991201D5 for <add@ietf.org>; Wed, 24 Jul 2019 08:05:12 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id r21so34030209qke.2 for <add@ietf.org>; Wed, 24 Jul 2019 08:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AURlNvTIpBBNLG2BC0zw1zdZkVkSv2NIb4GGEG1UqVw=; b=kfYn3eRI2mVeygDcq+K/Qpi7kIhbCtXTnzUxFuVwsEhXC7nfsJCvyMTCd3xAyo7b+A Pak+K9+30SsgxyTleWbFWoY3bRp5aNp0eJ3ULXxX7siaW+SCDBmfwF0jjzvR9jrKFWJm YeX4oe5dwcofx6FEt+WiEB0LFvXioNcReRSWwt1ekU6YAGee8S2HU00CqUZybISdyo03 VP9p6En/PPjZkAHW74fmEckwuF+pZLJRwk/rVxHv+B8G7A57vsunl77IuXqcPUXISdVI o9pL5WrTVUUqzeuvA54px9jbsYXocbyr1zfdPahTDuhGYh+qSzKYuyQ5P2Rmiw9z4jxZ Ja/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AURlNvTIpBBNLG2BC0zw1zdZkVkSv2NIb4GGEG1UqVw=; b=Yl0Yh8kJisSfgYWFhQ0obyL0/OFvKPZP4FplIMjpfNDKrWXHKP057x+rxhBjVEc8Sx nqdo3vkrmQyiUBhVgG5JfJSx4J5yj09dYob4CHcWYi4/F20i7/G0Fc/2hioF2O5+7teC vwtnS5zW29GOxRNoShO/i7FQyOoRZlwf6CJHxMEVu7q4hgHvylDBqnyyRb82Q6Qb1xwd Q5yHwJDRx2N90GgH6LrhZqfwaWI4fUDlsW/3oMkYZTOeYNIuK9y0Vs/XZm6LPIKQ7VVh al6+y58wkhqgzVK1BzzQsqqEqkwmqtflRb26FxwwRavKQqpQFGnCTvF/wU6B6GxDGX0a obAQ==
X-Gm-Message-State: APjAAAUGhNHxKC8HrluyPz7eOAJwyM88Xd8h1mGvMWENvz76A5OGX2g3 3PDEnvcclmPeDPhx6kqGxby8W1tBX0+p6Q==
X-Google-Smtp-Source: APXvYqwk6fEyB8QV49Gt5UCziHwW0E/RXeBTXQb7teynSuJV9sL6ue4ptYFxesY3tPkpVTVhPvXL7w==
X-Received: by 2002:a37:815:: with SMTP id 21mr54388250qki.257.1563980711341; Wed, 24 Jul 2019 08:05:11 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:b954:d2fe:7e59:68aa? ([2001:67c:370:128:b954:d2fe:7e59:68aa]) by smtp.gmail.com with ESMTPSA id h18sm19526098qkk.93.2019.07.24.08.05.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 08:05:10 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D89D8E0B-8E0B-4445-8276-48597DDEB2F1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ted Lemon <mellon@fugue.com>
X-Priority: 3
In-Reply-To: <555968666.24560.1563980206283@appsuite-gw1.open-xchange.com>
Date: Wed, 24 Jul 2019 11:05:06 -0400
Cc: "Diego R. Lopez" <diego.r.lopez@telefonica.com>, "add@ietf.org" <add@ietf.org>
Message-Id: <B6666564-E91E-40A8-9A5F-3B17F60A480D@fugue.com>
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E23910C@GAALPA1MSGUSRBF.ITServices.sbc.com> <14DF8769-A817-4C06-9140-80198518244F@akamai.com> <CAChr6SzH1EycAr5n+dK5BQcG=0Zsw66qE=8Rptvq7SEoEvQQ=Q@mail.gmail.com> <E5A0DAE2-A718-41EA-B490-58ABD0F31CF2@rfc1035.com> <CAChr6SzvUZS4Ru_SttiZgWtjwBuLrzc_fdewq9w-Ts+Rq_oNHw@mail.gmail.com> <9E8BD2C4-D750-4B8C-BA34-AC4425F2951D@gmail.com> <CAChr6Szo+1x6BnU2XH2A0o7CTQrQhFVPYezR7KQVLw-nWToULg@mail.gmail.com> <MN2PR21MB12134C6B57220E1B8BF5C811FAC60@MN2PR21MB1213.namprd21.prod.outlook.com> <CABtrr-Ue6rAom3ubJc_tPbn37T8HPGPabzX=CxT9UmiicbUtXQ@mail.gmail.com> <520325278.24189.1563973538937@appsuite-gw1.open-xchange.com> <E957E29E-66A9-4F49-8456-C2BBF9693928@fugue.com> <D36D6250-3B75-433E-B37B-BEC73F7C92DF@telefonica.com> <555968666.24560.1563980206283@appsuite-gw1.open-xchange.com>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/EdBxhpON1CnSWDhxZVpPKWBUwl0>
Subject: Re: [Add] Trust and control on the Internet (was Re: fixing coffee shop brokenness with DoH)
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: Wed, 24 Jul 2019 15:05:16 -0000

On Jul 24, 2019, at 10:56 AM, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org> wrote:
> Trust in the Internet infrastructure is a hard problem because the trust relationships are different depending on subjective judgements and preferences. 

Vittorio, I think it’s important to make a distinction between “who you might choose to trust” and “who you are forced to trust.”

In order to run an app, if the app is able to make https connections, you are forced to trust the app.   This is true whether you are aware that you are trusting it or not, and regardless of your attitude toward your service provider.

This is what I am getting at.   This is completely orthogonal to the question of “whose resolver would I choose to trust?”

What DoH does, but what any app can do whether DoH is present or not, is to make it possible to trust someone other than your service provider.  Without some covert channel that the service provider can’t block, the user does not have this choice.

But really, the user doesn’t have this choice anyway.   It’s the app that has this choice.   The user may hope that the app does what the user wants, but the user probably can’t validate that leap of faith.

We in the IETF do not have the ability to prevent the app from bypassing the ISP’s resolver.   It’s totally pointless to talk about whether or not we should do this.