[Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems
Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Wed, 04 March 2026 15:24 UTC
Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: lake@mail2.ietf.org
Delivered-To: lake@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 025A6C43D2F4 for <lake@mail2.ietf.org>; Wed, 4 Mar 2026 07:24:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.395
X-Spam-Level:
X-Spam-Status: No, score=-4.395 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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 dqwnrF83MSLP for <lake@mail2.ietf.org>; Wed, 4 Mar 2026 07:24:51 -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 0A60FC43D2EA for <lake@ietf.org>; Wed, 4 Mar 2026 07:24:51 -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=1rW9suDLxr/adDVYn8aU1RHdQJZs4A+lXNgHwrtENpw=; b=LkvoctdgKbrKrzBUaYfgGEQ6e6 mNOcXbc5aW8+czE31lEhMTGM63n2J3U46iCYDN4eg2DtvmCpCOBrAAs+Bjmps1RsZsM2YeRpXT3ue FCO8/8UmuASq1eE3QHi+ag0mNm+7ovnwxXebfgp0V1OUfIGx8GnG3gTfI8hBQaA6HdRNMfkgNvx8l t8Ruwjk34JDnF2D4A1tBq79uMA87/bWTz74QJj0rVYaawYgEhz5tYe0N5Wf+4GKr5TKho60yKfdm5 pdWbknyjREeX48uW7jvX9xwL0MzM1oZ5KbdJE1c7B7SaswcAdvIHlRMh0hPLMN40fopDp356DeJ7W Hx4kOhLw==;
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 1vxo5h-00Fu1N-8I; Wed, 04 Mar 2026 16:24:50 +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.37; Wed, 4 Mar 2026 16:24:48 +0100
Message-ID: <e85b426c-23a1-4d1f-8cc2-3bd589b8c1e8@tu-dresden.de>
Date: Wed, 04 Mar 2026 16:24:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Paul Wouters <paul.wouters@aiven.io>
References: <5521ffe4-4f9f-4470-93a2-644841713996@tu-dresden.de> <f40756f9-a7d3-4d3e-a744-1e273d96c496@tu-dresden.de> <2386e955-426e-4e19-ace2-0220d6552be4@tu-dresden.de> <CAGL5yWa6v7awcJv7GAoJ96jgAM7Vy4T4j9nSkiLReUs7zm91Rg@mail.gmail.com>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <CAGL5yWa6v7awcJv7GAoJ96jgAM7Vy4T4j9nSkiLReUs7zm91Rg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms060805020102030208000303"
X-ClientProxiedBy: MSX-L414.msx.ad.zih.tu-dresden.de (172.26.34.134) 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: WIJD7A5NV6QZUZLMXKJBSNVL5UDWOJTC
X-Message-ID-Hash: WIJD7A5NV6QZUZLMXKJBSNVL5UDWOJTC
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: "lake@ietf.org" <lake@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/FyiA29Q_1b9-S_BInmtHPZgQR90>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Owner: <mailto:lake-owner@ietf.org>
List-Post: <mailto:lake@ietf.org>
List-Subscribe: <mailto:lake-join@ietf.org>
List-Unsubscribe: <mailto:lake-leave@ietf.org>
Hi Paul, On 04.03.26 15:11, Paul Wouters wrote: > > On Tue, Mar 3, 2026 at 1:02 PM Muhammad Usama Sardar > <muhammad_usama.sardar@tu-dresden.de> wrote: > > Hi lakers, > > Following up with supporting public evidence: *Cocos AI has > publicly acknowledged [9]* the relay attacks last Friday. > > # *Context* > > As helpful context, Cocos AI [4] claimed their attested TLS to be > the "best in the world" in the Confidential Computing Consortium > and despite we having informed them repeatedly about the attacks > after our formal analysis, they were continuing to misguide the > community on social media. Anyway, we now respect their honesty > and transparency, and we remain fully committed to helping them > towards secure solutions. > > > The "we" in the context appears to refer to IETF until you get to the > end and see two people signing of on this posting. I would be good to > make this more clear and avoid talking about "we" on mailing lists. Please try to understand that I am a researcher and "we" is very common use for me, even when writing a single-authored paper. In my understanding, consensus of the IETF is represented in RFCs and not emails. The emails should at best be interpreted as the list of authors mentioned in the email. If I sometimes forget defining we, please interpret it in that context. BTW there were only two paragraphs until the reader reaches the end of the email. > > Furthermore, the tone of this posting is not conducive to future > collaboration with Cocos AI. The claim of them "misguiding" isn't > really softened by the statement of "we respect them again now". The collaboration exists already! > > # *Cocos AI acknowledgment of attacks* > > Cocos AI (one of the implementers of the protocol) has publicly > acknowledged [9] our email and the relay attacks we highlighted on > their design and implementation in our email. Particularly, see > the sections "Limitations and the Relay Attack" and "The Relay > Attack Scenario" in [9]. Note that their description is almost a > paraphrase of our email. There are some nits that we disagree with > them but that doesn't matter much. They have essentially > acknowledged the attacks and shared a short-term, medium-term and > long-term roadmap for mitigations of the attacks. We believe this > alone is sufficient supporting evidence. > > Similarly, the "has publicly acknowledged" is far from friendly, and > unhelpful for future cooperation. The cooperation exists already! I don't see anything unfriendly and unhelpful in the phrase "has publicly acknowledged". > > Chairs, if there is some time available and you feel it relevant, > we would like to request 5 minutes to present our formal analysis > for lake-ra draft. > > > How does this relate to lake? From what I can tell, Cocos AI used > regular TLS over TCP? You have already asked this before and I have already answered it at [0]. The chairs and authors know the connection and the best I can do is a relay attack to relay this question over to them :) Hopefully, they can explain in some other words that may resonate better with you. Again, if you and LAKE members want that I don't share any results, please let me know and I will then surely not share. If you and LAKE members don't want me to present, I'll cancel the slot as well. I can raise my concerns at IETF Last Call anyway. Best regards, -Usama [0] https://mailarchive.ietf.org/arch/msg/lake/VuWYJKpdpJsDqI_rtvgPqMf4y6o/
- [Lake] Fwd: [Ufmrg] Relay Attacks in Intra-handsh… Muhammad Usama Sardar
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Yuxuan Song
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Paul Wouters
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Muhammad Usama Sardar
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Paul Wouters
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Muhammad Usama Sardar
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Muhammad Usama Sardar
- [Lake] Re: [Ufmrg] Relay Attacks in Intra-handsha… Mališa Vučinić
- [Lake] Re: [Ufmrg] Relay Attacks in Intra-handsha… Muhammad Usama Sardar
- [Lake] Re: [Ufmrg] Relay Attacks in Intra-handsha… Mališa Vučinić
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Paul Wouters
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Muhammad Usama Sardar
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Muhammad Usama Sardar
- [Lake] Re: [Ufmrg] Relay Attacks in Intra-handsha… Mališa Vučinić
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Muhammad Usama Sardar
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Yuxuan Song
- [Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-ha… Muhammad Usama Sardar