Re: [Rats] Attestation key material in architecture document

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Thu, 30 July 2020 10:31 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 5B9BA3A105E for <rats@ietfa.amsl.com>; Thu, 30 Jul 2020 03:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ii7tqlHpfAuA for <rats@ietfa.amsl.com>; Thu, 30 Jul 2020 03:31:23 -0700 (PDT)
Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 6A3DB3A105C for <rats@ietf.org>; Thu, 30 Jul 2020 03:31:22 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FbBwBNoCJf/xwBYJlggQmBTIMXgTM?= =?us-ascii?q?KhCuRGJtQMgsLAQEBAQEBAQEBBgEBGAsKAgQBAQKESgKCKwEkOBMCEAEBBgE?= =?us-ascii?q?BAQEBBgQCAoZFDEMBEAGCHWGBAwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEgI?= =?us-ascii?q?NNh43EgEeAQEBAQIBAQEhDwEFNhALCQIOBAYCAiYCAicgAg4GAQwGAgEBgyI?= =?us-ascii?q?BglwfBQuTB5sEdoEyhVKDO4E6BoEOKgGGTYR8gTQPD4FMP4ERJw+CLC4+glw?= =?us-ascii?q?BAYR1gj4iBJAFgmmicCkHgVqBCIEIBAuHRJEYBQoekUUGjimSH4ozlGwCBAI?= =?us-ascii?q?JAhWBaoF7TSRPgmlQFwINkhCFFIVEcjcCBgEHAQEDCXyIGIZoAYEQAQE?=
X-IPAS-Result: =?us-ascii?q?A2FbBwBNoCJf/xwBYJlggQmBTIMXgTMKhCuRGJtQMgsLA?= =?us-ascii?q?QEBAQEBAQEBBgEBGAsKAgQBAQKESgKCKwEkOBMCEAEBBgEBAQEBBgQCAoZFD?= =?us-ascii?q?EMBEAGCHWGBAwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEgINNh43EgEeAQEBA?= =?us-ascii?q?QIBAQEhDwEFNhALCQIOBAYCAiYCAicgAg4GAQwGAgEBgyIBglwfBQuTB5sEd?= =?us-ascii?q?oEyhVKDO4E6BoEOKgGGTYR8gTQPD4FMP4ERJw+CLC4+glwBAYR1gj4iBJAFg?= =?us-ascii?q?mmicCkHgVqBCIEIBAuHRJEYBQoekUUGjimSH4ozlGwCBAIJAhWBaoF7TSRPg?= =?us-ascii?q?mlQFwINkhCFFIVEcjcCBgEHAQEDCXyIGIZoAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.75,414,1589234400"; d="scan'208";a="19372069"
Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2020 12:31:19 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaCQAVoCJf/1lIDI1ggQmBTIIobwN?= =?us-ascii?q?UMCwKhCuRGJwNCwEDAQEBAQEGAQEYCwoCBAEBhEwCgikCJDgTAhABAQUBAQE?= =?us-ascii?q?CAQYEbYVcDEMBEAGFHAEBAQMBAQEhDwEFNhALCQIOBAYCAiYCAicgAg4GAQw?= =?us-ascii?q?GAgEBgyIBglwkC5MSmwR2gTKFUoM7gToGgQ4qAYZNhHyBNA8PgUw/gREnD4I?= =?us-ascii?q?sLj6CXAEBhHWCPiIEkAWCaaJwKQeBWoEIgQgEC4dEkRgFCh6RRQaOKZIfijO?= =?us-ascii?q?UbAIEAgkCFYFqI4FXTSRPgmlQFwINkhCFFIVEQTE3AgYBBwEBAwl8iBiGaAG?= =?us-ascii?q?BEAEB?=
X-IronPort-AV: E=Sophos;i="5.75,414,1589234400"; d="scan'208";a="31814978"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2020 12:31:17 +0200
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 06UAVHcD013326 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 30 Jul 2020 12:31:17 +0200
Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 30 Jul 2020 12:31:12 +0200
To: Laurence Lundblade <lgl@island-resort.com>, <rats@ietf.org>
References: <830EC75F-B44E-4F3A-9972-D2196E480DBC@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <8d1ee7d4-bba4-a15c-28da-d3c380d265be@sit.fraunhofer.de>
Date: Thu, 30 Jul 2020 12:31:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <830EC75F-B44E-4F3A-9972-D2196E480DBC@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.206.156.41]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/VEuQIFGgR_qWo4mxGgaQymR8TFY>
Subject: Re: [Rats] Attestation key material in architecture document
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: Thu, 30 Jul 2020 10:31:27 -0000

Hi Laurence,

I updated issue #65 for you:

> https://github.com/ietf-rats-wg/architecture/issues/65

This will make it easier for the editors to address your two alternative 
proposals. I think it would help, if you are present when we discuss this.

MCR: do we plan for an editor's meeting next Tue?

Viele Grüße,

Henk

On 29.07.20 22:14, Laurence Lundblade wrote:
> I presented this slide below the IETF 108 RATS meeting today. I believe 
> it is critical that the RATS architecture allow for all uses case in the 
> slide.
> 
> In particular RATS architecture must allow for symmetric keys. TPMs and 
> public-key based crypto is too expensive for low-cost, large-scale IoT. 
> There are real use cases supported my multiple companies using symmetric 
> keys. Symmetric keys can be made secure at the verifier — we secure keys 
> for TLS at servers all the time using HSMs and such.
> 
> I do NOT want to put this taxonomy into the RATS architecture document. 
> I don’t think that is necessary. I created the taxonomy as background 
> information and as illustrative examples of real world designs.
> 
> I think there are options for adjusting the architecture document to 
> accommodate this.
> 
>     Option 1) Expand the notion of an Endorsement quite a lot.
>     Endorsements are not longer just static documents like X.509 certs
>     and/or COSE/CMS signed blobs. They are anything that conveys the
>     attestation key material into the Verifier or allows Verification of
>     the attester. They must support confidentiality.
> 
>     Option 2) Replace the term “Endorsement” with something like
>     “Verifier Input” or “Attester Trust Criteria” in the architecture
>     document as the means by which key material goes into the Verifier.
>     Endorsements still exist, but are just one type of Verifier Input or
>     Attester Trust Criteria just like EAT is one kind of Attestation
>     Evidence.
> 
> 
> I have a slight preference for Option 2). I’m interested in opinions of 
> which option to choose.
> 
> This is issue #65 
> <https://github.com/ietf-rats-wg/architecture/issues/65>, opened in 
> GitHub four months ago. It is not a last-minute/new issue. I believe it 
> is in scope with the RATS charter as the charter explicitly mentions 
> attestation key material in the Program of Work.
> 
> LL
> 
> My main point of this taxonomy was to affect the RATS architecture 
> document. There was discussion today of it being a separate document 
> perhaps outside of RATS. I’m happy for that to happen, but I don’t want 
> to write it because I have enough RATS/EAT work to do. I’m very happy if 
> other folks want to pick it up and use in other documents :-).
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>