Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

"Smith, Ned" <ned.smith@intel.com> Mon, 09 October 2023 19:55 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 E58F0C14CE42 for <rats@ietfa.amsl.com>; Mon, 9 Oct 2023 12:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=intel.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp8WzUGkcccb for <rats@ietfa.amsl.com>; Mon, 9 Oct 2023 12:55:28 -0700 (PDT)
Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) (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 F2597C151061 for <rats@ietf.org>; Mon, 9 Oct 2023 12:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696881326; x=1728417326; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CfZSln+fVgcZ/rGLEapuwxA0K5wDizohCzPf2OjA18E=; b=D5lH6xyQbMfinrrQoq/1dt8TyJNtLqXntUHL/mun4vEVR32jI37Snv+l nO6r51Kqv1AWcr3yY/TWdem5g5GMf2ayUdZRdrbtEV2ZHst/lnetESTmf Ty7EhCSwwSk5KQ1bYldUEPTUakmbKXzCGCq+lIqmUEvQQUAadN24HKKkT N0hY4BgUoLj8SOWspHDpdtU1gstBAuxSWeMb415UKtn5RmyZlQC+cMH8E 8GsRmuAPZXLuSuM+hxmI4kx+bF1s9xBWbGKyMeZp+BU3KSgB5vwxgoTdt 22Knzucn9W8vxaN9IBAR5LYA/pQE1rO1MjCc+0fNarIBJQYGlX20PLghc g==;
X-IronPort-AV: E=McAfee;i="6600,9927,10858"; a="383109588"
X-IronPort-AV: E=Sophos;i="6.03,210,1694761200"; d="scan'208,217";a="383109588"
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2023 12:55:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=McAfee;i="6600,9927,10858"; a="823460354"
X-IronPort-AV: E=Sophos;i="6.03,210,1694761200"; d="scan'208,217";a="823460354"
Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga004.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 09 Oct 2023 12:55:26 -0700
Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Mon, 9 Oct 2023 12:55:26 -0700
Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Mon, 9 Oct 2023 12:55:26 -0700
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.32; Mon, 9 Oct 2023 12:55:25 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PoizJSmR/6hFYBMyotSJIwrHKoQwe6Olg/hluWGXnvTJHSKBUc9BmZw4dweryn9kkdlAxGs9rAGPXT+BW7VzcjnSJh0Ltf5AxI6sogOzwzL1zzuGZc2dj7Y2WjYvs70sF8Yr52lnl9PeESy7obiG8wDYjAkuFu4x36dGq1FD6cW/vQkOQRQq5UnYp1CsA+jcN5iqsaBCJiGxSvQ4wSUX+6+fPH1YkW2kiugWTbyucVujkvKoGbZQAbP0g4N5Eb7nFm5GvonDoRbgOcxS7bfSWlf8Aiep33APPLLDS1gBxpplHNaU+R+hDmcMh00J0bpuwfjLBYkziUuvJrwqTbyMdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CfZSln+fVgcZ/rGLEapuwxA0K5wDizohCzPf2OjA18E=; b=flj7ToM9tnWUi7TaUEVLaOUVQ3aDXUZCZK8oHpoouX0GKIsBdAWYhV0wdlOLe+hY9Kgw0tszQdQLFFfzk6QlwN8C0OOv5tGEefeQiRUGna6gdl3WdMZdpCsZJz+HSmEjk5S7PdoJQZeJxLqm1W22URrorGnRSODHWYqjTiF7/z8SDWaiZzk+CA0+OKPb0wRD5jRXFQbz3BTVVE6bqLr6lUGIMTaTgLBbBJnDstgGTYk8f3MWzrX0E3FDxb5Gue7fq1LJmm9GTIQo9BWgzbzeusIZyUy4bvTg5+sto9ugUoKayOtYR2eTVEHHy0F9adO/qEqwzpPIFlhvUd1paGEuXA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by SN7PR11MB7419.namprd11.prod.outlook.com (2603:10b6:806:34d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.36; Mon, 9 Oct 2023 19:55:23 +0000
Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::20ce:90f8:e37a:746b]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::20ce:90f8:e37a:746b%4]) with mapi id 15.20.6863.032; Mon, 9 Oct 2023 19:55:22 +0000
From: "Smith, Ned" <ned.smith@intel.com>
To: Tom Jones <thomasclinganjones@gmail.com>
CC: Tom Jones <rp_tomj@hotmail.com>, "lgl island-resort.com" <lgl@island-resort.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "iab@iab.org" <iab@iab.org>, rats <rats@ietf.org>
Thread-Topic: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet
Thread-Index: AQHZ9XFHoYXW2Rzq/U2DeqRmHEHRSbA3VEUAgAgbM4CAANOngIAAwRWAgABULoCAAHZbgP//jZ2AgACHPgD//5E/AA==
Date: Mon, 09 Oct 2023 19:55:22 +0000
Message-ID: <7A06930B-77BB-4CD0-A121-655AF09B99D3@intel.com>
References: <169627945480.62917.5309122275327869344@ietfa.amsl.com> <16966.1696299372@localhost> <CAK2Cwb7X+Xri81tKX6Uvci_Ur_h18SKaAi0CQmJZHkVnpA-51A@mail.gmail.com> <87C6E17A-A4E6-49F6-AF51-BC6FD3A06404@island-resort.com> <CAK2Cwb6jy9W=-qJGt8xDEabi_U6qDTSMvv7FFNpqTN1z=qh-6Q@mail.gmail.com> <7897AE41-5DC7-4B9A-A5D6-952E7CBF9B9F@intel.com> <SA1PR20MB5407C5FA816E3DD9C41681578ECEA@SA1PR20MB5407.namprd20.prod.outlook.com> <CE654377-E5D7-41A5-9C98-B948A20F263E@intel.com> <CAK2Cwb7fvH8eqXaP64tkL6BDcCEKa6eBLj-YCdF5CeOXsJOByQ@mail.gmail.com>
In-Reply-To: <CAK2Cwb7fvH8eqXaP64tkL6BDcCEKa6eBLj-YCdF5CeOXsJOByQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.77.23091703
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR11MB5169:EE_|SN7PR11MB7419:EE_
x-ms-office365-filtering-correlation-id: 72e6a079-6963-44a4-5e83-08dbc901ac3c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UrfbLsJb+HPb5alrvMsqJAV4vJDAkgYlrTEfECKjz8vb4Xm6UMEjRjgWNbb7Vf7jRxBaJID+JX3CvzvrjMQd4l4GeCS6zBM/DuKLNyeN/TDXwXRnkFB0//eTfcV0Rwn02IaQ6Iu85HfnwZr8S1UfLtR+3d/LFL0tqYKzMizxvtJMRPEPzN54TJlWtdHRkZ7UoC4AVDkIyNyBikk7s3G98noKrsPDKONRuXy9Nj2iLpxF9QElqjPJ8dJKHtZIvj+ywof+vz/XjOwGGZBrNF5li0uA/CTDsmBd8L+C+znZcHlPMFOLK3psIz4C8Rk51fceZxJHZ8iDm/qPTb7Za1kMREtqYCfUuBQpocu2/QeTncHAuk+vXIIBU8hW7/wcjgmLehvkOFScajBXksdQQY1XtCqJX4VdEEARJUwk9/wZEAvpV6gP/S0qUSf38Zv53xcK7SY9+AsBC5wdVDdb9rm+6+o5RNl8QimkoEkBxL5fGpi7rODpbZLIV8aWrC/SbU4CzH5kb40nR9AyBnqRcN0Ut8eCBQ2PbCa7uBN2iPJ8grSB1H9aHEmorPxYPx/AaYMQypN4rgYCh73edp1fnf0dTV08EHKUlNt+b8t5foo5im/5slJhtaMTYAIwIq4XBJDmjmNQuWiFqsrpgExNpFKrT8bM7bovwz6D/3l/v2mwlOc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5169.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(376002)(136003)(396003)(39860400002)(346002)(230922051799003)(64100799003)(1800799009)(451199024)(186009)(2616005)(26005)(64756008)(54906003)(66476007)(66446008)(6916009)(76116006)(66556008)(2906002)(66946007)(66574015)(83380400001)(86362001)(36756003)(33656002)(6506007)(53546011)(5660300002)(6512007)(6486002)(478600001)(966005)(8936002)(8676002)(4326008)(316002)(71200400001)(45080400002)(41300700001)(166002)(82960400001)(38100700002)(66899024)(38070700005)(122000001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 6W1xP1Die4SMQrJZ3/sGOw/kJsw3jZt5YutqgQnVZ74+SabwKHU98697vNkOQC0VAiu11WMptx1vXKdEbhXNdNyheoTvCUtmiYMPmBFVVmOxL7mgNqPaAVLNs07R19TFHzhdOHrAbxSG70jiqAjq8wEM9FCREn3YC03mYOJU+LESgemqsfRF3TOrFgD4NU4ouZMQG9iogryWqjGFBB+bT/5e/eRvfvcWoFpqEQ/7Y8tgAjhazRHynazjXxAfbAjqjfHSto7ju5xHrGlQ78oxJD6bcvRgwoGZRo5R+ILIvCtPwG3Y1veUJ9HD8/ZVO+X2f2WL2RguV6PyVlkhAVUGF1nWFOjQQb+bNMvr5YJE54iv4r4LeUbKcWuqxrt9s91qztBvZdZMsKFy7UuLDlWHHIO/erkVUk1u27OwC5qpfMgaMc27XCRwHK60gR6/R20q1XbmxxcAS6/q2yr+BNw9SPrR0RCdvM79hxC+TOHle7WVTV4D++ngDdYg29w+gL2xGYmQl5omLJ1fGpK2MCSph5mcrRKCTuy4pc5Fcgx12BEGehwMwIZzPzI77YaBk4vSrPt4vYKsBz8PMnf9b3nFL9dXueNsRkmApsiPG+29785HEa1vheTt3aJiB6D2dQSGA/blT4i0IJQZv4euGxQ1Fd3DImrcwiC2AjRTjMwc+MDkdTw2R+97YtoBgEsMCorL4BhHbuTj8pmU1hVwQVE63cNPwhfdu84MbGuCWVmaTi40YnDG64+k16a5bDbp5z32uIVKfkUzVCjgBEEkkSthVsnU87nLAhlnMwUce//o0MCHC9aonSCmBuRKMn3fGEq8Lod2AHlqxKudwVfsYvRawspGap2zI5KwhaHmrXtZLPJ3eBmUl+bK02Nj7eu3RoNmg2g+qwUKqmT30ktThxjntfMvaVfszW+pydWqVZevhiuQpARVm7KvEFrH7J8E3pc16Pj8fsmcz96oc95WKVssKXMG4sDuq0AMT3E1FKQt0vNqzZj97bwA/ug7l3Tjn1uGhkxjH5KAh4Cnrof0EEiQlIoRxMw3CV50fJSqlJXpbRULsov+RBtF4IweNpbn4/ohA8ciQ7wtWWARCR4rWB9D7Q11cnfwuBF/trjvsE3OCpX4LP37noBVaYB+nxXyQByfsCcJ9A0nCYeJMcqr7zkPZve11dqv9E0fxqNqcY+2gminOZEv7fUvt5rA39U4FJhuC56r6YWvYw72JlK3zx//1JuQz+V8LDz076LFPtzN2fa/V9z3VTr813ST7Zq7NNktvKW5JoYmfkrHgUrdDhJY9D7RM4uPcSwiFneqcc5Wy8Po+Ntj8HEzGaiO/OYf9RG42ddV+fq6IK4M4uzywifhpMxkH+D4XWVL2O4SZ9XCHxnbIaSlPe6Brpiazo5U6om5gj8aft9iXPOfgqNCSsyBEyyU9wtz7F0Nx4AzlWR6fx8LNYliIpwmel6730iVtCqm9r9dkWCHtdyz9zmhMskEc3/wZuN8AN2yyOLLIZRnX8yDeiKYhbp9sKKp/XcYwvYVuSX0QOsRIZpWaW9X15lqrW2u4faGDx7NXlVIuKcAy2ASlk1ONKpO1rBWtABi8kY2n5g7NEtoaVuqZ4hJuGYxpw==
Content-Type: multipart/alternative; boundary="_000_7A06930B77BB4CD0A121655AF09B99D3intelcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 72e6a079-6963-44a4-5e83-08dbc901ac3c
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2023 19:55:22.4505 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CsAEdSqBPEHDqFgEeAutAdtLf/JHbuluZKlzSXPLHe3qrnP0s1Ob147vQ5n2rWn50tahLpXCoP3Ajq3MUIy9YA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7419
X-OriginatorOrg: intel.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/fsvhQRE3ObrMTVloen7A2DYi-V4>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
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, 09 Oct 2023 19:55:32 -0000

