[Rats] Re: Follow-up of interim: Jun's and Thomas' comments about two keys

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Wed, 11 February 2026 14:48 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: rats@mail2.ietf.org
Delivered-To: rats@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B53CAB5730BC for <rats@mail2.ietf.org>; Wed, 11 Feb 2026 06:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.de
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2no0lch7gqj1 for <rats@mail2.ietf.org>; Wed, 11 Feb 2026 06:48:48 -0800 (PST)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 91B35B5730A6 for <rats@ietf.org>; Wed, 11 Feb 2026 06:48:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:References:CC:To: Subject:From:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q46Vi91ZFVRsiC3/giS4+tXRjC/+TxndvE9ufpvPj+A=; b=XZRL/VyGymDjYEvz5lMmIb01qJ pGtcFlpb2jUtuftLnkqwFbmjcoP+holMO5M+6H2g1XG4CrXtoKpPMzBmfr8+QSgoRfFThMC/rs3OU Lxp0NDNhnXRCFVZfH2nEVcrfmuCUbv1FbZePrQqvbjkwLRAyuZ4T45ewqvOJ+BEwM0TLVQLtbnvRG OOlb5FxhTBqxtHCX9w6yPBEXVM8PVItRzoyGPf7mhu2vlCVt/Es1UgtcTBmfYxKDEsrci7EQNe8oI +jYaDHsN8YXRcaDskwNDfCt/YXCIV4x5KdgDXEISObKhB1XoICPBYm7q/Vg6Er6hCrmBJBLk4dY7c Y8ljfmEA==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout3.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1vqBWJ-00DeBU-Im; Wed, 11 Feb 2026 15:48:47 +0100
Received: from [192.168.178.60] (141.76.13.149) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Wed, 11 Feb 2026 15:48:39 +0100
Message-ID: <18ac065f-c175-47a3-8659-98bc60399885@tu-dresden.de>
Date: Wed, 11 Feb 2026 15:48:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
To: Thomas Fossati <thomas.fossati@linaro.org>
References: <76121f16-8dce-45bb-86b4-a850660e4a61@tu-dresden.de> <CA+1=6ydTUCam4iDy5wfRe7smjkBnhtm4=sO+2rWtWRjrdxN0pQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CA+1=6ydTUCam4iDy5wfRe7smjkBnhtm4=sO+2rWtWRjrdxN0pQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms030601000308020909080401"
X-ClientProxiedBy: MSX-L420.msx.ad.zih.tu-dresden.de (172.26.34.140) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: VFEYQJ6UHYCH63WUVE3PECD52IK6RYM4
X-Message-ID-Hash: VFEYQJ6UHYCH63WUVE3PECD52IK6RYM4
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "rats@ietf.org" <rats@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Rats] Re: Follow-up of interim: Jun's and Thomas' comments about two keys
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/o9nFc-3SqSRHrt38dkHJzjxpAPw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

Hi Thomas,

I believe the email is pretty clear. For details, I have referred to the 
paper. If you want to go to details, please be precise which exact 
statement in the paper is your concern related to? Presenting high-level 
concerns without pointing to the exact statement in the paper is not 
useful at all.

On 11.02.26 10:58, Thomas Fossati wrote:
> I still fail to understand the scope of this conversation.
Paper is clearly outlining the scope, and has been discussed several 
times in CCC Attestation SIG as well as RATS.What exactly confuses you?
> Once the CC platform is broken -- as is the fundamental assumption
> here (see the mention to TEE.fail & co.) -- and the verifier is
> informed of this, the platform measurements will contain evidence that
> the peer is unreliable. So I believe this is not a scenario you want
> to protect against, is it?
How can the verifier know who owns the exact instance of the 
platform?Verifier also needs Endorsements of which platforms belong to 
the data centers of the desired CSP. To the best of our knowledge, no 
cloud provider currently publishes such Endorsements.
> It seems to me that the scope is a zero-day and its ramifications in
> the context of TLS connections being relayed by an active attacker to
> a broken CC node, where the verifier is not yet aware of the broken
> TCB.  Is this correct?
No, that's not correct. The existing protocols and implementations 
provide no way to identify an instance belongs to a specific cloud 
provider or someone's basement. In short, a machine in someone's 
basement anywhere in the world is indistinguishable from a specific 
cloud provider's machine in a desired region.
> In general, I think you need to make it much clearer to your audience
> what the applicability of this attack is, because at the moment, one
> is left a bit wondering.

Audience is presented with a paper as well as the repo, which has links 
to the several talks where all of these issues have already been 
addressed to the satisfaction of everyone. If you have any leftover 
issue, please be precise and point to the exact statement in the paper.

Thanks,

-Usama