Re: [Rats] Attestation of implementation vs authenticity of service

Laurence Lundblade <lgl@island-resort.com> Tue, 18 August 2020 19:25 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCE13A0A97 for <rats@ietfa.amsl.com>; Tue, 18 Aug 2020 12:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 7g2Ib2vtbKcC for <rats@ietfa.amsl.com>; Tue, 18 Aug 2020 12:25:52 -0700 (PDT)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A5D3A0ABB for <rats@ietf.org>; Tue, 18 Aug 2020 12:25:52 -0700 (PDT)
Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 87F0k6zrIXBtn87F1kZg30; Tue, 18 Aug 2020 12:25:51 -0700
X-CMAE-Analysis: v=2.3 cv=O5ZHQy1W c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=l70xHGcnAAAA:8 a=K6EGIJCdAAAA:8 a=cauk0CUAAAAA:8 a=8pif782wAAAA:8 a=QdydKHLRhsMtKogxFcwA:9 a=WKvYoJsGByY9ySTb:21 a=c2AjFEKETSxgnPYB:21 a=QEXdDO2ut3YA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=L6pVIi0Kn1GYQfi8-iRI:22
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <7785.1597540251@localhost>
Date: Tue, 18 Aug 2020 12:25:50 -0700
Cc: rats@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4C3AD8B-BCB7-4093-8DF0-9D9AFFD5E7FF@island-resort.com>
References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> <7785.1597540251@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-CMAE-Envelope: MS4wfBR8xG3fiTaRtbanltaeW7ldoI5wbm20HgiujmYyaFmTqscH471knG0MVhK/h30GOkKRkjuRI5kYfBSo5G1lN4Os0sfWBiafd3SY2OZ4pYtxwZHrEorZ 8SrSkxFmAQmgpuG2PIYJ2EgQgdT947PWlKWTsvdD0dmu1qGA5AaI2xYyGUOsfQujXqagzkxxtYWJeDytK9Wo/rfWr9hH8N9XceI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/BV3Ltn1BCkkrW6uQjagJBLSjosc>
Subject: Re: [Rats] Attestation of implementation vs authenticity of service
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2020 19:25:54 -0000


> On Aug 15, 2020, at 6:10 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Laurence Lundblade <lgl@island-resort.com> wrote:
>> Service providers (e.g., web sites) use whatever HW and SW they want to
>> use. As a user of the service we don’t care what HW and SW they
>> select. We trust the service provider to pick good HW and SW and to
>> configure and operate it correctly. They might change the HW and the SW
>> and as a user we won’t know.  For example we trust Bank of Xxx to
>> operate their banking web site correctly with little concern for their
>> HW. This is why attestation of the HW and SW is not so useful to the
>> user of a service.
> 
> The only reason that I do not demand knowledge (attestation) about how my
> Bank operates is because I don't (individually) have the economic clout to demand it, and
> the users suffer from a Collective Action Problem
>  https://www.britannica.com/topic/collective-action-problem-1917157
>  https://en.wikipedia.org/wiki/Collective_action_problem
> In Canada (at least), as a shareholder of a publically trade company, I'm
> apparently forbidden from communicating with other shareholders, except via the
> company.
> 
> So I don't think that the difference has anything to do with what we want,
> but rather what has been possible up to now.
> 
> My bank regularly makes very poor technology choices.
> They also seem very reluctant to publically document their processes.
> Unfortunately, I can't vote with my wallet, because the other ones are as bad or worse.

Collective action for banks exists in a big way in the form of government regulation. For other services its usually reputational. Facebook’s isn’t so good right now. We all seem to trust GitHub well enough based on reputation.

Most folks decide to trust services based on reputation - what we read in the news, what we hear from friends and such. Sometimes we want to see if they meet government regulations, have deposit insurance or such. Sometimes we read the terms of service (which are scary for a bank), but mostly we don’t. 

I’m thinking about general population here, not super-smart IETFers or lawyers that read terms of service.

But I doubt even us IETFers would care if GitHub switched from Intel to ARM CPUs or from Azure to AWS. We mostly trust Microsoft to run GitHub well.


> 
>> Users of mobile phones and IoT devices are not trustworthy to pick
>> secure HW and SW. They are not professionals like the people running
>> web sites. There is little accountability against them if they pick bad
>> SW and HW. Therefor we want attestation for these usage scenarios. This
>> is why EAT, FIDO and Android Attestation exist.
> 
> This does not ring correct at all to me.
> Large media giants want assurances from manufacturers of phones that the end
> user does not have control over the video output systems, and the large
> suppliers have demanded (again, through massive differences in economic
> clout) assurances.
> It has nothing to do with the abilities of the owners.
> In fact, what is desired is assurance that the owners have in fact been
> forced not to pick their own SW.

My characterization was coarse.
- End users don’t get to choose much about the OS on a phone, maybe when to upgrade
- Some areas of devices are particularly locked down — video playback, authentication, payments (e.g. Apple Secure Enclave).
- End users do get to choose which apps they install
   - But only from an approved list
- Some end users get to use debug modes and write their own code, but when they do apps and services are disabled or they are fenced off.

I think it does have to do with the end users.

In China, the app ecosystems are a lot more wild-west than the US. There are imposter apps trying to dupe people into using them.

If I lose half the money in my bank account through a mobile app problem, I’m going to blame the bank and the bank might even be liable. The bank doesn’t want anyone accessing their online banking with anything but their app (and a browser).

Or consider allowing end users to write their own FIDO authenticators or use any authenticator available for download. Maybe one is branded as “easy FIDO” and truly is easier than most so it gets a lot of users. But underneath it is allowing the a foreign enemy nation to collect private info on citizens.

Allowing the masses unconstrained choices of SW for to access high-value services opens the door to fakes, frauds, getting duped and such.

LL