Re: [Rats] Comments on draft-birkholz-rats-architecture-01

Benjamin Kaduk <kaduk@mit.edu> Sat, 13 July 2019 02:38 UTC

Return-Path: <kaduk@mit.edu>
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 628D6120020 for <rats@ietfa.amsl.com>; Fri, 12 Jul 2019 19:38:32 -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 GtwF4jy9G5nY for <rats@ietfa.amsl.com>; Fri, 12 Jul 2019 19:38:30 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3762D120046 for <rats@ietf.org>; Fri, 12 Jul 2019 19:38:29 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D2cHls003796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 22:38:20 -0400
Date: Fri, 12 Jul 2019 21:38:17 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nicolae Paladi <nicolae.paladi@ri.se>
Cc: "rats@ietf.org" <rats@ietf.org>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>, "Ned Smith (ned.smith@intel.com)" <ned.smith@intel.com>, "henk.birkholz@sit.fraunhofer.de" <henk.birkholz@sit.fraunhofer.de>, "monty.wiseman@ge.com" <monty.wiseman@ge.com>, Thomas Hardjono <hardjono@mit.edu>
Message-ID: <20190713023817.GU16418@mit.edu>
References: <0189ed44bcf749c18e9b6612b2728553@oc11expo23.exchange.mit.edu> <8C52026F-A4D1-4CA5-901A-C20CC2396DF5@ri.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8C52026F-A4D1-4CA5-901A-C20CC2396DF5@ri.se>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/6IMWZ4MxRYxQesYflJc6cNYAvjk>
Subject: Re: [Rats] Comments on draft-birkholz-rats-architecture-01
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: Sat, 13 Jul 2019 02:38:32 -0000

Cherry-picking one point...

On Mon, Jul 08, 2019 at 02:44:56PM +0000, Nicolae Paladi wrote:
> Hello,
> 
> Some comments on draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>
> 
[...]
> 7.1.1<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1>.  How the RATS Architecture Addresses the Lying Endpoint Problem
> 
> 
> 
> 
> 
>  RATS imply the involvement of at least two players (roles) who seek
>    to overcome the lying endpoint problem.  The Verifier wishes to
>    consume application data supplied by a Computing Context.  But before
>    application data is consumed, the Verifier obtains Attestation
>    Evidence about the Computing Context to assess likelihood of poisoned
>    data due to endpoint compromise or failure.  Remote Attestation
>    argues that a systems's integrity characteristics should not be
>    believed until rationale for believability is presented to the
>    relying party seeking to interact with the system.
> 
> “Likelihood” implies a probabilistic approach to trustworthiness (e.g. 42% likelihood of poisoned data”). Is that really feasible? And if so, is it actually of any use? IMO trustworthiness is binary (“trustworthy or not trustworthy”), or binary and conditional/contextual (“trustworthy if used for certain actions”).

My personal thinking here is along the lines of "this data makes me
confident that only someone who was able to subvert my supply chain and
surreptitiously replace the TPM chip in the sealed device delivered to me
would be able to forge the attestation evidence; I don't think I'm the
target of such an attack, so there's a low likeliyhood of endpoint
compromise".  Or, as James Mickens put it more glibly in
https://www.usenix.org/system/files/1311_05-08_mickens.pdf there's a
Mossad/not-Mossad distinction in the potential attackers, and if the Mossad
is a threat, you're gonna be Mossad'ed upon no matter what you do.

-Ben