[Seat] Re: Comments on formal analysis of relay attacks in intra-handshake attestation (CVE-2026-33697)
Chengxin Huang <aurestarnull@gmail.com> Tue, 07 July 2026 13:57 UTC
Return-Path: <aurestarnull@gmail.com>
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 71D6B111F8959 for <seat@mail2.ietf.org>; Tue, 7 Jul 2026 06:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783432632; bh=bsFDpaOuhtDPaBmdhQTjlsUKaae9a22p8kPrCP2MqSE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=j5Y6WnO9DY/WmXucYM8IKR/Pa/MxICJf2btcvk3141SQSo3K4Qpqop/BHyRpO89wE 68PqJJ34H47u+e8Q3DC5V33Z9IugzlC27vC3qbvMsGDwEYSeAtc9m8lu3w+6RSqHuX Ec3GHEZbViFQoKlN3eROfbgnmAnyla/hA0hGmt0w=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Pm84xh9w5vmc for <seat@mail2.ietf.org>; Tue, 7 Jul 2026 06:57:10 -0700 (PDT)
Received: from mail-pj2-x03.google.com (mail-pj2-x03.google.com [IPv6:2607:f8b0:4864:39::3]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 74DFC111F886E for <seat@ietf.org>; Tue, 7 Jul 2026 06:56:49 -0700 (PDT)
Received: by mail-pj2-x03.google.com with SMTP id d9443c01a7336-2ccb0e85312so8159675ad.0 for <seat@ietf.org>; Tue, 07 Jul 2026 06:56:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1783432603; cv=none; d=google.com; s=arc-20260327; b=T5hRdYZbHte4Qpux6PnOshnUixngZKIltCrJLePpKYCIKcnjf0iQkqJx3S1X/8YTGj h0T9hnYH01oXrNXLNT6UcQDfEBoRtDaja1X+55b7tJUXSMcHRsODes4uqA05QnKHwyZt O9tI5GQJ13ae/J2+sBLTmdRiDZXnkkOPn3bdukJuoQavZEfi8evfNoPHni+ra1k9mPkn ONShPjtIqfH/lypFokSwtmh1ZlEFY4XmJ1gCChuym2VVoKBD8n+2Grwk2YaOjlt4SfWs /Vh2yty20+sOs6ZgfjkJzKkcBOCAUtTvCZJTn27ApNg6+PjuTNcc8wrXCMq1DJ9F2KAV enmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=1RERLDTP2lAQ9EdaErA4XT0xz7YGgNAGsYg/g0/R9OU=; fh=/cZ3APic/sRcNs8STSQUVOUFiRX+y9AUiB0exzhrykM=; b=GCXyk0IP9UYGUSfPHAxz2jt26ObKmEMFRy4f5lxUQZOwcWsbppQg57zUudrSXWGn2z XbYU4RNQ3sI/9+KH92LGD/MKg4onvNIDJJ0xvTn3AlkpWt3xGBN0MfJXrSpv5Sydbs3G rasDiumiVXqRLlLSEfi2hah4ceOOQoM6GLiAWBNd+4B7MhdadXcFYmXPtPG+t05sPxmo VYi+QiOR8c7B955VDzmfEOEfyx98qpios/fBidT/NeU2Zfml6IO8Ndv/CQRG7KpW/Ngu qZDdZZ/bA/Ou5W6G8hquC4BokhdkV7Hd+PP+53H/kuxx19SmaavhJXawtEex+/vKGfRS V10A==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783432603; x=1784037403; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1RERLDTP2lAQ9EdaErA4XT0xz7YGgNAGsYg/g0/R9OU=; b=OSB+LuBZR6D0J8QppFacGxfxOv+ZQ1a7rWu33DjQ855yzGno77pF7OWPKbUCMGBK8J c+YnsFvzz58GDugfhtJwnvgBNSRygS618eo/Gp/kjjFROHye7mC8jWDUMyHVJYXhCh4f KUpPcphQzfGc3SXmSXaJVXWcEp7C+tQSUTUDYBikoVTYYpOKGYFdJfP9vvUt/V0xCmdy S+y+iiA63BEnNcSCXXPUPKhTvBjBxE93Wc5aJE4zLsclrMGFdFnIg1NI1dFyrSlOmZCl eOoCSKu0mtKV5Up3mk416Hp6bix7G0X2Edh1zc4YZ94RdzalW9J/oklgm1mNXeaeZQIj an0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783432603; x=1784037403; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=1RERLDTP2lAQ9EdaErA4XT0xz7YGgNAGsYg/g0/R9OU=; b=C5SWJYQLEkJAZAFBoTSJTmg0yJW9K06kp8qN7kx16SOsPEnUrq5xbRinzN2ND7Bkjh wg+vk227jGZeR8ndmEI6ZaJNDPwilCMU/QrWA5s72Aoiknz1jS9H38Vw8OsOCmvGAK9X nAsXcMJAcK0QdJTV0PlpPhL2tqtw90hI8XdqnfGKuKX/pI4KZLjUojpZL7EzLgYOkqAo 01QIUU7FSE7Jsp6C6DQREW1bUQyDYx429N5usuUdEmsykwzCb8jZFTeIJ+7CSvm0Xykf OPjXj0LstlO+2o/dtCDKqsC9wAKz5gUCthM5hhkH+A9OKDEfWX876QsSvHZgjkw26jC2 sPjw==
X-Forwarded-Encrypted: i=1; AHgh+Ro7fnkmxarEOFbV71b9JE0K0XmEJRln/UBncnzkJjPh+Gper5m+CgEKj84rLYPNvXrkelkq@ietf.org
X-Gm-Message-State: AOJu0Yx+fLCZ8jmoXBxQxMJwkUAv4SCPaciqDMgHIr/pYfCGy8ANEmpl fx87kWQsMs45NnyJcvTloVQTZpiuhzY0GC2XsehGdqsIPJl2DxsDiTPjzJkri8viJm0h48yquZI W8w0hBJcH040NhsRWZxKPH7890qVhbwA=
X-Gm-Gg: AfdE7cmCxOZTV8VZqx3SZiJfUL+Zi9B6AQbtSm5Q4lSbMBFWzo7W1VCWxiyqqUjTld6 D19VBVdJLlBE3GEXXmyolQKTQ3s4bHZzyKRD46mHWSKBFmdXhdo09W/kVdZii+qyJjdjF1o6Ce4 uQp/uqYNTRtMy5fhEv5CHzSefLQixEaDNhIr/ZX7+jTVguFll9pSBPytwiTA9XOG3vbt4zWdZHR 3v6YwXuvKwMmt3ieGkZxjRAtXRDeVWhBiwkoWj8db9s1yqeKGzkkAJ5CeHgscYoK0VaVt0fN1zz i9KpwEJ9+g==
X-Received: by 2002:a05:6a21:3988:b0:3bf:6c08:fb8e with SMTP id adf61e73a8af0-3c08eecc5f1mr6204983637.48.1783432602493; Tue, 07 Jul 2026 06:56:42 -0700 (PDT)
MIME-Version: 1.0
References: <5f361893-bc32-4737-9578-fdb3ad7be3f9@tu-dresden.de> <9F03163D-B0F9-40DD-A4AB-69C151B872D6@aiven.io> <c4a0c433-173d-44ac-bd48-eed642a674d3@tu-dresden.de> <CAHxYnaOBMnPp7EiRLNYWX8AQDc2zYoBL226nfeBiPXsyii7Now@mail.gmail.com> <CAHxYnaOFWQBLf0Pn8bY=CMx7ytSEkTbvj7xp-s0GCHJohRh5xg@mail.gmail.com> <2b53d833-51b8-4915-82b0-ac3305e89528@tu-dresden.de> <CAHxYnaPDTzHuXyeC06bKWNOQ+wYfc-02AVyDETveL7dTteYURA@mail.gmail.com> <CAK08nYaQb6tQzy_nZrJbGbyu1oLuFpAEjTWqe_hY6cmmGzJFvA@mail.gmail.com> <CAHxYnaPyD+mFBgk-axNXCS+9qob-nhF_+Y6eqz9fgPnDvNF5Nw@mail.gmail.com> <34201e80-edb7-4f99-afa2-0d5b5799c6da@tu-dresden.de> <CAHxYnaOUyvMrMRN2C4wjO_s3hpqXDDMJAOAUYyGVt0JRu4RSQQ@mail.gmail.com> <3f87fe50-f0bc-45f7-8ed5-0a7cc7cf975c@tu-dresden.de> <CAHxYnaOsUBJF1+dkhEuPdhExNmk14cWcauxEw-zo6TotWzxsHQ@mail.gmail.com> <8caf22fa-907d-42fd-b3db-0aed8a9fae91@tu-dresden.de> <CAK08nYbdj2XbAM7ndOiXNGdyHf8kD2V26qvmi-gQJ1NjMuQt+Q@mail.gmail.com> <CADmRJY6W0aUs=3ueyUPhoCe3B1bzpgcZdHJ_vGPy_Dy2-zy-zQ@mail.gmail.com>
In-Reply-To: <CADmRJY6W0aUs=3ueyUPhoCe3B1bzpgcZdHJ_vGPy_Dy2-zy-zQ@mail.gmail.com>
From: Chengxin Huang <aurestarnull@gmail.com>
Date: Tue, 07 Jul 2026 21:56:30 +0800
X-Gm-Features: AVVi8CeYm4ii3fdDHtYU8hPMzpZ9bUcR5dhf7zxZ7nWGOGwK5G2yq8sa2PeH73E
Message-ID: <CAP3D6hLRtAsn9zhXi-TFsgqejvS1tukOgkMDxtiL3xDAYq9ong@mail.gmail.com>
To: Steve <zhijieluo1022@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c0a6c3065605c251"
Message-ID-Hash: KK6CMTBFYSEFZEU5VKMSKBRH2NCUYLJ2
X-Message-ID-Hash: KK6CMTBFYSEFZEU5VKMSKBRH2NCUYLJ2
X-MailFrom: aurestarnull@gmail.com
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: Songbo Bu <bluedognull@gmail.com>, Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>, Nathanael Ritz <nathanritz@gmail.com>, seat@ietf.org, ufmrg@irtf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Seat] Re: Comments on formal analysis of relay attacks in intra-handshake attestation (CVE-2026-33697)
List-Id: "Secure Evidence and Attestation Transport (SEAT) WG" <seat.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/seat/wb_Ys9MZd9u9oM2Bk-8tv7fvXGg>
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>
Hello everyone, After careful review, I would like to express strong support for the main results of the Intra-handshake.fail paper and for considering its accompanying code artifacts as substantive technical input for SEAT and UFMRG. The result I find most important is that the security of intra-handshake attestation cannot be judged only by whether Evidence is carried during the TLS handshake. The central question is that how strongly Evidence is bound to the same TLS connection whose keys will protect the later application traffic. This is a protocol-level issue, and it is directly relevant to how SEAT evaluates candidate mechanisms for attested TLS. The paper's analysis of binding levels is especially useful. It connects the Evidence to different stages of the TLS key schedule and explains why some seemingly natural binding materials are not sufficient against relay attacks. In my view, this gives the WG a concrete basis for discussing the paper's result instead of relying only on intuitive message-flow arguments. I also support the methodological direction of the paper. For work that adds attestation-related logic to or around the TLS handshake, explicit security properties and reproducible formal artifacts are the right way forward. Authors make it possible for the community to inspect assumptions, test claims, compare mitigations, and improve the design on a scientific basis. This work is also relevant to UFMRG. It is a practical example of applying formal analysis to an active IETF protocol-standardization problem. The paper and code can help both the standards community and the formal-methods community understand how formal models can be used in real protocol work, including where such models are strong and where further analysis may still be needed. For these reasons, I strongly support the analysis of the paper and support treating the paper and code as important technical input for further SEAT and UFMRG review and refinement, as we move forward. Best regards, Chengxin Huang On Mon, Jul 6, 2026 at 11:17 PM Steve <zhijieluo1022@gmail.com> wrote: > Dear all, > > I am Research Analyst at Cloud Security Alliance (CSA-GCR). > > Because of highly severe attacks, the intra-handshake.fail paper deserves > close attention from the SEAT WG, UFMRG and the related research community. > From a Cloud Security Alliance community and cloud-security industry > perspective, I strongly support bringing the paper and its supporting > open-source code into the WG/RG discussion. > Cloud and confidential-computing deployments rely on attestation > mechanisms that can be implemented, audited, and operated at scale. In this > setting, a protocol extension that adds intra-handshake attestation > behavior affects more than message syntax. It affects implementation > assurance, conformance testing, incident response, certification, and > enterprise risk acceptance. > > The paper is therefore important industry input because it connects a > concrete protocol-design question with formal analysis, relay-attack risk, > and production implementation impact. Its treatment of binding mechanisms > gives cloud providers, enterprise relying parties, security vendors, and > governance teams a sharper basis for judging whether a proposed attestation > transport path delivers security value proportionate to its operational > complexity. > > I strongly support using the Intra-handshake.fail paper and code as a > reference point for further SEAT and UFMRG discussion, and I encourage > review by WG participants, UFMRG experts, confidential-computing > implementers, and cloud-security stakeholders. > > Best regards, > Steve Luo > Research Analyst, Cloud Security Alliance (CSA-GCR) > > Songbo Bu <bluedognull@gmail.com> 于2026年7月6日周一 22:18写道: > >> Hi Usama, Slava, Jean-Marie, all, >> >> Based on my participation in the related research discussions, I >> appreciate sharing Intra-handshake.fail paper and code with the WG/RG and >> strongly support using them as important technical input for the ongoing >> SEAT discussion. >> >> The paper and code is valuable because it makes the discussion more >> property-driven. In particular, I think the WG should explicitly examine >> what security property a hybrid intra-handshake plus post-handshake >> attestation design can satisfy that post-handshake attestation alone cannot >> satisfy. This question is independent of any particular specification >> proposal, and it is important for evaluating whether additional >> intra-handshake complexity is technically justified. >> >> I also support the paper’s narrower focus on intra-handshake attestation. >> Keeping the analysis scoped in this way avoids conflating different >> attestation models and allows the WG/RG to reason more precisely about >> binding mechanisms, relay attacks, and the relationship between Evidence >> and the TLS connection. >> >> From WG charter perspective, the paper is useful because it gives the >> community a concrete object to review, challenge, reproduce, and improve. >> This is especially important where formal models, protocol state-machine >> changes, and production implementations intersect. >> >> It helps bring the standards community and formal methods researchers >> closer to share experience and ideas and provides UFMRG a concrete >> methodology for protocol analysis of AI agents. >> >> For these reasons, I strongly support sharing this paper and code with >> the WG/RG and encourage review from SEAT WG participants and UFMRG >> formal-methods experts. >> >> Best regards, >> Songbo Bu >> >>> _______________________________________________ >> Seat mailing list -- seat@ietf.org >> To unsubscribe send an email to seat-leave@ietf.org >> > _______________________________________________ > Seat mailing list -- seat@ietf.org > To unsubscribe send an email to seat-leave@ietf.org >
- [Seat] Re: Comments on formal analysis of relay a… Iman Schrock
- [Seat] Relay Attacks in Intra-handshake Attestati… Muhammad Usama Sardar
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Давид Nunhausen
- [Seat] Re: [Ufmrg] Re: Re: Comments on formal ana… rachid bouziane
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Muhammad Usama Sardar
- [Seat] Re: [Ufmrg] Re: Re: Comments on formal ana… Dr Küçük Oxford University DPhil Computer S cience
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Nancy Cam-Winget (ncamwing)
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Muhammad Usama Sardar
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Nathanael Ritz
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Paul Wouters
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Muhammad Usama Sardar
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Nathanael Ritz
- [Seat] Comments on formal analysis of relay attac… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Songbo Bu
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Songbo Bu
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Songbo Bu
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Songbo Bu
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Songbo Bu
- [Seat] Re: Comments on formal analysis of relay a… Steve
- [Seat] Re: Comments on formal analysis of relay a… Chengxin Huang
- [Seat] Re: [Ufmrg] Re: Comments on formal analysi… Song Haowen
- [Seat] Re: Comments on formal analysis of relay a… Mark Novak
- [Seat] Re: Comments on formal analysis of relay a… Markus Rudy
- [Seat] Re: Comments on formal analysis of relay a… Mark Novak
- [Seat] Re: Comments on formal analysis of relay a… camilo ayerbe
- [Seat] Re: Comments on formal analysis of relay a… Markus Rudy
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Markus Rudy
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Markus Rudy
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: [Ufmrg] Re: Re: Comments on formal ana… Salz, Rich
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Nathanael Ritz
- [Seat] Re: Comments on formal analysis of relay a… Songbo Bu
- [Seat] Re: Comments on formal analysis of relay a… camilo ayerbe
- [Seat] Re: Comments on formal analysis of relay a… Song Haowen
- [Seat] Re: Comments on formal analysis of relay a… Chengxin Huang
- [Seat] Re: [Ufmrg] Re: Re: Comments on formal ana… Salz, Rich
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: [Ufmrg] Re: Re: Comments on formal ana… Steve
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Muhammad Usama Sardar
- [Seat] Re: Comments on formal analysis of relay a… Markus Rudy
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Muhammad Usama Sardar
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Muhammad Usama Sardar
- [Seat] Re: Relay Attacks in Intra-handshake Attes… Paul Wouters