Re: [Rats] comments on draft-birkholz-rats-uccs

Henk Birkholz <> Mon, 17 August 2020 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7407E3A0ABB; Mon, 17 Aug 2020 03:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.848
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b-s0MDuaXz6F; Mon, 17 Aug 2020 03:49:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE6713A0AA8; Mon, 17 Aug 2020 03:48:58 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EeAwBkpYde/xoHYZldCRsBAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgXuCKWwDVS8qCoQRkF0tmz0KCgEBAQEBAQEBAQYBARg?= =?us-ascii?q?LCgIEAQGERAKCRyQ4EwIQAQEGAQEBAQEFBAICaYVWDIZGAQEBAwEBIQ8BBTY?= =?us-ascii?q?LBQsJAhgCAiYCAicgEAYBDAEFAgEBgyIBgnsFC5M/m3mBMoVLg2eBOAaBDiq?= =?us-ascii?q?MMQ+BTD+BEScPglo+gmcBAYE5FIMqgl4EjWGDHpA1j14HgUl3fASLf4ogI4J?= =?us-ascii?q?MiDiEMQWMRo8ynB0CBAIJAhWBaSOBV00kT4JpUBgNjikXiGSFQ3KBKY0ZAYE?= =?us-ascii?q?PAQE?=
X-URL-LookUp-ScanningError: 1
X-IronPort-AV: E=Sophos;i="5.72,341,1580770800"; d="scan'208";a="33649345"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:48:56 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.76,322,1592863200"; d="scan'208";a="119747710"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:48:54 +0200
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id 07HAmrDr007176 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 17 Aug 2020 12:48:53 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 17 Aug 2020 12:48:48 +0200
To: Jessica Fitzgerald-McKay <>, <>
CC: Jessica Fitzgerald-McKay <>, Jim Schaad <>, "" <>
References: <>
From: Henk Birkholz <>
Message-ID: <>
Date: Mon, 17 Aug 2020 12:48:47 +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: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Rats] comments on draft-birkholz-rats-uccs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2020 10:49:04 -0000

Thanks Jess!

the discussion on where this is incubated was deliberately scoped down 
to provide:

* a finite and still useful set of Security/Privacy considerations, and
* relatively specific guidance and context on how prerequisites for 
usage look like.

The concept of an UCCS tag goes beyond RATS, of course. The usage of an 
UCCS tag alas requires some application-specific "rules".

That said, we will discuss this topic specifically asap. Also, Jim is 
now in CC (Hi Jim) and maybe he can weigh in on this topic?

With respect to your technical comments, please give us some time to 
come back with well-formed answers. I do not want to barge ahead with 
half-baked replies :-)

Viele Grüße,


On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote:
> Hi, UCCS authors,
> Mike Jenkins and I reviewed the UCCS draft. Our comments are below. 
> Happy to talk through any of them with the group.
> Thanks,
> Jess
> The intent of this draft is similar to the key concept of EST - use the 
> authentication of the secure session connection. Most schemes build on 
> this concept leave a lot of banana peels laying around, some of which we 
> describe here. In general, this does not seem appropriate to the scope 
> of RATS. We feel that COSE might be a more appropriate work group to 
> think these issues through.
> - If you're using a static symmetric key for authentication (as one 
> might with highly-constrained devices), you can only authenticate a net, 
> not an entity. The receiver cannot differentiate between authenticating 
> the sender and authenticating itself.
> - The authentication happens at the secure channel termination, not in 
> the channel-contents-using application. It's important how the 
> termination process vouches the authentication to the application. (In 
> EST, this question is how the EST server vouches the requestor's 
> identity to the CA server.)
> - A TEE only helps if the TEE application can punch through the REE and 
> set up the secure channel completely on its own. If the TEE relies on 
> the REE to set up the secure channel, you might as well just operate in 
> the REE.
> - There is a comment at the end of the introduction (!) about 
> transitioning back and forth between self-protected and 
> channel-protected CWT, "in a well-defined scope". Define the security 
> characteristics of that scope or get rid of the comment. You're handing 
> someone an awful lot of rope there.
> - The claims set should be treated as ephemeral by the recipient. It 
> shouldn't be stored, and can't be forwarded except as data originated by 
> the recipient. As soon as it emerges from the secure channel, it's no 
> more valid or meaningful than any other piece of unprotected data in the 
> application environment.
> _______________________________________________
> RATS mailing list