Re: [Rats] I-D Action: draft-birkholz-rats-uccs-01.txt

Laurence Lundblade <lgl@island-resort.com> Thu, 04 June 2020 19:11 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 5C2383A0DD8 for <rats@ietfa.amsl.com>; Thu, 4 Jun 2020 12:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 P8SJP4impYRr for <rats@ietfa.amsl.com>; Thu, 4 Jun 2020 12:11:14 -0700 (PDT)
Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) (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 0613B3A0D6A for <rats@ietf.org>; Thu, 4 Jun 2020 12:11:13 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id gvGijHoC2UWQLgvGijNhHZ; Thu, 04 Jun 2020 12:11:12 -0700
X-CMAE-Analysis: v=2.3 cv=DYNpVclW c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=LD-zQ67PKl2J6gDn2lEA:9 a=oC4JMAnEfuleHk8B:21 a=7iTaDj3JUHWPNGUk:21 a=QEXdDO2ut3YA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <72AE6830-B424-47F1-BA3D-C694989300AF@island-resort.com>
Date: Thu, 04 Jun 2020 12:11:12 -0700
Cc: jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F64295D-E8B9-428F-9587-8D0D2C763582@island-resort.com>
References: <72AE6830-B424-47F1-BA3D-C694989300AF@island-resort.com>
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfD8LfCiGgD+3dhHmEKug7b2fqHxPFOm7yzJBtv7GdbuREHnaco5crGqBnpWzcbJ0d8qCigiW1melsE+zsN8H/xWo+9G9NQ7GLf9lBw+8En8XR80dGAYU lfM+YvYL5QueO9kr7BTg1x9V/24ZGv8BpmLSBoH90kT1pisZkdoD2eK3AUvl4f/80xdOPSDGkarxrcCpyCzee0b6NPxqbESuktY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/DA2V1fAgzbiajWljCQ9IOgul5aQ>
Subject: Re: [Rats] I-D Action: draft-birkholz-rats-uccs-01.txt
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, 04 Jun 2020 19:11:17 -0000

At least one private response seems to have misunderstood my intent. Let me try again.

I am saying that most security discussion should be moved out of UCCS and into use case specific documents and contexts:
- UCCS as RATS claims
- UCCS as RATS endorsements
- UCCS as RATS attestation results
- UCCS in GlobalPlatform
- UCCS in ACE
- UCCS in future unanticipated use case #1 that has nothing to do with RATS or ACE
- UCCS in future unanticipated use case #2 that has nothing to do with RATS or ACE

It seems better factoring to associate the security model with the use cases than with the data structure format. It seems hard to anticipate the security models needed for future use cases.

In the three RATS uses of UCCS (claims, endorsements, results), the characteristics of the security needed vary a lot and all three are not all covered here.

The text doesn’t seem to anticipate securing UCCS with CMS or a TPM-based signing scheme. It focuses on TLS / Secure Channels. 

The security of nested EATs seems better discussed in EAT.

CWT is part of the establishment of the Verifier’s trust in an Attester. That topic requires Endorsements and seems better in the context of RATS architecture or related. 


All that said, I don’t think the section 3 security discussion is harmful, just that it may become outmoded and necessarily bypassed as the use cases fill in.

LL


> On Jun 3, 2020, at 12:24 PM, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> Perfectly in favor of the UCCS tag.
> 
> The security discussion in this seems like the tail wagging the dog. UCCS is the tail. Conveyance Security is the dog. 
> 
> I think this draft should only say it is up to you to attach a dog to this tail.  CWT’s are a dog+tail so you don’t have to worry. UCCS is tail-only so you do. Your choice of dog is of course up to you. Choose wisely.  
> 
> Note also that UCCS is useful if you don’t like the type of dog that CWT comes with. It allows you use different types of dogs with a CWT-style tail.
> 
> :-)
> 
> Or said another way, I’m not so much in favor of section 3. Anything about RATS / EAT security should be in RATS / EAT docs, not here. Would like the draft to say simply “Be warned. UCCS does not have the security that CWT does. If you use UCCS, you should add security”.
> 
> LL
> 
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats