Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Laurence Lundblade <lgl@island-resort.com> Tue, 12 November 2019 05:57 UTC

Return-Path: <lgl@island-resort.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 3344712011E for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 21:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xBFMeRyliDbD for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 21:57:30 -0800 (PST)
Received: from p3plsmtpa08-06.prod.phx3.secureserver.net (p3plsmtpa08-06.prod.phx3.secureserver.net [173.201.193.107]) (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 B381D12001E for <rats@ietf.org>; Mon, 11 Nov 2019 21:57:30 -0800 (PST)
Received: from [10.141.0.126] ([45.56.150.139]) by :SMTPAUTH: with ESMTPA id UPBAi3JTQksi3UPBBiA8ln; Mon, 11 Nov 2019 22:57:29 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <9D447837-954B-4717-B4EC-22FE9A5EF36B@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBCAC51A-46E6-4C73-AE4A-0E46F3125EC2"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 11 Nov 2019 21:57:28 -0800
In-Reply-To: <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
Cc: "Smith, Ned" <ned.smith@intel.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "rats@ietf.org" <rats@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com> <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfDvNGJ0V4YsxNzja1SDho4M/j4uXXp7oV2KhPUY9PtXeph9mbOi6RhC4GKWu3nY0YRJSQloPO0wpg0vhQyVGm5ftQUSVEPVd2XSv+EB+BNlN1mdu9JKK 26DOG7ulNz1xpZFOIk7gXggfU8aTEL4Ze+NNTcBitkmsVJTJENz/F2XcxODFggMHeI9Kr3Rq0y/HDSvjYTrDmK8MNoBlkTwDtGRv3ZQjwSUbEV7Db4jG1e7O dkTyPE41tZwZnrCLlsq+QLL8eUPij2BaclSqSB5VFo6FIEcsr7Z+PA0uIevOhOHru4F2yzWwjhBPGZnBiJ7KRHHcTgIfUcZ8JjyK0js87vMLADbBEo6WXLEw KyWI7hvPcJnr8Nz8bQk3DmzPioGfOg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/iSGkeoGW0EB8i9F1kqZvjJW89GQ>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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: Tue, 12 Nov 2019 05:57:33 -0000

Clarifying questions and comments.

Where did this table come from?

Is a firewall here a typical IP-level thing that filter Internet traffic? (If so, why is that relevant?). Or is it memory protection between the attestation host (e.g. RoT) and the other parts of the system? Something else?

What is privacy here? Is it the untrackability of attestations because they use ECDAA, shared keys or such? That is privacy in the web browser / GDPR sense.

One of them is not like the other: Firmware. It typically isn’t isolated and doesn’t have a CPU.

There are other isolating execution environment approaches such as separate CPUs and virtualization, particularly Microsoft VBS.

LL


> On Nov 11, 2019, at 5:43 PM, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>; wrote:
> 
>                         Requirements?
>          +--------------+---------------+---------++---------------
>          |  RoT         | Host Firewall | Privacy ||   Solution   
>          |  Type        |   Enabled     | Needed  ||    Pieces    
>          +--------------+---------------+---------++---------------
>       1  |  SGX         | No            | No      ||
>       2  |  SGX         | No            | Yes     ||
>       3  |  SGX         | Yes           | No      ||
>       4  |  SGX         | Yes           | Yes     ||
>       5  |  TrustZone   | No            | No      ||
>       6  |  TrustZone   | No            | Yes     ||
>       7  |  TrustZone   | Yes           | No      ||
>       8  |  TrustZone   | Yes           | Yes     ||
>       9  |  TPM         | No            | No      || draft-birkholz-rats-basic-yang-module-01
>      10  |  TPM         | No            | Yes     ||
>      11  |  TPM         | Yes           | No      ||
>      12  |  TPM         | Yes           | Yes     ||
>      13  |SecureElement | No            | No      ||
>      14  |SecureElement | No            | Yes     ||
>      15  |SecureElement | Yes           | No      ||
>      16  |SecureElement | Yes           | Yes     ||
>      17  | Firmware     | No            | No      ||
>      18  | Firmware     | No            | Yes     ||
>      19  | Firmware     | Yes           | No      ||
>      20  | Firmware     | Yes           | Yes     ||