IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 05 July 2019 18:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 E8395120155 for <rats@ietfa.amsl.com>; Fri, 5 Jul 2019 11:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 aCHUSXIvW4iL for <rats@ietfa.amsl.com>; Fri, 5 Jul 2019 11:47:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA13C120148 for <rats@ietf.org>; Fri, 5 Jul 2019 11:47:15 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DB9538196; Fri, 5 Jul 2019 14:45:17 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3ABF5B26; Fri, 5 Jul 2019 14:47:14 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carl Wallace <carl@redhoundsoftware.com>, "rats@ietf.org" <rats@ietf.org>
In-Reply-To: <D93100A6.E0A23%carl@redhoundsoftware.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> <bf003513-209a-7d5f-a9a5-58ade6c23545@gmail.com> <21417.1560911502@dooku.sandelman.ca> <fbc05f84-232b-7ca6-47c1-9b23d73e47ca@gmail.com> <CAFyqnhUkVaYMtjpB9wa4h6hEwd=h3hXHkCr9w8bd8LSXEo0ckA@mail.gmail.com> <D93100A6.E0A23%carl@redhoundsoftware.com>
X-Mailer: MH-E 8.6; nmh 1.7+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: Fri, 05 Jul 2019 14:47:14 -0400
Message-ID: <2294.1562352434@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ogN4wsjpB4Rc_7KCjkslNQuY248>
Subject: Re: [Rats] Android attestations: Re: 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: Fri, 05 Jul 2019 18:47:21 -0000

Carl Wallace <carl@redhoundsoftware.com> wrote:
    >> There's a tension here between enabling more use cases and maintaining
    >> increasing the security of existing use cases. We recognize that GP
    >> and many  others disagree with us on how to balance the issues, and
    >> that perhaps we're wrong, but we have to respond to the Android
    >> ecosystem as we see it.

    > Re: more use cases, the ability to encrypt a key attestation in TEE/SE
    > for a specific provisioning end point would be nice to have (to conceal
    > a challenge password while in transit, for example).

You have asked for a specific ability/feature: the ability to encrypt
a claim using trusted code.  I don't know if that's a symmetric or
asymmetric encryption.  I don't know who you need to hide the claim from.  It
seems that it can't be done by an app.

Can you explain this in terms of the problem that you are trying to solve,
or the threat you are trying to mitiate rather than a solution?

When you say challenge password, I think you mean some kind of nonce
a relying party might send to the device in order to maintain freshness.
That also seems like a solution to a problem, the nature of which I'm unclear
about.

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

v2.23.0 | Report a Bug | By Email