Re: [Add] [EXTERNAL] Re: My longer list of questions [from partial distribution at the MIC]

Ted Lemon <mellon@fugue.com> Sat, 27 July 2019 16:51 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 C4BB312016A for <add@ietfa.amsl.com>; Sat, 27 Jul 2019 09:51:30 -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 MTqjt6-Wwf21 for <add@ietfa.amsl.com>; Sat, 27 Jul 2019 09:51:28 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 D39FB120165 for <add@ietf.org>; Sat, 27 Jul 2019 09:51:27 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id m14so15676383qka.10 for <add@ietf.org>; Sat, 27 Jul 2019 09:51:27 -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=TOQp4HlrNHzX2JhhxoMN22n/Bwik6CvCBsFplGyWIrw=; b=IKmKds9Eb7CL0IL1qDWKxmfkaWVoKMaqEgvXk8OS6xdKeicVdeQTJk6anT6fbbZqiN /sSNWLw6urdoPsvl8SmUKI+s9pZEXZi2/XB13uqQHLJZeUiH63A2g0rshns8OMB65EiF V2JbqHGAFVVIuZa6uedc6LxsnZeVrj2Uu4HMTjewhgiIY7S8Ou/RyiJTIvcN5vlp6Asb mF8WKMFIJvyt59LeZk2AemXy2xGf/eadxc2K2zCjtU06WhbWm7X64HqXvrN7CtFKZgfd /+u7vAQolim9TbMhqrIDe86UhrGEIeISuqbifV2hTMfb/Uicns6558CyC7M1dYxXW+wC RmeQ==
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=TOQp4HlrNHzX2JhhxoMN22n/Bwik6CvCBsFplGyWIrw=; b=qCmEYeR8UIN4Tfsy1lho1mLS9jccnQa1lI6j2RGsTES4gRGLuQ7CZOwNZQLYBV9+qN +PkUKLP5K/ZL48VYvGqXtoPQ6Zuf0afCMkg5I3c4PHUy7gCbMNQYu0jRpuSKjpTiJAq3 Qf5hvkKG6FcWJLHOJJZgDHrSt1pu5TvQKapTLIaaDbjGgmUffHG/aDt3ruathzk3nMOY +yIEYVTJD0Yf66DgZJYWtBpiDmYgN36lAEPv+KX5WsinjjDmwFwkNExxFbgxhXgNoQ7/ WMzsmGdQVx21Z/W9bXOytTmLCffsjF+HfVPgaQHVeLOqjS6vfxJSFR7H0jPRfBoXxfNY 5+CA==
X-Gm-Message-State: APjAAAXYt2Zkfk59CjZV9HCuWYf1CXCQfk4k0tLV0oIlWTDSrXlu7eI9 yajiW0W+b63d5ZLtaTpG9bSbJw==
X-Google-Smtp-Source: APXvYqx9OUlpgsHkf9cETjtLbEmItjQEy17mtS7pWOWGWi7Gx4sGkUPn9jXgB9GORDp32sW5pmWNdw==
X-Received: by 2002:a37:7cc5:: with SMTP id x188mr65678240qkc.456.1564246286832; Sat, 27 Jul 2019 09:51:26 -0700 (PDT)
Received: from [10.0.30.16] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id y42sm36986354qtc.66.2019.07.27.09.51.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jul 2019 09:51:26 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <47F10041-6E3E-49D0-AE83-7EB0BE1FD91F@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F47948F6-8EE0-4292-8749-1B56A6C1FD51"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 27 Jul 2019 12:51:24 -0400
In-Reply-To: <B559AB20-47D9-41F2-B520-3989B6F4D92F@nbcuni.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Paul Wouters <paul@nohats.ca>, "add@ietf.org" <add@ietf.org>
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
References: <ybl8ssna2en.fsf@wu.hardakers.net> <DBF126D4-ACE7-419A-A608-2A7114F816E0@frobbit.se> <CAChr6Sw8ZuTxE0iha+tkuE2Bg7zOtKCHUMYXVkDKg84McPh-aw@mail.gmail.com> <112384FB-C68D-4308-8ED9-C0BBF615751D@frobbit.se> <CAChr6Swh_9w8tRacYf+=QWarQ3-4Kr===ZjPogGGGRCRgPObEw@mail.gmail.com> <1C02AB5B-D01E-49F6-86CE-BAEF4779E776@frobbit.se> <alpine.LRH.2.21.1907261512390.22335@bofh.nohats.ca> <477F76EA-3945-4D77-BEAE-FFCC01B21FF8@nbcuni.com> <64bcfc51-6f3d-ae24-4de5-d0eb89975c66@cs.tcd.ie> <B559AB20-47D9-41F2-B520-3989B6F4D92F@nbcuni.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/vGG1h4ubzb9tab6o31ZyzQ9oLC4>
Subject: Re: [Add] [EXTERNAL] Re: My longer list of questions [from partial distribution at the MIC]
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: Sat, 27 Jul 2019 16:51:31 -0000

On Jul 27, 2019, at 12:23 PM, Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:
>  My key point was that there is not data support for the assertion that general users trust a few big companies more.

This is a really puzzling observation.  I guess it depends on what you mean by trust.   You could mean “put their trust in” (operational trust) or you could mean “feel that they are trustworthy” (emotional trust).  Or possibly some third thing I didn’t think of! :)

So if you mean “feel that they are trustworthy,” I think this is true—there’s plenty of evidence that people do not think that various large corporations are trustworthy in that sense.

However, what we mean by “trust” when we are talking about protocols is operational trust: that they actually make a choice to trust the corporation regardless of how they feel about the corporation’s trustworthiness.   We do this all the time, and I suspect everyone here is familiar with the feeling of reluctantly allowing a corporation to be “trusted” when we feel fairly certain they are not worthy of that trust, simply because we have no choice.

In that sense, there is a tremendous amount of data to support the conjecture that users trust a few big companies more.  It’s not because they trust them in the sense of considering them trustworthy, but because they have no choice but to trust them: the small company that might actually be more trustworthy (or might not) is not an option for them.   The service that the end-user wants is not available from that small company.

In this sense, then, we can see that in fact users do trust various large companies.   When they use the resolver offered by their ISP, they are trusting their ISP.   When they use the resolver in the coffee shop, they are trusting the coffee shop.   When they choose to use 8.8.8.8., they are trusting Google, and they are also trusting their ISP not to intercept their connection to Google, if they are using Do53.   If they use 1.1.1.1, the same is true.   If they use 8.8.8.8 with DoT, they are trusting Google, and if their ISP wants to intercept the connection, they will know that this is happening.   But it’s pretty easy for the ISP to do this.

If they want to use 8.8.8.8, and either they know their ISP is not trustworthy, or know that they will sometimes be using ISPs that aren’t trustworthy (the coffee shop use case), then they have no choice but to use DoH, because it’s not really something that a coffee shop would be able to intercept or block, even if they wanted to.

In most cases, I think it’s safe to say that the users just take the default behavior.   So if they have a smartphone, they just trust the vendor to act in their best interests (whether they actually believe the vendor will do this or not).   If they are running Firefox or Chrome, they will trust Mozilla or Google to act in their interest, which may mean using DoH, whether either of these orgs is actually acting in their interest or not.

And if they are using the operating system resolver, they may legitimately hope that what they are buying is an O.S. that doesn’t betray their trust by sending personally-identifying information down the DoH channel.   It might even be possible for a small company to make money offering this as a service, to those people who want it.

So I hope this clarifies the distinction between emotional trust, for which I believe there is plenty of data that actually supports your assertion, and operational trust, for which there is data that pretty definitively contradicts it.