[Rats] Collection binding (was Re: New RATS)

Laurence Lundblade <lgl@island-resort.com> Fri, 03 June 2022 18:15 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 22728C14F74E for <rats@ietfa.amsl.com>; Fri, 3 Jun 2022 11:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level:
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 r1mRZHxEmiU7 for <rats@ietfa.amsl.com>; Fri, 3 Jun 2022 11:15:40 -0700 (PDT)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (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 3D599C14F6E7 for <rats@ietf.org>; Fri, 3 Jun 2022 11:15:39 -0700 (PDT)
Received: from [192.168.1.4] ([75.80.148.139]) by :SMTPAUTH: with ESMTPA id xBpin55y1PzzbxBpjn9g3V; Fri, 03 Jun 2022 11:15:39 -0700
X-CMAE-Analysis: v=2.4 cv=OPniYQWB c=1 sm=1 tr=0 ts=629a4fcb a=qS/Wyu6Nw1Yro6yF1S+Djg==:117 a=qS/Wyu6Nw1Yro6yF1S+Djg==:17 a=7CQSdrXTAAAA:8 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=gfrzBx4ME0TrB5gni64A:9 a=QEXdDO2ut3YA:10 a=bfb09CbrtlqHzZ0B:21 a=_W_S_7VecoQA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <0606C657-7BA5-4439-A65E-4FBE6E01DEA6@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B2C17BC6-2201-4A94-8847-8B626FFAB11E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Fri, 03 Jun 2022 11:15:38 -0700
In-Reply-To: <AS8PR08MB6392C7D0CC195B30CBC789CBEFDD9@AS8PR08MB6392.eurprd08.prod.outlook.com>
Cc: "rats@ietf.org" <rats@ietf.org>, Thomas Fossati <Thomas.Fossati@arm.com>
To: Simon Frost <Simon.Frost@arm.com>
References: <AS8PR08MB6392C7D0CC195B30CBC789CBEFDD9@AS8PR08MB6392.eurprd08.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-CMAE-Envelope: MS4xfJxBPK7erYA7TIgn2jg6FW0z/FwpippHEPQrP9b2w/Ye1iWlS2tyCtqb8ukYZXTvDrTjKq/FVo8KJ2sl0cTcaa13oQIdeWymsGhiOB6ArzX12bRIc1Bn DsBvYO9aXSSCzK/QLLVGPa/ceUw8TFGCRGbGAKLMUCW6ZCHQS7e0i654IjJa+XUbZfb4OLv40wP+uoo5cTZneWEZBnW4xSGdXEGLpM6Qv1ZU7NXm0SRWlZGp yemDbP+fEByMaoZ3K+sekw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/dww-pUoS5I1ggn__rZRqB6tMnZI>
Subject: [Rats] Collection binding (was Re: New RATS)
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:15:41 -0000

This is one of two comments I have on collections.

Without any cryptographic binding between tokens in the collection, an attacker can easily substitute a good attestation from another device for one that is not good. This is very large vulnerability in my view. So what to do?

1) One option is to write some very large security considerations. They would probably recommend strongly the use of TLS to provide the binding. They would look a lot like all the text in UCCS.

2) Another option is to abandon the draft for submods that does provide that. The top-level signer could be a weaker attester whose job is just to provide the binding. It would be kind of similar in security characteristics as using TLS (where TLS is not implemented in a root of trust).

3) There could be some other cryptographic binding. Perhaps a hash of one is COSE aad for another. There is allusion to cryptographic binding in the draft, but nothing specific. That other binding could be left up to the implementer and not standardized in which a big recommendation in security considerations is needed. It could also be standardized by describing what it is in this draft.  Can you describe what you were thinking about?

I don’t have a strong opinion of which option should be used, but I think one (or more) is needed.

LL



> On May 30, 2022, at 4:33 AM, Simon Frost <Simon.Frost@arm.com> wrote:
> 
> FYI. I’ve just submitted a new draft for a proposed extension to the top level object in EAT.
>  
> There’s a full justification in the doc, but as a quick summary, there are difficulties in creating a top level ‘envelope’ object for a multi-token system while remaining compatible with EAT. Given the recent move to fix the list of top level objects but embrace extensions, this approach seems to be an appropriate proposal.
>  
> See: https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/ <https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/> & https://github.com/SimonFrost-Arm/draft-frost-rats-eat-collection <https://github.com/SimonFrost-Arm/draft-frost-rats-eat-collection>
>  
> Thanks
> Simon
>  
> Simon Frost
> Senior Principal Systems Solution Architect, ATG, Arm
> Mob: +44 7855 265691
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
> RATS mailing list
> RATS@ietf.org <mailto:RATS@ietf.org>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>