> There is an architectural document. There appears to be no consideration for human privacy

RFC 9334 does call out privacy considerations relating to humans. It specifically suggests removal of PII from Evidence.
“Another approach to deal with Evidence is to remove PII from the
   Evidence while still being able to verify that the Attester is one of
   a large set.  This approach is often called "Direct Anonymous
   Attestation".  See Section 6.2 of [CCC-DeepDive] and [RATS-DAA] for
   more discussion.”

User privacy threats are often concerned with user tracking and targeting. PI and PII are attributes that allow such activity.
The various drafts that define specific attributes such as draft-ietf-rats-eat-21 - The Entity Attestation Token (EAT)<https://datatracker.ietf.org/doc/draft-ietf-rats-eat/> define attributes that are optional to include in Evidence. Many are attributes that represent a class of device that in most circumstances is ineffective as PII.

The use (or not) of an attribute due to its privacy sensitivity (or not) is a policy decision. The Attester can have privacy policy that dictates which attributes are privacy sensitive. The Attester, as part of reasonable protocol design, can select which Verifier to trust to enforce the Attester’s privacy policy (in addition to locally applied policy).

Attestation that focuses on machine attributes rather than user attributes helps protect personal privacy in that it shifts the focus from humans to machines (of which there can be a large class that are the same). This approach allows user identities and credentials to be omitted while still allowing assessments that can detect malware and compromise.

