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

Michael Richardson <> Sun, 16 August 2020 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A272A3A0B6A for <>; Sat, 15 Aug 2020 18:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LE_KlzqIZ2xC for <>; Sat, 15 Aug 2020 18:10:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C30EA3A0B69 for <>; Sat, 15 Aug 2020 18:10:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A242389DA; Sat, 15 Aug 2020 20:50:04 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id 35BePpx402nx; Sat, 15 Aug 2020 20:50:03 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 00DFF389D9; Sat, 15 Aug 2020 20:50:02 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6B6A4136; Sat, 15 Aug 2020 21:10:51 -0400 (EDT)
From: Michael Richardson <>
To: Laurence Lundblade <>,
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sat, 15 Aug 2020 21:10:51 -0400
Message-ID: <7785.1597540251@localhost>
Archived-At: <>
Subject: Re: [Rats] Attestation of implementation vs authenticity of service
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Aug 2020 01:10:57 -0000

Laurence Lundblade <> 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
In Canada (at least), as a shareholder of a publically trade company, I'm
apparently forbidden from communicating with other shareholders, except via the

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.

    > 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.

Carsten Bormann <> wrote:
    > if you are talking about HTTPS, there is exactly one claim:  The
    > service is speaking for a specific name (e.g.,  All
    > other claims are funneled through this one very special one.  Of
    > course, the TLS handshake could be leveraged to do more than this one
    > claim, but that is not what happens in HTTPS.

The CA system could also review the Bank's systems on a regular basis.
Claims could be embedded in the HTTPS server certificate, and this is already
in the architecture, in the spider diagram.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-