[Teep] use case document comments

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 15 March 2017 01:07 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A29B131780 for <teep@ietfa.amsl.com>; Tue, 14 Mar 2017 18:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 FkFsTn4xrU7O for <teep@ietfa.amsl.com>; Tue, 14 Mar 2017 18:07:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536F2129468 for <teep@ietf.org>; Tue, 14 Mar 2017 18:07:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 95F97E1F7 for <teep@ietf.org>; Tue, 14 Mar 2017 21:30:03 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 26E3D636E0 for <teep@ietf.org>; Tue, 14 Mar 2017 21:06:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: teep <teep@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Tue, 14 Mar 2017 21:06:59 -0400
Message-ID: <19661.1489540019@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/twmxj2GA_chf5NVme_bdNJ4Fp-w>
Subject: [Teep] use case document comments
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 01:07:03 -0000

Thank you for the use case document.
I think that there is a need in the use case document to explain who owns the
code inside the TEE.  (It seems that a device like a smartphone would need a
multitude of TEEs)

3.1. Use Case 1 - Payment

So on the one hand the document suggests that the TEE will contain personal
information relating to payment, so be securely unlocked by the end user via
some kind of SecureAttentionKey interface.   A private key, or perhaps an
anchor for a blockchain signer....
So the end user needs to intimately control what code is inside (i.e: be able
to delegate that trust to a party that they trust).

Then the document says:
     For the development of the relevant TA of SP, the
     use of OTrP can easily send the latest trusted application to the
     device.

I get the impression that the bank is going to send updates to the trust
application.   But, it's the bank that I'm going to dispute a payment with,
so in fact, I can't let them create the audit trail at my end.

No use case was given for media, yet that was mentioned.
Nor Enterprise.

In each case, I think that the contents of the TEE are controlled by a
different party.  And each party seems to want to control the screen and
keyboard.


3.2.  Use Case 2 - IoT

The only example here given is smart door locks.
I think that this is really confused.   The most important thing the TEE can
do is to provide original bootstrap process, and then yes, storage and update
of session keys.   After putting all that in the TEE, what's actually left?


====

Based upon what I have read so far, I can't see a role for the IETF, but I
continue to read with an open mind.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-