[Rats] draft-ietf-rats-architecture-12

Muhammad Usama Sardar <muhammad_usama.sardar@mailbox.tu-dresden.de> Wed, 07 July 2021 11:27 UTC

Return-Path: <muhammad_usama.sardar@mailbox.tu-dresden.de>
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 50AEF3A21BB for <rats@ietfa.amsl.com>; Wed, 7 Jul 2021 04:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level:
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 ZtnOP1yG5CqN for <rats@ietfa.amsl.com>; Wed, 7 Jul 2021 04:27:36 -0700 (PDT)
Received: from mailout4.zih.tu-dresden.de (mailout4.zih.tu-dresden.de [141.30.67.75]) (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 E9A0C3A21BA for <rats@ietf.org>; Wed, 7 Jul 2021 04:27:35 -0700 (PDT)
Received: from [172.26.34.101] (helo=msx.tu-dresden.de) by mailout4.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@mailbox.tu-dresden.de>) id 1m15iG-003ozG-Ip for rats@ietf.org; Wed, 07 Jul 2021 13:27:34 +0200
Received: from MSX-L103.msx.ad.zih.tu-dresden.de (172.26.34.103) by MSX-L101.msx.ad.zih.tu-dresden.de (172.26.34.101) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 7 Jul 2021 13:27:29 +0200
Received: from MSX-L103.msx.ad.zih.tu-dresden.de ([fe80::e5b7:72e7:b0f5:1489]) by MSX-L103.msx.ad.zih.tu-dresden.de ([fe80::e5b7:72e7:b0f5:1489%23]) with mapi id 15.00.1497.018; Wed, 7 Jul 2021 13:27:29 +0200
From: Muhammad Usama Sardar <muhammad_usama.sardar@mailbox.tu-dresden.de>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: draft-ietf-rats-architecture-12
Thread-Index: AQHXcur1+WXz319MnEKjMEv/OZmryg==
Date: Wed, 07 Jul 2021 11:27:28 +0000
Message-ID: <1625657248502.47603@mailbox.tu-dresden.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [141.76.44.149]
x-pmwin-version: 4.0.4, Antivirus-Engine: 3.82.1, Antivirus-Data: 5.85
Content-Type: multipart/alternative; boundary="_000_162565724850247603mailboxtudresdende_"
MIME-Version: 1.0
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qYUQ1C5-8blE4KzF7PnYW-pXrUQ>
Subject: [Rats] draft-ietf-rats-architecture-12
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: Wed, 07 Jul 2021 11:27:40 -0000

Dear authors,


Here I would like to share some thoughts on the draft:


Abstract: "a model that is neutral toward processor architectures" As the terminology, topological patterns and even the architecture itself is primarily taken from TCG (e.g., https://trustedcomputinggroup.org/resource/dice-attestation-architecture/), it is trivial that the architecture would hold for TPM. So in my view, interesting case is that of TEEs. In this regard, I would like to see a concrete instantiation of how this model, which is claimed to be neutral to architecture, could model the attestation process in Intel SGX/TDX, for instance. More concretely, how will the core entities (TD QE, VMM, TD, TDX Module, CPU Hardware) in the TD attestation be modeled in the RATS architecture? This will not only help make the concrete example of RATS architecture for a specific TEE, but also make the draft more accessible to people who have familiarity with SGX/TDX remote attestation.


Section 3 (Architectural Overview), Section 4 (Terminology) and Section 5 (Topological Patterns): I think it would be helpful for the readers if original source is clarified that the sections are based on TCG (e.g., https://trustedcomputinggroup.org/resource/dice-attestation-architecture/)


Section 4.1: Attester:

  *   Is it not possible to define Attester somehow without using "Attester" itself in its definition? Mathematically, this should be the case only in recursive definitions.
  *   "extent to which" Is it supposed to be quantitative rather than qualitative?

Cheers,
Usama


------------------------------------------------------------------------------------------------------------------------------------------
Best Regards,

Muhammad Usama Sardar (M.Sc.)

DAAD Scholarship holder

Chair of Systems Engineering

Institute of Systems Architecture

Faculty of Computer Science
Technische Universität Dresden

Germany

Office: APB 3073

Phone: +49 351 463-42048

Email: muhammad_usama.sardar@mailbox.tu-dresden.de

Website: https://tu-dresden.de/ing/informatik/sya/se/die-professur/beschaeftigte/muhammad-usama-sardar

------------------------------------------------------------------------------------------------------------------------------------------