Cheers,
Ned

From: RATS <rats-bounces@ietf.org> on behalf of Tom Jones <thomasclinganjones@gmail.com>
Date: Monday, October 9, 2023 at 12:32 PM
To: "Smith, Ned" <ned.smith@intel.com>
Cc: Tom Jones <rp_tomj@hotmail.com>, "lgl island-resort.com" <lgl@island-resort.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "iab@iab.org" <iab@iab.org>, rats <rats@ietf.org>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

To be clear. There is an architectural document. There appears to be no consideration for human privacy. Can this gap be addressed within this community. Or is there a sep field in operation here. (See someone else's problem, hitch hiker's guide )
thx ..Tom (mobile)

On Mon, Oct 9, 2023, 11:27 AM Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>> wrote:
> so then, there is no hope for privacy preserving architecture from RATS?

Does “RATS” refer to the WG or RFC9334? And I didn’t say privacy preserving attestation was hopeless.

From: Tom Jones <rp_tomj@hotmail.com<mailto:rp_tomj@hotmail.com>>
Date: Monday, October 9, 2023 at 11:17 AM
To: "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>, Tom Jones <thomasclinganjones@gmail.com<mailto:thomasclinganjones@gmail.com>>, "lgl island-resort.com<http://island-resort.com>" <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>>, "iab@iab.org<mailto:iab@iab.org>" <iab@iab.org<mailto:iab@iab.org>>, rats <rats@ietf.org<mailto:rats@ietf.org>>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

