Re: [Rats] Comments on draft-birkholz-rats-architecture-01
"Smith, Ned" <ned.smith@intel.com> Mon, 15 July 2019 14:07 UTC
Return-Path: <ned.smith@intel.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 A6B25120157 for <rats@ietfa.amsl.com>; Mon, 15 Jul 2019 07:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 5O6qaMXwSpCK for <rats@ietfa.amsl.com>; Mon, 15 Jul 2019 07:07:15 -0700 (PDT)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 C55CF120125 for <rats@ietf.org>; Mon, 15 Jul 2019 07:07:15 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2019 07:07:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.63,493,1557212400"; d="scan'208,217";a="175104002"
Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by FMSMGA003.fm.intel.com with ESMTP; 15 Jul 2019 07:07:14 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.170]) by ORSMSX108.amr.corp.intel.com ([169.254.2.65]) with mapi id 14.03.0439.000; Mon, 15 Jul 2019 07:07:14 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Ira McDonald <blueroofmusic@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: Nicolae Paladi <nicolae.paladi@ri.se>, "henk.birkholz@sit.fraunhofer.de" <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>, Thomas Hardjono <hardjono@mit.edu>, "monty.wiseman@ge.com" <monty.wiseman@ge.com>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>
Thread-Topic: [Rats] Comments on draft-birkholz-rats-architecture-01
Thread-Index: AQHVNM6n08a7P12bmUyVFL6zYsL3BKbArEYAgAengoCAAMI5AIABhyoA
Date: Mon, 15 Jul 2019 14:07:13 +0000
Message-ID: <E7299F99-54D4-47FA-A439-F1D8CB7D1353@intel.com>
References: <0189ed44bcf749c18e9b6612b2728553@oc11expo23.exchange.mit.edu> <8C52026F-A4D1-4CA5-901A-C20CC2396DF5@ri.se> <20190713023817.GU16418@mit.edu> <CAN40gSuge3=-dKTtUz2bWVTzBDX0rqmr1sj=NT_-OVRH90o=9A@mail.gmail.com>
In-Reply-To: <CAN40gSuge3=-dKTtUz2bWVTzBDX0rqmr1sj=NT_-OVRH90o=9A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1a.0.190609
x-originating-ip: [10.251.17.101]
Content-Type: multipart/alternative; boundary="_000_E7299F9954D447FAA439F1D8CB7D1353intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ABJnvh557cjk3X4XaxpteKABFsw>
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: Mon, 15 Jul 2019 14:07:19 -0000
I think both perspectives are correct. If the context of evaluation is an access decision then trust is binary. If the context is analytics, logging or risk management then trust is (can be) probabilistic. The relying party has the necessary context. The main objective for RATS is to define Attester-Verifier interactions. I’m just wondering, for the purposes of RATS architecture, if we need to resolve this question now? On 7/13/19, 7:11 AM, "Ira McDonald" <blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>> wrote: Hi, About binary "trustworthy". This is a fundamental fallacy. Neither "trustworthy" nor "secure" are *ever* binary. That's basic to the security by design approach. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com> PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote: 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 _______________________________________________ RATS mailing list RATS@ietf.org<mailto:RATS@ietf.org> https://www.ietf.org/mailman/listinfo/rats
- [Rats] Comments on draft-birkholz-rats-architectu… Thomas Hardjono
- Re: [Rats] Comments on draft-birkholz-rats-archit… Nicolae Paladi
- Re: [Rats] Comments on draft-birkholz-rats-archit… Benjamin Kaduk
- Re: [Rats] Comments on draft-birkholz-rats-archit… Ira McDonald
- Re: [Rats] Comments on draft-birkholz-rats-archit… Laurence Lundblade
- Re: [Rats] Comments on draft-birkholz-rats-archit… Nicolae Paladi
- Re: [Rats] Comments on draft-birkholz-rats-archit… Ira McDonald
- Re: [Rats] Comments on draft-birkholz-rats-archit… Smith, Ned
- Re: [Rats] Comments on draft-birkholz-rats-archit… Ira McDonald
- Re: [Rats] Comments on draft-birkholz-rats-archit… Adrian Shaw
- Re: [Rats] Comments on draft-birkholz-rats-archit… Laurence Lundblade