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

Ira McDonald <blueroofmusic@gmail.com> Sat, 13 July 2019 14:11 UTC

Return-Path: <blueroofmusic@gmail.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 E4E59120045 for <rats@ietfa.amsl.com>; Sat, 13 Jul 2019 07:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bO4TlUaOewg4 for <rats@ietfa.amsl.com>; Sat, 13 Jul 2019 07:11:33 -0700 (PDT)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3016612028E for <rats@ietf.org>; Sat, 13 Jul 2019 07:11:33 -0700 (PDT)
Received: by mail-yw1-xc29.google.com with SMTP id l79so5958296ywe.11 for <rats@ietf.org>; Sat, 13 Jul 2019 07:11:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/XTBk1sPkVRn8Ekp28DSPZbP67XiFBTiLtUh0lSKvJQ=; b=NNC0p7CxhvXGYjgPSP01hd5Y1Kw0/OC0/SVHpWVigPc2hZW7I0FhwZVMG93V8Tw0G2 x/wlcBSgj+8p3fBG3CP6txa5nxp7h7tCUOM0gfDXQXM/HsOfgAsfTvThSWdfErMkGPnJ iw7tCE4xXjDOKqmxveGBxbeyE74gQmFIG2EStRC3Ser2jfqqBu5gG2hWSbBAS0BxlDxP slF8L+NsKke8Pa9sDVGU1YD6HJwtEojy/rSsOr99lmNuA8bM3MZYkKICxjBPgpp8YIRW p4vaooubwdnFbx61qL0AQWgRggCsxi2nxPMmPWK5eOiKhGFjsrtn0QuQGX2TouAhZeOb QsLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/XTBk1sPkVRn8Ekp28DSPZbP67XiFBTiLtUh0lSKvJQ=; b=co0Fakhs9eFLJExybh0Y/hbN/5EOmVzD+JRjsh68FGdLthdiFPqoS9+7fnIpZ4qzWr mIt7zb3noyj4oxZzI52d0WSYueVNpzSCmo6lNMyqd+EBJmkZjJTM4tER0kuALz4m3sjD Hx63UrzV9LrDrU2ydYkvP99Ko47nvnvaYgjFrHnUcuxMsZYCg0VttC6kWFylB3pDu5Cq cTiK4J1V6EX0ue5M4KOyEU3Gt6vJ/Id25zN3Sk59oYUi0S3EZhlvtqDyoPHCPwe9/7Hf dY9GigUmv3a9mlvjiRHcLHMxWkd9eYOVBFNk/UUULvc+3BZ3Jz/d/MrR/FatP9WGEKOT G+xg==
X-Gm-Message-State: APjAAAVebCcQ5utz3lyxdHLBGvzgsPYDXhE2Ib9k/cIpij9X8VIr+Ndy oT1yVTPZY++qrBUYexb8QUd7cTeCNOGp792sv08=
X-Google-Smtp-Source: APXvYqxfE2ax5xXT8grR6S9brfVS5P8WUHebndyTLRMJj2tXegD2R5uxaTH4hOiIw8F4tdvkuV7Pn6CHO8J61AS7FW0=
X-Received: by 2002:a0d:c044:: with SMTP id b65mr9349986ywd.273.1563027092193; Sat, 13 Jul 2019 07:11:32 -0700 (PDT)
MIME-Version: 1.0
References: <0189ed44bcf749c18e9b6612b2728553@oc11expo23.exchange.mit.edu> <8C52026F-A4D1-4CA5-901A-C20CC2396DF5@ri.se> <20190713023817.GU16418@mit.edu>
In-Reply-To: <20190713023817.GU16418@mit.edu>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Sat, 13 Jul 2019 10:13:26 -0400
Message-ID: <CAN40gSuge3=-dKTtUz2bWVTzBDX0rqmr1sj=NT_-OVRH90o=9A@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Ira McDonald <blueroofmusic@gmail.com>
Cc: Nicolae Paladi <nicolae.paladi@ri.se>, "Ned Smith (ned.smith@intel.com)" <ned.smith@intel.com>, "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>
Content-Type: multipart/alternative; boundary="0000000000009ac679058d909aa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/HNAQ67aYWPGBgLEbjewwfK0j2tI>
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 14:11:36 -0000

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
PO Box 221  Grand Marais, MI 49839  906-494-2434



On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <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
> https://www.ietf.org/mailman/listinfo/rats
>