so then, there is no hope for privacy preserving architecture from RATS?

Peace ..tom
________________________________
From: Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Sent: Monday, October 9, 2023 11:13 AM
To: Tom Jones <thomasclinganjones@gmail.com<mailto:thomasclinganjones@gmail.com>>; lgl island-resort.com<http://island-resort.com> <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>>; iab@iab.org<mailto:iab@iab.org> <iab@iab.org<mailto:iab@iab.org>>; rats <rats@ietf.org<mailto:rats@ietf.org>>; Tom Jones <rp_tomj@hotmail.com<mailto:rp_tomj@hotmail.com>>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet


> The problem then is that the verifier must state what the use case is in a trustworthy message.

If there is a gap in the RATS Architecture, it is that it didn’t acknowledge the need for a Verifier to present usage/context to the Attester as a prerequisite to disclosing Evidence. And it assumes the relying party doesn’t need to present usage/context to the Verifier before disclosing Attestation Results.



In its defense, the RATS Architecture wasn’t trying to define a protocol, rather a conceptual flow of information. Actual protocols would consider deployment and usage context and address privacy considerations as appropriate. Consider an embedded system behind a firewall, this may not need the deployment context to be communicated in a protocol message since the context is embedded.



-Ned



From: RATS <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> on behalf of Tom Jones <thomasclinganjones@gmail.com<mailto:thomasclinganjones@gmail.com>>
Date: Sunday, October 8, 2023 at 11:12 PM
To: "lgl island-resort.com<http://island-resort.com>" <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>>, "iab@iab.org<mailto:iab@iab.org>" <iab@iab.org<mailto:iab@iab.org>>, rats <rats@ietf.org<mailto:rats@ietf.org>>, Tom Jones <rp_tomj@hotmail.com<mailto:rp_tomj@hotmail.com>>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet



