Re: [Rats] Attestation of implementation vs authenticity of service

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 18 August 2020 13:30 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 F28F93A09FD for <rats@ietfa.amsl.com>; Tue, 18 Aug 2020 06:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 UGHtVRUz-jw8 for <rats@ietfa.amsl.com>; Tue, 18 Aug 2020 06:30:20 -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 5D01A3A09FB for <rats@ietf.org>; Tue, 18 Aug 2020 06:30:18 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HABgB21ztf/xoBYJlfgQmBSoMagTM?= =?us-ascii?q?KhC2QfiWaK4EsNAkLAQEBAQEBAQEBBgEBGAsKAgQBAQKESgKCIQEkNwYOAhA?= =?us-ascii?q?BAQYBAQEBAQYEAgKGRQyCcmE9RgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQENAkMDUgMPAR8BAQEDAQEhDwEFNgsQCQIOBAYCAiYCAicgAg4GDQEFAgE?= =?us-ascii?q?BgyIBgnsFC5Rsm3qBMoVSg1WBQIEOKoZTgj6Dfw8PgU0/gRABJwwDgiwuPoJ?= =?us-ascii?q?cAQGBKgESAYM4gmAEjQeCQCMRgwSHB5shXioHgVuBCoEKBAuGBoFFjleCWgU?= =?us-ascii?q?KHoMAgSONPQYojhWSO4hwllACBAIJAhWBaYEMcE0kT4JpCUcXAg2SEIUUhUR?= =?us-ascii?q?yNwIGAQkBAQMJfI8IAYEQAQE?=
X-IPAS-Result: =?us-ascii?q?A2HABgB21ztf/xoBYJlfgQmBSoMagTMKhC2QfiWaK4EsN?= =?us-ascii?q?AkLAQEBAQEBAQEBBgEBGAsKAgQBAQKESgKCIQEkNwYOAhABAQYBAQEBAQYEA?= =?us-ascii?q?gKGRQyCcmE9RgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQENAkMDUgMPA?= =?us-ascii?q?R8BAQEDAQEhDwEFNgsQCQIOBAYCAiYCAicgAg4GDQEFAgEBgyIBgnsFC5Rsm?= =?us-ascii?q?3qBMoVSg1WBQIEOKoZTgj6Dfw8PgU0/gRABJwwDgiwuPoJcAQGBKgESAYM4g?= =?us-ascii?q?mAEjQeCQCMRgwSHB5shXioHgVuBCoEKBAuGBoFFjleCWgUKHoMAgSONPQYoj?= =?us-ascii?q?hWSO4hwllACBAIJAhWBaYEMcE0kT4JpCUcXAg2SEIUUhURyNwIGAQkBAQMJf?= =?us-ascii?q?I8IAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="19724848"
Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 15:30:01 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBCABL1ztf/1lIDI1fgQmBSoIqcAN?= =?us-ascii?q?UMCwKhC2QfSWaK4FpCwEDAQEBAQEGAQEYCwoCBAEBhEwCgh8CJDcGDgIQAQE?= =?us-ascii?q?FAQEBAgEGBG2FXAyFcgEBBAEBIQ8BBTYLEAkCDgQGAgImAgInIAIOBg0BBQI?= =?us-ascii?q?BAYMiAYMAC5Rsm3qBMoVSg1WBQIEOKoZTgj6Dfw8PgU0/gRABJwwDgiwuPoJ?= =?us-ascii?q?cAQGBKgESAYM4gmAEjQeCQCMRgwSHB5shXioHgVuBCoEKBAuGBoFFjleCWgU?= =?us-ascii?q?KHoMAgSONPQYojhWSO4hwllACBAIJAhWBaSRncE0kT4JpCUcXAg2SEIUUhUR?= =?us-ascii?q?BMTcCBgEJAQEDCXyPCAGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="88724648"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 15:29:58 +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 07IDTwnc004909 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 18 Aug 2020 15:29:58 +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; Tue, 18 Aug 2020 15:29:53 +0200
To: Laurence Lundblade <lgl@island-resort.com>, "Smith, Ned" <ned.smith@intel.com>
CC: "rats@ietf.org" <rats@ietf.org>, Carsten Bormann <cabo@tzi.org>
References: <0B64B104-1BA0-4341-8470-A17D2C6AC181@island-resort.com> <B61BA81C-6E39-4B3D-83FB-336694E99DC5@tzi.org> <76845355-645C-4BD2-9599-50E33A419C51@island-resort.com> <C5B1590C-CE1B-4797-BA82-84281BCB8006@intel.com> <BD954BC5-37D7-4E21-8774-16C9A7B4DD95@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <7a320d3e-801b-ef1f-2483-e81d130e042d@sit.fraunhofer.de>
Date: Tue, 18 Aug 2020 15:29:52 +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: <BD954BC5-37D7-4E21-8774-16C9A7B4DD95@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/H9HsEetK03lhm3aqZepIhmJQrQs>
Subject: Re: [Rats] Attestation of implementation vs authenticity of service
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, 18 Aug 2020 13:30:24 -0000

