Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

Giridhar Mandyam <mandyam@qti.qualcomm.com> Fri, 03 June 2022 18:37 UTC

Return-Path: <mandyam@qti.qualcomm.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 B42A5C14CF09 for <rats@ietfa.amsl.com>; Fri, 3 Jun 2022 11:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 12qFHeTe5cfO for <rats@ietfa.amsl.com>; Fri, 3 Jun 2022 11:37:39 -0700 (PDT)
Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.142.165]) (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 B64B6C14F725 for <rats@ietf.org>; Fri, 3 Jun 2022 11:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1654281459; x=1654886259; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wV/cYdOY+Se5+fpdVobI+TMyulP0cHFza4e42QP2GyI=; b=Jfe9q/KGZLoYrFWMA4XRlFYlXwat1Wfx/eOcbShe19LJ0WLyTbzOGxP6 C/nIFsw2Yyye74dvC7QjuHn1c1Y3FgM0VsURyGNStI/xBJ0goKAaeMxh/ 1J5AntiWffNELvBku3X2tuxDyWf3KsXTQGgO3H8jYq8PBmQYC7TpfnFvA I=;
Received: from mail-dm6nam04lp2041.outbound.protection.outlook.com (HELO NAM04-DM6-obe.outbound.protection.outlook.com) ([104.47.73.41]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2022 18:37:38 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IrXTK5JvHgYNLoDLAATcGBJ1krK/OKIZXVjXRlcsgN6K1cIhVx6F7HWZn6V69VsZtAX1/5sKoByiWyR/qkYnte0DQjurkUCcfsYnN43Lvqj7wSzlv1f5Ma2wKVa4aG5sg7J7z29jx4HqEIk3BXmcjcFzEcRcV/9x888hFh/Q7v5mm+ftzoVMfb2E6aNZs7jvkI0y5J6NTY+fzMibKFBxTctgWxVgiSvu6kib8ssmQWxmmnhOVKUyqgwqmixMxkz3sxOuKvU25mRu3/R3tENxDSGrTSPGpPO6a7+Pk2iA8fCU83dw6TB1dDDPc9V+FXWaafRkpf4EdxBusSO8oNt/8w==
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=wV/cYdOY+Se5+fpdVobI+TMyulP0cHFza4e42QP2GyI=; b=kdaXv1lsumGEHsgFbz3EB5UP7grCUkfCS68rB51+8d8l4lnJiraO7XQISEzwEIHeJTQfD5lkcggOJGJ1IkuzbiQgLaZJjDSb1yhsUhUwqbpc/IRCudT2AJ66SQil0NE9xQp18clvU/cR/kH7sTdLHew/wQ2VkVU16mFaEfELprpkLqRrrfEXIlPG5oLyZhIYP8neQMtfCnXX0G7epueoJxrR8NwpL5DjDkH/gunEp5JsF0i096eOeUqrpbNqW0COsdFbYbvb1qeYKgzbZ+vK/wjsp6wCD5dLNYWYFc6AjIxGUpNN1lzfpUB8ZU0FZvVa2QSVold1b/5nabPylFaB1g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none
Received: from SJ0PR02MB8353.namprd02.prod.outlook.com (2603:10b6:a03:3e4::7) by SN6PR02MB5567.namprd02.prod.outlook.com (2603:10b6:805:e5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.13; Fri, 3 Jun 2022 18:37:35 +0000
Received: from SJ0PR02MB8353.namprd02.prod.outlook.com ([fe80::416:c75d:6a2a:9e19]) by SJ0PR02MB8353.namprd02.prod.outlook.com ([fe80::416:c75d:6a2a:9e19%4]) with mapi id 15.20.5314.016; Fri, 3 Jun 2022 18:37:35 +0000
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "Smith, Ned" <ned.smith@intel.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, Laurence Lundblade <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
CC: "Eric Voit (evoit)" <evoit@cisco.com>, "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)
Thread-Index: AQHYdfnhH+Yo1uYlM06yTBHRvLqR7K07CvaAgAADD9CAAUgKAIAABxcAgAAJSICAABHNAIAACd8AgAAI1mCAAXiYAIAAADBA
Date: Fri, 03 Jun 2022 18:37:35 +0000
Message-ID: <SJ0PR02MB8353CC2F1A9D2BC089F6BBBD81A19@SJ0PR02MB8353.namprd02.prod.outlook.com>
References: <45618431-7329-4F31-941F-A39BBC9D575F@cisco.com> <BYAPR11MB3125EB2DEC4CE5136AC903F9A1DF9@BYAPR11MB3125.namprd11.prod.outlook.com> <7FD4FE54-7A16-4E92-BDDC-878D726095E6@island-resort.com> <900bf8d8-0b00-cc98-fd82-786dc9c18901@sit.fraunhofer.de> <SJ0PR02MB8353B7216358275E4BF3923081DF9@SJ0PR02MB8353.namprd02.prod.outlook.com> <AB42EABD-FE7A-4DF0-8909-A6D304E292C5@intel.com> <BL0PR11MB3122AA0245129AAB021F0E5DA1DE9@BL0PR11MB3122.namprd11.prod.outlook.com> <c98b992b-5efb-d46f-81d5-d3711941dbb9@sit.fraunhofer.de> <B2C05847-4A5C-4179-AE00-A5F9BACC5121@island-resort.com> <PH0PR02MB725621CB633C322367FD4935F2DE9@PH0PR02MB7256.namprd02.prod.outlook.com> <SJ0PR02MB83536AE654BEDBAE653F803381DE9@SJ0PR02MB8353.namprd02.prod.outlook.com> <C0C0C756-214C-43C8-8EE2-AD4CFF71C0A0@intel.com>
In-Reply-To: <C0C0C756-214C-43C8-8EE2-AD4CFF71C0A0@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=qti.qualcomm.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f7e921ec-45f0-4ddd-e257-08da459020fd
x-ms-traffictypediagnostic: SN6PR02MB5567:EE_
x-microsoft-antispam-prvs: <SN6PR02MB556730B55C8D11ED838DCEB081A19@SN6PR02MB5567.namprd02.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0dTh/3ykJzs3cxOnV37ecgrmR5P9CqT7it8HadZ2obuiUkSkjpar9kTS+FkR8bgKbiJjgj7fOjZODQ7og9kCkv1VcmHTGI5MHy4nxFBlJhLwkVFSdM2bR3ErsZyKbkY3tsSmvKE6UiBaxi9DjLqZyvrfk7hFIRqpHtgC1p+H+DwXrBno+zAw7ZG4GO1JMgyPmttlKXNvTN/UD8c/Y95E69meKsZMojIfrg/M6g2v9blmuRoSCLNIwwZXmcWUXFNzTNCB4Q3FncwhSFGbxpuzKNqA8KfBfDuHxQZjovJ9LmxA08uilRW3KQbOz/Ui01xutO2lPbnB0gvScoB/LkhtIepGtpeuVDftvHFJlJDA8YjA+LD8D64BRVob4bHkonXFdzq3j+FuX9bP/8j/C4uEqkJPapbSrGCk3GZff8ySuell+PA9mkfMnKkaWSmTZzD2S2/fWwo3Trx0e8G4Funr4dRLj/zR5j1v/BiF+6SwUtwRQwHzkWhk/VcAIOqjycFNVxkj79KQ2NbT2R9yvKQN9XImIyXLiC8Toxy4V3vMCVoeYo9Ssp/hAGPZbss82iaAW7hBoj6C/69PcddOb+bH1i/voHpz26ooc9sdnoIFXoX7W1/gV7EThs0HoGSMuARO39iH6CrgwqWhShVZDn2pu0s7N9xPPtJlyHARNUoc9NRwEAaxVJzQ7bNEh/eNjc1UMgTHJsbPVi+O10zoTwAC/Dj/KHKLc5J+RWA8CpTWxCHwLdeOVANgICFZVkX6JZfqyxV37Bf1VSTqzqUnAzKZHl6BhgEmvwJPjMN3hXrUd7vMZ4yk7lwv0iGwL8x+GhgblgRIZGJlrfhfDxLHeI5o/g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR02MB8353.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(64756008)(66446008)(38070700005)(83380400001)(9686003)(66476007)(166002)(66556008)(54906003)(76116006)(4326008)(8676002)(316002)(55016003)(71200400001)(186003)(66946007)(966005)(6506007)(508600001)(53546011)(52536014)(7696005)(38100700002)(110136005)(8936002)(5660300002)(15650500001)(122000001)(86362001)(2906002)(33656002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: sp3oqJ5kFF4RI56CRIERSxesuiOjt0bZUL0T/8AtsmoV+nvDGJboThHQ/xRuTX8DaBSzc/vyO/vlRGfzySlbmJbOJVBrP5Lb7N5EvSG7DjNYT8Gq54CGuQxgfJaEEiQiOE7Xt1qHYQTV4An59qErHKOPNSPuEhfrcTX6a4YhCrDQPEXy3CihgygLkBW3c+xezanUlZeiJCdAc3CBE1bN4NNWlNjFktOn5ARQCi0suB0Ku6E/oWognsjs9lGWweuNXPlLe5YnJH3h7qG/Oeihg86+L2HrfJ4t2CKHZeXoNCfUE3G4mNqIU7xC4tLA+GrUPdQ3Zl2sy0/jEUJAa1CEIHCT1Gm3iDv+soCusWYVeAPGgdtBaHg5tucNEQ/aUrymJUMSQOJt0zGQ26uHeiSrgrdAX4Nbq86bh3CW0QO2PsrwyU2Z8yzsWnjlcl42MohbsC7ggbg9tdwpDw7UO1oz0irDX+sxO0g/VwntIPeYubLjF3vxVCQvx3otfdhujRTaIbTJ24NdVZ5Ph7gkidrBgZEVESkXOL1snzVgaFmOkq4Iy2XWXjya4hjqWiQoAm1B9DTDSQJ8R45ECHmdCgr8DRzflV/o8ESPIxYM024MZsIFgHYA+IaH0pR+jq4d1+sIg49mV3UtPiUaRhDqBJwHPQqSYsZyS2YSScwBsn2eeQW/NXguHQzdE3Ce4AzvGj5UU09z3pyfO9fy349TU/z1iRQ+7eECmdourmhlhGUXo5oEyjHlKbFkw6MP+rkdemjrLCLU8vAcoz9trInjt9Zrs7rAJ8qoJrIMwq6bY+rpNWLph704FDLfmPlvHGCMlCGjBZEnutjRv3kGTx3mVcALY/EfXBq9lkSKZmSExuW1Q8nFidALvgzvBvDSTwhL57b+4/eELkTgXRDjF3TfOkCXqTHDTlz2TbAZ29O2nlZrJ824WATw2Ymmk/v3RfD4aEcSkX87yOr2Lmvc2eXif2JQOMOK/fjAglASKm7PAzlsCYNoihQy+tMk/qj7EN3EmhP4GNLuXUFIpkUvljJc80DapvYoZyWf9IRnA34uIsQFmohgqbq4SkqOp9AkazH70VauYawTHSkUFdNrzZTD9ufe7arA0pt9xagu3hRvY2XgkNZA+MoH5KK2Hsmy+UhX9nM7up6eIQpA5XsQPcEu71j9U947AXnk0YpMf10WHBugB/9QAqmoLxGVD6gv5Rxz2cAfEWu+pm6dyCaEygV905JzlJP1ahtW4pS4H34zG4a23shlEob1989ERnytVpWhJjcEJ/5mfrTDhJiJqroFGgHa7rb56Npss/qtE5TU+xxVQ7Y6upBqxavzqme0xzOJfCR6wKHgaDzowCxND9oGdntXZ6YG/6D8NWjO0WUdvf9iHUU+3evBRUOUvf1J+yXyP/hoZlPn2b5y7i4VDj/UjeCgvXtynCu4uii8FX3Dqr9ruVT4vfAAvv6pT9M9w03JlLB7ASnANphsaULQeyR8Br6sfbAfJzqvbo9Taypn2pf/d24wQQ7fyX5Y47CB0EbDQDGTrYb18qPAGtNS0V6Nl2NdeSvzeqiFEhjV+KyheEXWp+j9watUMPr1FopLEev23wi3U3n4XNeP5E+kcbEKJj1yrag0KQAz6RFawELsTvplcUgKMuam1MtAnugRVaIZvLO4dNlRP5+If+C8KfYO4jBipic4UQqwggR6A5xVFFdcBASGULk4PF5YC8MbbykagMcdbmaTYZyw10M7Bki0jRnlOY1tC8SvvPDU4RxMR3gO/Ig=
Content-Type: multipart/alternative; boundary="_000_SJ0PR02MB8353CC2F1A9D2BC089F6BBBD81A19SJ0PR02MB8353namp_"
MIME-Version: 1.0
X-OriginatorOrg: qti.qualcomm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR02MB8353.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f7e921ec-45f0-4ddd-e257-08da459020fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2022 18:37:35.7306 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TibjPEM/8kCu96tlwTz8PA2aNxHQzC2+k8ZPkmnDxzxc97KR6euqGHP/mK3esaktdhgz7CfF8anUv+n8dNKhUIqUUIVzISi6JyhG0r4fcZE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5567
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/i8eoOOGKBEQG9Mbs5MEEqnr0uGA>
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)
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: Fri, 03 Jun 2022 18:37:43 -0000

My impression with the concerns being raised on security level is that there is not a clear delineation between whether it is attestation evidence and attestation results.  I was hoping to get guidance from the RIV doc, which the group has approved for advancement beyond LC, for guidance.  In this doc, all PCR entries are represented as attestation evidence.  As I have shown below, several of the PCR values as defined could be interpreted to be self-assessments or results.  I do think this is relevant -  other drafts that have successfully advanced beyond WGLC can be used for guidance in the context of EAT.

I have also highlighted that the group seems to have been comfortable with guidance such as “Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies)” in WG drafts that have been forwarded that have made it past LC.  Why can’t such guidelines apply to sec level?  If a verifier based on its local policy has determined sec level is not consequential they are free to ignore it.

-Giri

From: Smith, Ned <ned.smith@intel.com>
Sent: Friday, June 3, 2022 11:29 AM
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>; Laurence Lundblade <lgl@island-resort.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: Eric Voit (evoit) <evoit@cisco.com>; Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>; rats@ietf.org
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
I’m not sure how observations about a different draft / legacy technology addresses the issues raised related to the EAT draft security-level claim.
There might be issues with another draft, but those issues should be raised in the context of the draft to which they pertain.
-Ned

From: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>
Date: Thursday, June 2, 2022 at 1:45 PM
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>>, Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>, Henk Berkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>
Cc: "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>>, "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>, "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org<mailto:evoit=40cisco.com@dmarc.ietf.org>>, Nancy Cam-Winget <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>, "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>
Subject: RE: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

I also make an observation that some of the persons who are claiming confusion about whether security level is attestation evidence, attestation results or some form of self-declaration seem to be quite comfortable with comparable (maybe greater) ambiguity with TPM’s.

For instance in https://www.ietf.org/archive/id/draft-ietf-rats-tpm-based-network-device-attest-14.html#name-notes-on-pcr-allocations:


  1.  “PCR[0] typically represents a consistent view of rarely-changed Host Platform boot components, allowing Attestation policies to be defined using the less changeable components of the transitive trust chain. “

How is a “rarely-changed” boot component identified?  Is this the “result” of a rules engine within the attester?



  1.  “PCR[4] is intended to represent the software that manages the transition between the platform's Pre-Operating System start and the state of a system with the Operating System present. ”



What if there are multiple OS’s in the system?  Which entity determines what constitutes the specific operating system that corresponds to this PCR?  Isn’t this an attestation result as opposed to just evidence, as this value cannot be in the quote without a preliminary determination (result) identifying which SW is responsible for the transition to the target OS?



  1.  The text goes on to state “Although the TCG PC Client document specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, *it should be noted that embedded software vendors may have considerably more flexibility*. Verifiers typically need to know which log entries are consequential and which are not (*possibly controlled by local policies*)”



So why is it OK for a RIV-compliant implementation (embedded software vendor) to assign arbitrary values to a PCR (which could conceivably span both evidence and results) with the expectation that a relying party/verifier to be able to apply the appropriate policy to interpret it, but it is unacceptable to expect a verifier to interpret sec level in the context of its own appraisal policy?

-Giri

From: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>>
Sent: Thursday, June 2, 2022 12:29 PM
To: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>
Cc: Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>>; Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>; Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>; Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org<mailto:evoit=40cisco.com@dmarc.ietf.org>>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com<mailto:ncamwing@cisco.com>>; rats@ietf.org<mailto:rats@ietf.org>
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

I’m pretty happy with the latest text. It’s a considerable improvement on what we had previously.

On 02/06/2022, 11:54, "RATS" <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> wrote:


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

On Jun 2, 2022, at 10:50 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>> wrote:

Hi Ned,

this also reflects my perception of group consensus.

Maybe be little careful about concluding what consensus is here?

There are an equal number of people expressing support of security level as there are questioning it.

Isn’t consensus based on number of people, not on how long the list of questions is or how strong the view is?

LL