IETF Logo Mail Archive

[Seat] Re: [WIMSE] 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> Tue, 06 January 2026 18:18 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: seat@mail2.ietf.org
Delivered-To: seat@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id F0F87A3901C4; Tue, 6 Jan 2026 10:18:12 -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_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 D2UxFhCUTNhF; Tue, 6 Jan 2026 10:18:12 -0800 (PST)
Received: from mailout4.zih.tu-dresden.de (mailout4.zih.tu-dresden.de [141.30.67.75]) (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 EFA0CA3901BA; Tue, 6 Jan 2026 10:18:11 -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=CuMULnVvjMF8Jc7Ce3DgFuIgZ0xEvuBJpguONH515x0=; b=GG4TElcNWIBAQzrqDilnQSv6K/ mHQK7iqtWeUbRdcd4VwakM0SZrkW8tgP70uRRW+UR0SswZJK0sLibDs4Zdd8l5EEevtc0hfGP175t e+Feagq7nldhdqB9/BdawATTelYji0cGAKQNHbo8224b8I2bw3stUUxTZC7xq88arJbwSzTJFMgrO o4kyDEY96IDJEa1oMQxf/XbEc9LULjA6l8bfr36O0K76Wc1Npet8lp+Zvsva8KfI1mQn+m1xtYXwV +TrzuJkENAKqqbdbx9Acu6T19rConndI3bM5woBj1M1IL1Y1u4iDooWwUnez/JuxwOnBvibDGFYSi FamHaMpA==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout4.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 1vdBdC-0015KS-7Q; Tue, 06 Jan 2026 19:18:10 +0100
Received: from [10.12.5.228] (141.76.13.165) 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; Tue, 6 Jan 2026 19:18:02 +0100
Message-ID: <975540a0-0796-417a-b5e8-3a1b204e52cf@tu-dresden.de>
Date: Tue, 06 Jan 2026 19:18:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <8ea21216-8819-4b5d-8526-7dc3ca75c854@tu-dresden.de> <3df51010-820a-4615-af22-9722ab40a94e@returnze.ro> <0516f548-19e0-43a8-a1d4-02feb2da8b50@tu-dresden.de> <1091A040-E13F-41C7-9344-03642A92258F@gmail.com> <97de370c-1f6d-43af-b80b-9850056cc567@tu-dresden.de> <9CE46048-084B-46CF-B0A5-1DAF7FE1FB07@gmail.com> <04151c27-ed12-41cd-93fd-6a20db315fbe@tu-dresden.de> <440F8274-35D6-49C7-AA11-9F2FDB20ABAF@gmail.com> <bcdd15c4-4d79-4dd6-818c-67a0000ccee9@tu-dresden.de> <80B45863-8DDB-4539-80DB-D6342B93CFCF@gmail.com> <890f353f-eae2-4bc8-bd6e-514526e73972@tu-dresden.de> <10E1AEB3-B425-4B3B-B201-D300A37B1FAC@mit.edu> <14295601-86df-4557-beb0-1e1845141417@tu-dresden.de> <CALtWOA20-CF4OJa9SKJG4rVtDKzrukVmwLRYbVMp72PgX_osKQ@mail.gmail.com> <IA0PR01MB8277FFF97ED4DFA5E6F6C3BFBD87A@IA0PR01MB8277.prod.exchangelabs.com> <dcbd8688-2e8c-4060-b9c2-6671596c5f78@tu-dresden.de> <FRWP195MB27649ED4F206519D0C8A4C78A987A@FRWP195MB2764.EURP195.PROD.OUTLOOK.COM>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <FRWP195MB27649ED4F206519D0C8A4C78A987A@FRWP195MB2764.EURP195.PROD.OUTLOOK.COM>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms010403060109040808010201"
X-ClientProxiedBy: MSX-L416.msx.ad.zih.tu-dresden.de (172.26.34.136) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Message-ID-Hash: OIJD3KIOJFAUJTIXGH6KW5XAUF7MHJ35
X-Message-ID-Hash: OIJD3KIOJFAUJTIXGH6KW5XAUF7MHJ35
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: John Kemp <stable.pseudonym@gmail.com>, Sorin Dumitru <sorin@returnze.ro>, "wimse@ietf.org" <wimse@ietf.org>, "rats@ietf.org" <rats@ietf.org>, "seat@ietf.org" <seat@ietf.org>, "wimse-chairs@ietf.org" <wimse-chairs@ietf.org>, Justin Richer <jricher@mit.edu>, Pieter Kasselman <pieter@defakto.security>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Seat] Re: [WIMSE] 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/pHAzqWBpTn2uIBiBffiC93WZJTY>
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>

Hi Yaron,

On 06.01.26 18:12, Yaron Sheffer wrote:
>
> There is no terminology police at the IETF, as far as I know. Working 
> groups, and in fact document authors, are free to define their own 
> terminology.

You may be right. But what I am firstly asking clarification on is why 
attestation needs to be there in the architecture draft, despite the 
rough consensus from IETF meeting 123 [0]. I haven't yet seen any answer 
to that.

Defining is secondary issue and is only required if there is something 
which has overturned that rough consensus.

> Also, it is inappropriate to incorporate text into the WIMSE 
> Architecture draft that tries to settle a question still being 
> discussed at the SEAT WG.

And this text is only option 3 if options 1 and 2 don't work. BTW I 
don't see any discussion happening at SEAT which contradicts the text I 
have proposed. Could you please point me to the exact thread you are 
referring to? Thanks.

-Usama


[0] https://youtu.be/Mv4lgHLxOH4?t=2626

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