Hi Laurence,

I am fine with "no Claims exclusive for services" in the base EAT I-D. 
One can always start a complementary I-D that focuses on services later 
(e.g. facilitated by re-chartering).

Viele Grüße,

Henk

On 06.08.20 21:09, Laurence Lundblade wrote:
> Yes, the RATS architecture seems highly applicable to claims-about-services (for lack of a better term). It would be dumb to have an IETF architecture for claims-about-services that didn’t re use the RATS architecture at least partially.
> 
> By my read of the charter, claims-about-services are not explicitly excluded, but also not quite in the spirit of it. Maybe the work done is done in RATS with a re charter?
> 
> The bottom line for me, is that I really don’t want to put any claims about services in EAT. There is enough work to do already :-)
> 
> LL
> 
> 
> 
>> On Aug 6, 2020, at 11:38 AM, Smith, Ned <ned.smith@intel.com> wrote:
>>
>> The RATS charter refers to "system component" as the initial focus for definition; which includes claims definition. The architecture makes it clear that claims can originate elsewhere as well. It seems reasonable that claims about services could be defined elsewhere, but still be conveyed / appraised using RATS WG defined architecture and technology. Alternatively it could be defined in RATS, but possibly with some charter adjustments to allow "services" scope?
>>
>> -Ned
>>
>> On 8/5/20, 12:42 PM, "RATS on behalf of Laurence Lundblade" <rats-bounces@ietf.org on behalf of lgl@island-resort.com> wrote:
>>
>>
>>
>>> On Aug 5, 2020, at 4:47 AM, Carsten Bormann <cabo@tzi.org> wrote:
>>>
>>> On 2020-08-03, at 20:58, Laurence Lundblade <lgl@island-resort.com> wrote:
>>>>
>>>> Service Authenticity
>>>> 	• Focus is on the provider of the service, not the HW or SW
>>>> 	• The legal entity of interest is the service provider
>>>> 	• There is no equivalent of claims, but if there was they would be about the business or person operating the service
>>>> 	• Example: a web site
>>>> 	• Example: an email provider (IMAP service)
>>>>
>>>
>>> Hi Laurence,
>>>
>>> if you are talking about HTTPS, there is exactly one claim:  The service is speaking for a specific name (e.g., facebook.com).  All other claims are funneled through this one very special one.  Of course, the TLS handshake could be leveraged to do more than this one claim, but that is not what happens in HTTPS.
>>
>>     Yes, agreed.
>>
>>     Any notion of trustworthiness, regulatory compliance and such for a service is implied. We make heavy use of that implication and that is mostly OK. For example, knowing that facebook.com is Facebook Inc allows us to assume lots about the service from what we know of the company.
>>
>>     The equivalent for attestation would be just to name the manufacturer of the HW or SW. However, we are going far beyond that with all the Claims in the Evidence and Results.
>>
>>     Maybe we should have Claims about services? For example, what regulatory statutes they meet. Where are they incorporated. A reference to their terms of service and privacy policy.
>>
>>     That however seems like a new WG, not RATS.
>>
>>     LL
>>
>>
>>     _______________________________________________
>>     RATS mailing list
>>     RATS@ietf.org
>>     https://www.ietf.org/mailman/listinfo/rats
>>
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>