Re: [Rats] draft-richardson-rats-usecases-00 comments

Laurence Lundblade <lgl@island-resort.com> Thu, 20 June 2019 17: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 6D7DC12000E for <rats@ietfa.amsl.com>; Thu, 20 Jun 2019 10:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 O2H3Y-NrQerX for <rats@ietfa.amsl.com>; Thu, 20 Jun 2019 10:25:18 -0700 (PDT)
Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 3951C1200E5 for <rats@ietf.org>; Thu, 20 Jun 2019 10:25:18 -0700 (PDT)
Received: from [172.20.10.4] ([174.212.24.188]) by :SMTPAUTH: with ESMTPSA id e0oGhaxIkoaPAe0oGhq3B3; Thu, 20 Jun 2019 10:25:17 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <2978E05F-2269-4196-9C86-A69914F21404@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9EED007E-52BF-488D-BD0B-ADBB63B93297"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 20 Jun 2019 10:25:15 -0700
In-Reply-To: <CAFyqnhVpzsLbeTto3oREYSa8UXTGzrt9DuhD=mn6W6XRE65rkw@mail.gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Thomas Fossati <Thomas.Fossati@arm.com>, "rats@ietf.org" <rats@ietf.org>, Anthony Nadalin <tonynad=40microsoft.com@dmarc.ietf.org>
To: Shawn Willden <swillden@google.com>
References: <MW2PR00MB03963ABEB87211AD28A16240A6490@MW2PR00MB0396.namprd00.prod.outlook.com> <12503.1552447661@localhost> <219648D6-188A-429D-A13F-ED6155DE9016@island-resort.com> <14288.1553710783@dooku.sandelman.ca> <4EB6FF13-2DAF-4BDC-AC90-C46720D61AF0@arm.com> <21349.1560911427@dooku.sandelman.ca> <CAFyqnhVpzsLbeTto3oREYSa8UXTGzrt9DuhD=mn6W6XRE65rkw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfF9OzbDN4Jw9KAPEbd16YvD8+BQKTewEcqLBB812NeROcBz+2jOdkL16APAXCE9SxQJEm7zESOsK4xNgLe3NMYMFOB91zUJrEZZGS6vck6V4EBo/0eaM sa8LeE3TrNrQPeGmWNeg/noQdwODsmTC7fw4kCbhLsCrMddRDBLw8fwQAmrU8hmvuRWuxddmrZOSBGxN3pP84Oql2wSnl8/l5CpEI+nNj3w7iIqxxGmCstOh EyukT7xYwrdufoQwwaSnnjzlaR45KYiRulJqIhzK/33JcQH3w/JTq8t8dAi/4uzctAAZbAmnLu9/9LXQu9VnYg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/G07qObdilNKqe80B8dxDir1xPMk>
Subject: Re: [Rats] draft-richardson-rats-usecases-00 comments
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: Thu, 20 Jun 2019 17:25:21 -0000

> On Jun 20, 2019, at 5:52 AM, Shawn Willden <swillden@google.com> wrote:
> 
> Thank you. It was a really interesting read.
> What I learnt is that Android mostly attests to the location of a device
> signing key.
> 
> This is correct.  Originally, keystore attestation was intended *only* to prove that a key (a) lived in a thought-to-be-secure environment and (b) that the key had a certain set of properties.  The scope has expanded a bit to also attest to some bits of information about the device state, at least as it was at boot time.

A few other things that seem useful and may be implemented in some cases:
That the key use is gated by user verification like a fingerprint match. This is immensely valuable IMO.
That there are timer throttles that govern the rate of key use.
Knowing which application (e.g. Android app) requested the attestation.
Allowing the application to include custom data in the attestation (it must be marked as as less secure than other data in the attestation). 
Inventory of some or or all of the SW on the device.

A lot of these are useful as risk signals or cross-checks for payments and such.

LL