IETF Logo Mail Archive

[Seat] Re: [Rats] [WIMSE] Re: Re: Re: Re: Follow-up of meeting 122 presentation (Formal proof of insecurity of Intel's RA-TLS and draft-fossati-tls-attestation)

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Fri, 16 January 2026 20:36 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: wimse@mail2.ietf.org
Delivered-To: wimse@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 87C89A8C8B74; Fri, 16 Jan 2026 12:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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 r3Rv6EYF1CsV; Fri, 16 Jan 2026 12:36:09 -0800 (PST)
Received: from mailout7.zih.tu-dresden.de (mailout7.zih.tu-dresden.de [141.76.32.220]) (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 83454A8C8B6A; Fri, 16 Jan 2026 12:36:09 -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:From:References:CC:To :Subject: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=8nhXsnd+AkqyFcBTXqfcvxTvkp7JETvKoNG1e6Et1ig=; b=V2vPGdRxQ5g90s/kPppTzsR0oP RfuPXyCw0aaG+BsG2RYWZSQdilJcBd46oNVG8kbEpyD3OkO5lETVOIVmOb+EGm71Pls4k3m6El+YF jYC4vf9lSIUtjnj2iuR61no8KHr53lM5s8QvJTfdko1Zsn/ikmKY3D1IcKYc19uddkO05xGjl5iuo OyQQJohk8JT6DyRxccjA04cUr5k4cVOMROrz+GmgWyw0TbqZbL8aOmPj+bhB1q5MB5yRivm6io3ti q9hMuMLtUGZdsPZUB5ijIDfLz9Jhz4fKYlZPb5649FAb1Cs1SofQn3DFsVO2tJjoUAZCUY18oTL9m dN2YrkVA==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout7.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1vgqY5-003DCC-2m; Fri, 16 Jan 2026 21:36:06 +0100
Received: from [10.12.5.228] (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; Fri, 16 Jan 2026 21:35:59 +0100
Message-ID: <4978e51d-600d-4f1c-98c0-c3a2d2d065c7@tu-dresden.de>
Date: Fri, 16 Jan 2026 21:35:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: John Kemp <stable.pseudonym@gmail.com>
References: <CAHu=PL2n26wwEtEECb1VqzshJBTJ+chhbcKTNbLeABmM_+eymg@mail.gmail.com> <CBDD5425-01C7-4A2D-97F6-BF66C0E5A0FE@gmail.com> <CAOgPGoAoserfxs4DjMUpexvSfSxnWUzTedd1MPyc74+QTUC1_Q@mail.gmail.com> <cb5ce7ff-6e7c-4891-a1a6-0e5e8d706184@tu-dresden.de> <92BBB51B-5F89-416C-8684-F0A0011D84F0@gmail.com>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <92BBB51B-5F89-416C-8684-F0A0011D84F0@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms030902050105000509010801"
X-ClientProxiedBy: MSX-L415.msx.ad.zih.tu-dresden.de (172.26.34.135) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout7.zih.tu-dresden.de
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Hits: max-recipients
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-size; news-moderation; no-subject; digests; suspicious-header
Message-ID-Hash: QCWWKOOTIEJ5L2DHDLMFVRSEUCAYZEEF
X-Message-ID-Hash: QCWWKOOTIEJ5L2DHDLMFVRSEUCAYZEEF
X-Mailman-Approved-At: Fri, 16 Jan 2026 15:12:23 -0800
CC: Joseph Salowey <joe@salowey.net>, wimse@ietf.org, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Manu Fontaine <Manu@hushmesh.com>, Nathanael Ritz <nathanritz@gmail.com>, Henk Birkholz <henk.birkholz@ietf.contact>, Yaron Sheffer <yaronf.ietf@gmail.com>, Justin Richer <jricher@mit.edu>, Pieter Kasselman <pieter@defakto.security>, wimse-chairs@ietf.org, Sorin Dumitru <sorin@returnze.ro>, rats@ietf.org, seat@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Seat] Re: [Rats] [WIMSE] Re: Re: Re: Re: Follow-up of meeting 122 presentation (Formal proof of insecurity of Intel's RA-TLS and draft-fossati-tls-attestation)
List-Id: "Secure Evidence and Attestation Transport (SEAT) WG" <seat.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/seat/o2K5dENCG3vTP0AO1Ym7c556y8Q>
List-Archive: <https://mailarchive.ietf.org/arch/browse/seat>
List-Help: <mailto:seat-request@ietf.org?subject=help>
List-Owner: <mailto:seat-owner@ietf.org>
List-Post: <mailto:seat@ietf.org>
List-Subscribe: <mailto:seat-join@ietf.org>
List-Unsubscribe: <mailto:seat-leave@ietf.org>

Could WIMSE clarify which one of the following is intended in its 
attestation?

 1. Software-based attestation *only*
 2. Any of software-based attestation or hardware-based attestation

If it is #1, then our attacks are completely irrelevant and I'll close 
my PR.

So a simple question for WIMSE is: is hardware-based attestation in 
scope or not?

If hardware-based attestation is in scope, attacks are in scope.

If hardware-based attestation is out of scope, I don't really see why 
definition says WIMSE attestation is broader than RFC9334. In this case, 
maybe simply say it is software-based attestation.

On 16.01.26 19:54, John Kemp wrote:
>>
>> WIMSE folks seem to have settled at some definition. Looking at the 
>> current definition of attestation of WIMSE in PR [1], I have proposed 
>> a small edit there.
>>
>> One nit: Definition says "Attestation in WIMSE is intentionally 
>> defined quite broadly" but I don't see what exactly is broader than 
>> RFC9334.
>>
> What that specifically means to me is that the WIMSE definition is 
> broader than the defined use-cases specifically mentioned in RFC9334.

Well, I don't think that is quite right. RFC9334 never "defined" any use 
case. Sec. 2 says "Reference Use Cases". We don't limit remote 
attestation to these use cases only. The start of Sec. 2 says explicitly:

This section covers a number of representative and generic use cases for 
remote attestation, independent of specific solutions. The purpose is to 
provide motivation for various aspects of the architecture presented in 
this document. Many other use cases exist; this document does not 
contain a complete list. It only illustrates a set of use cases that 
collectively cover all the functionality required in the architecture.

-Usama

v2.43.4 | Report a Bug | By Email | System Status