Return-Path: X-Original-To: ufmrg@mail2.ietf.org Delivered-To: ufmrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 20B6611F56414 for ; Mon, 27 Jul 2026 09:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785168600; bh=flxXOLDEOkmvwivwNvncH4+Ry1GXTNli6u4Dw041gOQ=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=r+n3+iGuGXNekIkGp0mL+CHVzED3EfTfkgVlaK2b52hn8QXaz2P1WZYdzqT2zFCp7 wmmMz2rtbAg7WZPuIUAHNyOvSUSd5RUt3y6XvivASohymdWaYY/5CZ1pDCUrFjdcvx XOG7LGB0HqwxxVQacUrbAEdmGsPK4WouTosboU3g= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=edgeless.systems 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 Cm7vqsqdD2DB for ; Mon, 27 Jul 2026 09:09:59 -0700 (PDT) Received: from DB3PR0202CU003.outbound.protection.outlook.com (mail-northeuropeazlp170100001.outbound.protection.outlook.com [IPv6:2a01:111:f403:c200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1586C11F56404 for ; Mon, 27 Jul 2026 09:09:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rygf/5KvfWI2m+3AKeVyFXrJFSGpsiuMl+RHSDeIzUwryYi2+VTYPvLsN9RzxtuZxMRLARxlhDA1Y6FoYPqMydLT7vF2fCXdyBrWZszith914jKYK60yr9nfYCNa0//0fZhgPaCVPtDfwmiJdnrSdbcm24o/Ke6Qf07ZLI2cfxLIXPG1fGea01vjkGpUTbI2UKmMPx0jn4rmAxpL+wSV3beve1wl5lxv9s79GOU6QCVxvmlMIEelrA2BHDDvYEZhid4xU8PdMTkZszwc0sKcYcq9GUq662Edg7tWC6xbwHuf8ZvlTjHHWi49JNDrvHsHUtIWfJBYusjz7YaIqH3mLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3pSPwkBegUm8OChhzQwPnKYVpOAoYvRbYH09OxYz7Sc=; b=DzvEopqUe9Tk1Pv/oC0Lfe1qQD080u/niP7CFrdSRy57hDif3+IGdRfYIl+iXyFQ8SkwEsfDZcmRJWcIgQKJhVFo42xMw3gCQdQVLF8Vbc/dcPvV5byUj8fa8er4L27aLzl1uy7HsTUFCwX8N1a8X8F7yiNW6H6Z7aQfRIv9ZwOcuoZMZUfHzFW/g8dFYUWaBuDSysl/oorT8265IDM0SjUxO0GNZT8lNeLl5+dbWNsa5OosM3wsCSXvW8zyVNhaL21dgd7NUp1mK312sb7FivBRwWXAPVv1fQJpMxOHhb4tZjBBuZ6eMe1C1mJAMRj1bf/9crQYYQvlqQGM0s9Rgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=edgeless.systems; dmarc=pass action=none header.from=edgeless.systems; dkim=pass header.d=edgeless.systems; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edgeless.systems; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3pSPwkBegUm8OChhzQwPnKYVpOAoYvRbYH09OxYz7Sc=; b=RIMq6upgfd4VU7dxYpK0SnhTTyQfe7y9Tcs1Lh1AYVTQVOK0ZQIpZei1gmZvZYWN8aiAG7nlsZMrWTkAnQE4Zo9E+A/DRhuOTyG64TBCeKrgT/fzNi6BvECCrWg1TdTX8u7j+0EoAQv+xo+CvrF3O85kXMtxs8j1AXybqSCqzy0= Received: from MRWPR02MB12086.eurprd02.prod.outlook.com (2603:10a6:501:83::19) by AM7PR02MB6179.eurprd02.prod.outlook.com (2603:10a6:20b:1a9::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.245.11; Mon, 27 Jul 2026 16:09:50 +0000 Received: from MRWPR02MB12086.eurprd02.prod.outlook.com ([fe80::98d2:5e73:47ef:31]) by MRWPR02MB12086.eurprd02.prod.outlook.com ([fe80::98d2:5e73:47ef:31%4]) with mapi id 15.21.0245.012; Mon, 27 Jul 2026 16:09:50 +0000 From: Markus Rudy To: Muhammad Usama Sardar , "seat@ietf.org" Thread-Topic: [Seat] Comments on formal analysis of relay attacks in attested TLS (CVE-2026-3369) Thread-Index: AQHdBTr4U9vPdzvYIEqgo4DXKpr36LZ/4/YDgABwPgCAAANdaoAAS5gAgACLE36AAIM+AIAACBR1 Date: Mon, 27 Jul 2026 16:09:49 +0000 Message-ID: References: <5f361893-bc32-4737-9578-fdb3ad7be3f9@tu-dresden.de> <9F03163D-B0F9-40DD-A4AB-69C151B872D6@aiven.io> <76b504ae-5692-4f31-a9d2-025974b12339@tu-dresden.de> <5fb42c5c-825b-472b-8455-ce893011ade5@tu-dresden.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=edgeless.systems; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MRWPR02MB12086:EE_|AM7PR02MB6179:EE_ x-ms-office365-filtering-correlation-id: 07009a73-8364-4cca-2b12-08deebf97c70 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|10070799003|23010399003|4143699003|10067099003|6133799003|5023799004|56012099006|22082099003|18002099003|3023799007|8096899003|38070700021|13003099007; x-microsoft-antispam-message-info: 9FwTOuMVe1TKtlLwuJlc/uW4A3g/DtV01QHWxhYPE5adcsIOdrppbzUu4yV19PBITCgYyWs3kji0CL2+6DRaoYFDGSJVEQ//1IrN84iBETzpiX8+f7leYrq6WHwPZ2Lhh8ZZnkkHGj+5LzKc51FD+4if1pyYEnq2d/nW2QoVtUZaJZIYD/WLy4fF4k0Zy6zxrs12NYvd3pqfskOKYQzEzfq6VjPosi4ocrNviofJ2GmtCXeTLNMw/TJlUk1OqqeTawx1nw1yZ/2B8uCijq8SjfJR9D0+W0SxN6iTqodMS2hDy495qKITjeM37cWDHd+0cxSff7qrO87YlKMnj7SwfEnUhFfvBz9/31uL7V3ocZZxzzVMsZPRgMhEv0znOic6niMCWk457V+RxLmjdqsRMppyVi01sHfioLca43N5nMSuGxY1hV19UzykFG2sLogLW99j0fMXbE40DKOpiZrAfuqHnKo90nfYD2meeGujRefAaR+6T427+VJPo6BmDYiw3s1tKPnBBVDqdD70ZB3ccBaYgFhl/nSDVlZK8ZxKblS5hDMofXea4IOrvwxkGD601aAt0Q2BLl3VFxPglm/GuNEO6uBhMOz5Wz3tDiT5G13dmtZVE4AnSPZj70TjZ2O/XTj9OUmXoEgCYpGx7poV5t3YIX8nNBLK/PZIJq3XyJQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MRWPR02MB12086.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(10070799003)(23010399003)(4143699003)(10067099003)(6133799003)(5023799004)(56012099006)(22082099003)(18002099003)(3023799007)(8096899003)(38070700021)(13003099007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?JnDJseQvtvlpu7HBJ5Hjf+OTNd55Pstd7HHSGlOZtN8Z4oPBu0nd6oWiTq?= =?iso-8859-1?Q?TzYU8Nf/T4W06w/dLdDa/Y01JVSyRakEkDkWbG8WzVqUWzwYuUqyf7fh8A?= =?iso-8859-1?Q?jorjCUIGEQ7bJKuaCkGaii0i8ZAdf1pp11ANl6c5+a4frc04AgMS2YR5rK?= =?iso-8859-1?Q?CoTJ5qZE9yqVnF4laRu1A69agZaV3gV0ZVNBgTl+jHicRRGkdFRcuqFzcb?= =?iso-8859-1?Q?yMPVeeCS5m8Og6MYV4S/cZ1qt+ZXLUy8i5hLn369mP7bMU1D0veDTm7NEc?= =?iso-8859-1?Q?BFtDyfcF27Zf2NzV3YcLyHigv8K4YSesfNcyY8e2Zavgu6aYv2XH1pxKcD?= =?iso-8859-1?Q?skjEK0xRNgbzcHB6faNnOmgmDIitZ1LFdHEkhuAeST0gdcd0AcWpkSDoeX?= =?iso-8859-1?Q?Ucj9VNDrQ5NZeYJ6X3vgPsoN0Zx1tI5hehaXooAGAR2RxdewBb1OzUL+J4?= =?iso-8859-1?Q?+mhtrqBsWPbpeyv8uSSxpfY8vBbeJdSTXfvk3Pdgrmayku0ylD7vcup9PE?= =?iso-8859-1?Q?uCDwcPBvveyLpqlT1/dkW2LPyQhLHxxA/D3KgxmQJWmvS5CIP0wRQ4HA0M?= =?iso-8859-1?Q?DE1ZT9jSc9Oe4OJSgvOn5po14y3EmhrM4/mC81T1646StlZ3xxcit5OrWg?= =?iso-8859-1?Q?HBofept8FGqiJwqtlmbrrhGmUXoPe2oaRe2TkmBl2CEzbSNV6z1ClPEohj?= =?iso-8859-1?Q?mtSA/RhpyBdY4cLT4W7JZyyR2DaRMF6LCPuXYKy4I5uZVOdTTNsDuAG7Ds?= =?iso-8859-1?Q?F3+RploAJWPg3b+kVKIZFYeT/0ysKReLhqrelksoJ0QgfmKbZGevcknsmi?= =?iso-8859-1?Q?l7uf7vmXVM7XHEofbx10B74Ix49p6tOiewXsv2i5w+KxJ0uHMACRptNL/V?= =?iso-8859-1?Q?g5sbaV+U/2TZ8s5AXj8VH32msjbHckwGzQf114pv8vzfPGTtpit36Hq5jM?= =?iso-8859-1?Q?p7/W7OyS0FWRM44gBOw3+Tx9e0pEgY4wqP7dB/WtIIVMpwv8IveZMLPQW9?= =?iso-8859-1?Q?pXcZZsGw+JSEq9ZWh/3kWhMyiRV/vK6i8KYYkXLrMmb5hRtEhc//P6jBb1?= =?iso-8859-1?Q?OHREGvY358G0UWDJH+0mlPRQwGof9JjLdi18SdzaqG1twXnDpS19Q/aQZB?= =?iso-8859-1?Q?W70CtpqYcygF3vbhaTBuL7vvlNhtmGdliYiROtjVresH4WJ9Ms2fQixipb?= =?iso-8859-1?Q?qIVox5+Wlz79w/ZbO3eVz7kdaeyYWPaNyhQlty047UXa5B677v8I7kXpY8?= =?iso-8859-1?Q?cREsP1uPQHgmv8+FMflgWChhzrqCYbMTbOXM9ZgjTrQCzbPK76VQK9N6PK?= =?iso-8859-1?Q?xv2Uc9rNk8lgCmIJal7ulb9rIlZqY0RCsKtSsuVIXq3IfHiKDmvmJdxLyf?= =?iso-8859-1?Q?7PY49fkRR6RPwG+rqUTzMF22drgxC0sFcg+FY1qr+krvSjzCJBSN9xhViZ?= =?iso-8859-1?Q?Y9eeoUzfQHvDVFShfzKOaBtF/o9e48awUgUR9BiVb9VpBulaowhaSP0vZN?= =?iso-8859-1?Q?RX0go0q7ly7Tft6ozsrSJ2F/wAiuRMBMj2Hi2J2fZaMG5wycGDySZcOxKv?= =?iso-8859-1?Q?FQZ0Q2824AqUflrPw/CKEPICImyTK0Ix/S44T3O2lnMcQNMNlWIYotjj9Y?= =?iso-8859-1?Q?ywsKo3smZ51IU7P4oAAkSYCRMXKt5AgXNWCxpUWS8ZQAm7AivalYBBp4kd?= =?iso-8859-1?Q?zowSvf8/M61vI4IBbZFO91v+t6A0mDEkm62/WJPdl1x2GVzCovaCb3G/EX?= =?iso-8859-1?Q?2NKnMxnxzh7LoNkFPd6VCh64g2tz2yRmYggaGynuy5iH3ltgrCcdKc49fx?= =?iso-8859-1?Q?xzOgIDxgGcD6AKRCSh8V0LoQ4mIT0qKBSZy31q84srcUBBvl4E+G?= Content-Type: multipart/alternative; boundary="_000_MRWPR02MB120868AB4858FB4957CB1CD2FB7CC2MRWPR02MB12086eu_" MIME-Version: 1.0 X-OriginatorOrg: edgeless.systems X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MRWPR02MB12086.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07009a73-8364-4cca-2b12-08deebf97c70 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2026 16:09:49.9364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: adb650a8-5da3-4b15-b4b0-3daf65ff7626 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1gaKnaV2VYFOEUbdvyF28HKYYt41GEGm1/OEPPIdBX/2OktuiRgAEockUEfCRM4L0QTOtYD7311kSA2s2fqZhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR02MB6179 Message-ID-Hash: KCNEFHSZX64YNQDOA5EHHDH4IZ757WCP X-Message-ID-Hash: KCNEFHSZX64YNQDOA5EHHDH4IZ757WCP X-MailFrom: mr@edgeless.systems 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: "ufmrg@irtf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BUfmrg=5D_Re=3A_=5BSeat=5D_Comments_on_formal_analysis_of_relay_?= =?utf-8?q?attacks_in_attested_TLS_=28CVE-2026-3369=29?= List-Id: Usable Formal Methods Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_MRWPR02MB120868AB4858FB4957CB1CD2FB7CC2MRWPR02MB12086eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Usama, These are indeed the questions I'm trying to wrap my head around. Question = (1) is probably less interesting for SEAT immediately, but should be very i= nteresting to RATS if I'm not mistaken, which again makes it important for = SEAT, but passively. Thanks, looking forward to your next paper! Cheers, Markus ________________________________ From: Muhammad Usama Sardar Sent: Monday, July 27, 2026 5:38 PM To: Markus Rudy; seat@ietf.org Cc: ufmrg@irtf.org Subject: Re: [Seat] Comments on formal analysis of relay attacks in atteste= d TLS (CVE-2026-3369) Hi Markus, To help keep this discussion more focused, here is my understanding of the = points where you would like to see more details: 1. Is binder#6 insecure if LEK of some specific servers (identified by P= IID in Intel TDX) is somehow ruled out? 2. Why our proposed binder in Sec. 7.2 of [0] is insufficient to achieve= level 3 security? You would like to see concrete counter-example trace wit= h intuitive explanation for the attack. * OR you would like to see disproof of G1 <=3D> G2 <=3D> G3 3. Why Intel's POE is insufficient for security? Is there something I have missed? I believe it is much more organized to ha= ve them answered in detailed technical report. So more important than the d= iscussion below is the correction/addition/edits in above questions. We wil= l then work on it and share with the WG/RG. On 27.07.26 10:32, Markus Rudy wrote: 1. Unless I am misunderstanding something, that is not really "missing" in = the paper since that is the proposed binder in Sec. 7.2 of [0], and the res= ults are already in Table 4 of [0]. ProVerif artifacts are in folder 'propo= sal' of [3]. Thanks, I don't know how I managed to miss that, sorry. No worries; I realize that the paper is quite dense. Please take your time = to read it. 2. I believe I covered a good number of intuitive arguments in slide 2 of m= y SEAT presentation [1]. I think what's missing in that slide are two observations: - If the handshake secret is known to the attacker, that attacker can compr= omise the application traffic secrets. So the handshake secret security is = not "irrelevant for security goals". The first statement is correct but it addresses a different point. Also, I = do not see how the second follows from the first and hence I disagree with = the second one. Please note that I talked about handshake traffic keys and not handshake se= cret. They are both different. When one dives into the subtleties of key sc= hedule, one realizes how important the distinction is. There is no direct dependency for application traffic keys on the handshake= traffic keys. Please see figure 2 of [4]. Handshake traffic keys may be le= aked/compromised independent of application traffic keys. - The server may not be authenticated at the point where evidence is genera= ted, but it is authenticated after the TLS handshake completes. That's my a= rgument: if you look at the entire state of the TLS session, after it's cre= ated, it's enough to observe binding to the handshake secret and authentica= ting the server as in standard TLS. Please note that unlike TLS threat model, in addition to the network, Serve= r is malicious here. 3. I'm not sure what question you are trying to settle for SEAT, where the = charter says [...] This discussion came up several times on the list, and I don't think "deriv= ing a binder from a TLS key" is considered an extension of the key schedule= by everyone. I don't think it is "deriving a binder from a TLS key," rather extending th= e TLS key schedule to derive a key which is then used in the binder. My worry is that the TLS WG agreed to do this work under certain conditions= . If we go to TLS WG asking this, probably the first question they will ask= is why the well-established and formally verified mechanisms like RFC9261/= RFC9266 are insufficient. It has lesser complexity and more security. Above= that, one needs post-handshake attestation for continuous attestation in a= ny case. The key schedule complexity seems very hard to justify. Alternatively, we can ignore these conditions. I am not sure that would be = productive, because it will ultimately be raised at the IETF LC. Is EKM an extension of the key schedule, too? I don't understand why would it be. It is a part of Sec. 7.5 of the standar= d RFC9846. Deriving another key from the exported key material? Could you please share a concrete example to understand better? and why suc= h a key is required? Thanks for the clarification. I believe Table 4 in [0] has clear counter-ex= amples to your argument. For instance, there are binders which satisfy G1 b= ut not G2 and G3. I'm sorry to say, but that is a table with emojis, not a clear counter-exam= ple. You may be aware of the concrete counter examples, but they are not ve= ry accessible in their current form. It would be enlightening to see the ac= tual counter-examples, because then we could understand whether we're missi= ng considerations from standard TLS security in the formal analysis. Sec. 7.1 of [0] is intuitively explaining all the seven cases with two of t= he traces in Fig. 5 and explaining what would change in other cases. I'd li= ke to understand which one you disagree with and the rationale. So could yo= u point me to the specific case or trace that you believe is insufficient o= r incorrect? That would help me understand where our interpretations differ= . Just to make sure you are looking at the right figure, I mentioned Fig. 3 o= f [0] which is the protocol and not the TLS key schedule. So I am not sure = why you are mentioning "not part of the TLS key schedule." Sorry for the imprecision, but I was hoping the rest of my mail somehow con= veyed the message: this is not specific to TLS! Nothing changes in that pic= ture! Assurance of non-LEK is guaranteed out of band! To me, this seems analogous to saying: I was guaranteed out of band that I = am talking to an uncompromised endpoint. If I have that guarantee, then it = is not clear to me why I would use attestation at all. With that guarantee,= I could use standard TLS. 3. How is that identity supplying entity trusted? [...] - I'm running on hardware provided by my CSP. The CSP can simply publish a = list of known PIIDs; or they can cross-sign PCK certificates to endorse the= machines they own and operate (this is what POE does). I am not aware of any list of known PIIDs published by any CSP. If someone = knows, please share a link. So I assume your parenthesis text refers to cross-sign. Certificates are ty= pically signed just once by the CA. I don't believe I've heard the term "cr= oss-sign" in the context of certificates before. So could you please elabor= ate this part; as in what exactly does CSP sign? If the CSP does not sign a= connection-specific transcript, it is still vulnerable to relay attacks. M= oreover, how does the other endpoint (verifying relying party) get the publ= ic key of CSP? I am not sure what you are talking about, and how this is related to the pa= per and this discussion. We are not comparing with and without TEE. In the = world I live in, security is always evaluated compared to the claimed secur= ity properties. Confidential computing made a claim that there is no need t= o trust the cloud provider, and we are saying this is not possible in the c= urrent technologies. I don't think we need to discuss the discrepancy between marketing and real= ity here - we agree on that. However, if we take "Cloud provider does not n= eed to be trusted to some extent" as a mandatory security property, we will= not be able to produce any secure protocol. This is very intuitive to unde= rstand: the CSP can mount a hardware attack, which is out of scope for TEE = security properties, and either impersonate a TEE or extract secrets (not o= nly EK, but also the traffic secrets). What I'm saying is that trusting the= CSP does not defeat the purpose of TEEs (at least not entirely). Thanks, and good to know that we largely agree on the marketing and reality= of confidential computing. Best, -Usama [0] https://www.researchgate.net/publication/408219182_Intra-handshakefail_= CVE-2026-33697_High-severity_CVE_in_Attested_TLS [1]: https://datatracker.ietf.org/meeting/126/materials/slides-126-seat-bin= ding-properties-of-expat-00 [2] https://www.researchgate.net/publication/398839141_Identity_Crisis_in_C= onfidential_Computing_Formal_Analysis_of_Attested_TLS [3] https://github.com/muhammad-usama-sardar/intra-handshake.fail [4] https://www.researchgate.net/publication/385384309_Towards_Validation_o= f_TLS_13_Formal_Model_and_Vulnerabilities_in_Intel's_RA-TLS_Protocol --_000_MRWPR02MB120868AB4858FB4957CB1CD2FB7CC2MRWPR02MB12086eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Usama,

These are indeed the questions I'm trying to wrap my head around. Question = (1) is probably less interesting for SEAT immediately, but should be very i= nteresting to RATS if I'm not mistaken, which again makes it important for = SEAT, but passively.

Thanks, looking forward to your next paper!

Cheers, Markus


From: Muhammad Usama Sardar
Sent: Monday, July 27, 2026 5:38 PM
To: Markus Rudy; seat@ietf.org
Cc: ufmrg@irtf.org
Subject: Re: [Seat] Comments on formal analysis of relay attacks in = attested TLS (CVE-2026-3369)

Hi Markus,

To help keep this discussion more focused, here is my understanding of= the points where you would like to see more details:
  1. Is binder#6 insecure if LEK of some specific servers (identified by PII= D in Intel TDX) is somehow ruled out?
  2. Why our proposed binder in Sec. 7.2 of [0] is insufficient to achi= eve level 3 security? You would like to see concrete counter-example trace = with intuitive explanation for the attack.
    • OR you would like to see disproof of G1 <=3D> G2 <=3D> G3
  3. Why Intel's POE is insufficient for security?

Is there something I have= missed? I believe it is much more organized to have them answered in detai= led technical report. So more important than the discussion below is the co= rrection/addition/edits in above questions. We will then work on it and share with the WG/RG.

On 27.07.26 10:32, Markus Rudy wrote:
1. Unless I am misunderstanding something, that is not really &qu=
ot;missing" in the paper since that is the proposed binder in Sec. 7.2=
 of [0], and the results are already in Table 4 of [0]. ProVerif artifacts =
are in folder 'proposal' of [3].=0A=

Thanks, I don't know how I managed to miss that, sorry.
No worries; I realize that the paper is quite dense. Please take your = time to read it.
2. I believe I covered a good number of intuitive arguments in sl=
ide 2 of my SEAT presentation [1]. =0A=

I think what's missing in that slide are two observations: =0A=
=0A=
- If the handshake secret is known to the attacker, that attacker can compr=
omise the application traffic secrets. So the handshake secret security is =
not "irrelevant for security goals".

The first statement is co= rrect but it addresses a different point. Also, I do not see how the second= follows from the first and hence I disagree with the second one.

Please note that I talked= about handshake traffic keys and not handshake secret. They are both d= ifferent. When one dives into the subtleties of key schedule, one realizes = how important the distinction is.

There is no direct depend= ency for application traffic keys on the handshake traffic keys. Please see= figure 2 of [4]. Handshake traffic keys may be leaked/compromised independent of application traffic keys. 

- The server may not be authenticated at the point where evidence=
 is generated, but it is authenticated after the TLS handshake completes. T=
hat's my argument: if you look at the entire state of the TLS session, afte=
r it's created, it's enough to observe binding to the handshake secret and =
authenticating the server as in standard TLS.
Please note that unlike TLS threat model, in addition to the network, = Server is malicious here.
3. I'm not sure what question you are trying to settle for SEAT, =
where the charter says [...]=0A=

This discussion came up several times on the list, and I don't th=
ink "deriving a binder from a TLS key" is considered an extension=
 of the key schedule by everyone.

I don't think it is "= ;deriving a binder from a TLS key," rather extending the TLS key sched= ule to derive a key which is then used in the binder.

My worry is that the TLS = WG agreed to do this work under certain conditions. If we go to TLS WG aski= ng this, probably the first question they will ask is why the well-establis= hed and formally verified mechanisms like RFC9261/RFC9266 are insufficient. It has lesser complexity and more s= ecurity. Above that, one needs post-handshake attestation for continuous at= testation in any case. The key schedule complexity seems very hard to justi= fy.

Alternatively, we can ign= ore these conditions. I am not sure that would be productive, because it wi= ll ultimately be raised at the IETF LC.

 Is EKM an extension of the key schedule, too?
I don't understand why would it be. It is a part of Sec. 7.5 of the st= andard RFC9846.
 Deriving another key from the exported key material?

Could you please share a = concrete example to understand better? and why such a key is required?

Thanks for the clarification. I believe Table 4 in [0] has clear =
counter-examples to your argument. For instance, there are binders which sa=
tisfy G1 but not G2 and G3.=0A=

I'm sorry to say, but that is a table with emojis, not a clear co=
unter-example. You may be aware of the concrete counter examples, but they =
are not very accessible in their current form. It would be enlightening to =
see the actual counter-examples, because then we could understand whether w=
e're missing considerations from standard TLS security in the formal analys=
is.

Sec. 7.1 of [0] is intuit= ively explaining all the seven cases with two of the traces in Fig. 5 and e= xplaining what would change in other cases. I'd like to understand which on= e you disagree with and the rationale. So could you point me to the specific case or trace that you believe is in= sufficient or incorrect? That would help me understand where our interpreta= tions differ.

Just to make sure you are looking at the right figure, I mentione=
d Fig. 3 of [0] which is the protocol and not the TLS key schedule. So I am=
 not sure why you are mentioning "not part of the TLS key schedule.&qu=
ot;=0A=

Sorry for the imprecision, but I was hoping the rest of my mail s=
omehow conveyed the message: this is not specific to TLS! Nothing changes i=
n that picture! Assurance of non-LEK is guaranteed out of band!
To me, this seems analogous to saying: I was guaranteed out of band th= at I am talking to an uncompromised endpoint. If I have that guarantee, the= n it is not clear to me why I would use attestation at all. With that guara= ntee, I could use standard TLS.
3. How is that identity supplying entity trusted?=0A=

[...]=0A=
- I'm running on hardware provided by my CSP. The CSP can simply publish a =
list of known PIIDs; or they can cross-sign PCK certificates to endorse the=
 machines they own and operate (this is what POE does).

I am not aware of any lis= t of known PIIDs published by any CSP. If someone knows, please share a lin= k. 

So I assume your parenthe= sis text refers to cross-sign. Certificates are typically signed just once = by the CA. I don't believe I've heard the term "cross-sign" in th= e context of certificates before. So could you please elaborate this part; as in what exactly does CSP sign? If the CSP d= oes not sign a connection-specific transcript, it is still vulnerable to re= lay attacks. Moreover, how does the other endpoint (verifying relying party= ) get the public key of CSP?

I am not sure what you are talking about, and how this is related=
 to the paper and this discussion. We are not comparing with and without TE=
E. In the world I live in, security is always evaluated compared to the cla=
imed security properties. Confidential computing made a claim that there is=
 no need to trust the cloud provider, and we are saying this is not possibl=
e in the current technologies.=0A=

I don't think we need to discuss the discrepancy between marketin=
g and reality here - we agree on that. However, if we take "Cloud prov=
ider does not need to be trusted to some extent" as a mandatory securi=
ty property, we will not be able to produce any secure protocol. This is ve=
ry intuitive to understand: the CSP can mount a hardware attack, which is o=
ut of scope for TEE security properties, and either impersonate a TEE or ex=
tract secrets (not only EK, but also the traffic secrets). What I'm saying =
is that trusting the CSP does not defeat the purpose of TEEs (at least not =
entirely).

Thanks, and good to know = that we largely agree on the marketing and reality of confidential computin= g.

Best,

-Usama


[4] https://www.researchgate.net/publication/385384309_Towards_Validation_of_TL= S_13_Formal_Model_and_Vulnerabilities_in_Intel's_RA-TLS_Protocol

--_000_MRWPR02MB120868AB4858FB4957CB1CD2FB7CC2MRWPR02MB12086eu_--