The problem then is that the verifier must state what the use case is in a trustworthy message.

thx ..Tom (mobile)



On Sun, Oct 8, 2023, 11:41 AM lgl island-resort.com<http://island-resort.com/> <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:

I think the workable strategy is privacy-preserving attestation. The attestation target (e.g. client device) reveals only enough to prove the security characteristics that it needs to for the use case. FIDO supports this sort of thing.



In some ways, formal, cryptographically secured attestation doesn’t change things. Web sites already try to collect as much personal information as possible. The OS and the web browser defend.



The IAB’s comment, is that web sites and services would deny service unless the client device provided attestation of their SW stack and such. That’s different than the privacy issue.



LL







On Oct 7, 2023, at 11:03 PM, Tom Jones <thomasclinganjones@gmail.com<mailto:thomasclinganjones@gmail.com>> wrote:



Granted that the iab doc is difficult, I would like to state an objection in terms of the user.



No verifier may ever request more attestation than they are willing to first provide.



What's sauce for the goose is sauce for the gander.



That would limit the sites that just troll users to see what they can discover to the sites that the user is willing to trust.



Generally I agree with panwei.

thx ..Tom (mobile)



On Mon, Oct 2, 2023, 7:16 PM Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>> wrote:

IAB Executive Administrative Manager <execd@iab.org<mailto:execd@iab.org>> wrote:
    > On 25 September 2023, the Internet Architecture Board (IAB) posted a
    > new IAB Statement on the Risks of Attestation of Software and Hardware
    > on the Open Internet[1].

    > [1]
    > https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/

It's an interesting statement, and I suspect that I agree with the intent.
As written, it fails to inform: you need to know what the treacherous uses of
remote attestation are (and then take two steps not detailed in this
statement) in order to understand the statement.
I think that this should be revised, and it shouldn't be so timid.

As an author of RFC9334, I'm rather surprised that this statement was issued
without any consultation with us.

As written, I find this statement useless.
I would be happy to work with the IAB to craft a better statement.

--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr%2BIETF@sandelman.ca>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats