Return-Path: 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 3BD731120CB77 for ; Tue, 7 Jul 2026 08:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783437400; bh=1GIfSrJhmWOFQjAqfjXXngBBCOKRYFuaPShi6v1OqOg=; h=In-Reply-To:References:From:Date:Subject:To:Cc; b=cPdiNiurLmqpmgrY2YYEi5kOa8ZhEJ2YTUZ33tsjK9Jt7sVLH4UNFxWM9B12gRJvF izY1mYizNU0h5np3qComT8PW/iDCW4v7U1yNCq8+hvURf5vN5St4/4fGt+80fZBl1Y HzrdaKMVBFjaiEKuNzzgWoAHi0xeTXQAxv8xGY28= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 kOi8Vgh9ZAN1 for ; Tue, 7 Jul 2026 08:16:39 -0700 (PDT) Received: from mail-oi2-x03.google.com (mail-oi2-x03.google.com [IPv6:2607:f8b0:4864:32::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 878271120CB6B for ; Tue, 7 Jul 2026 08:16:39 -0700 (PDT) Received: by mail-oi2-x03.google.com with SMTP id 5614622812f47-495f936d5ecso515343b6e.0 for ; Tue, 07 Jul 2026 08:16:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783437399; cv=none; d=google.com; s=arc-20260327; b=T0cR1/q3xKQi1DF5889EOwve1uRISjvtRITgP7wKi0dQ27yLOsgaSGO+3bC9vxQM2t 0y10+X3DeOUt0CzrINw0P11IG7X09D8U3tTi2jX9bD2xyMA7JxB91wtLEYBhxfFjfkIl h2w5Fo62VUvmBWCxo5Jym/I+SPm/309f6YMr5/M1tvc234Lvyou9SfrWy8d2zLjlDn2l SQLaHkho91KPxZfXqC4yVi+7rOj42D4jNbC8opqcxof0aC99vdgaPVTxH9VVd/jybcOz r4DGo4sN+/ACUsjtVDqBZeti8tTdpxXe19zAxhLnBCDsV+O5kh5tLXQCUeIAUUxBjzrm ZURw== 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:references:in-reply-to :mime-version:dkim-signature; bh=YL0sdSnKRKojtfkHraY7i//+1Q9D1zWz6P8TdV7hi1o=; fh=j+oG1MiotT+mMuZgfGZi8DzmV5m67MLmi4KKPQd/rkI=; b=eS2gQFqyyHjS75Ds/KX7mBznJHel/FzGjnr6TPB5s08DMM2FBp7xfl9XffIYI9+ReM 9gjolWrtB02ZaCP+s0iQi4fFzUhgVYDQAEFESPopDD7SAfqHbgxfbt4t1S5VmNvOt9A/ vMv0vmyJKFlGYYNsdZS8nn+daNAcb6zdO0eqBOu0RPFnBk97EWq4HWuZTY2PlxXre5gv opjd2f/d9+uRwL+qR228diQHX3aHYVmA4EzodKmh0RJbetEegZ9vOsig5a/4VssnIWIq S6kB5d4j5VKnYQlFDvdgL/LCs0CvZPlFVZE1L01kK9K2DTRfZu3zXYWuSk0WuAD8VI6z 31IA==; 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=1783437399; x=1784042199; darn=ietf.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YL0sdSnKRKojtfkHraY7i//+1Q9D1zWz6P8TdV7hi1o=; b=XGqeWSgXqP0P1a6/yDf1eDMjrNcIE8RlcjDyy8trSJUFC+cwZIvcEGo7yf1uWw7QRJ TZe40EjqQksNNUTIb8Gn7D8MU5OJMBp+jO342zFmjH7/Xjp1B4GLXFhnv7C58FkEfyG4 zg84/KRhsU9yfkw5qGmelkgTBrcp+bIp9omNoBn5eU/WtHFWl4Qt33KzaggtSW6ITeLc PdaRjyeQQt40aLWHEiTdVAr7itLflDMeCr/dopFVdiqCT6nYM0Rj/fOe3oPZqkJZ9kiF AeBpCqFBzOO4zu0FdEgsTAxFhJYRksWBgIFa4bevr4UAg1P41gALPCPvSy+9VSyJetJU 4b+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783437399; x=1784042199; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YL0sdSnKRKojtfkHraY7i//+1Q9D1zWz6P8TdV7hi1o=; b=GcN0FlxyAcG120Xjt5x/jZ1AdC4IQQxj1LnqSpjPXPTwwGCVOUBjkgGejdw97zlnGs xezk2Yqr0aanNLRDHQy0E5reJJoJk1Qcnv4Kj8DhNyPXKvySljcylYCbnoxlB7Ta6xzH JP0YTBvjfS/x/RYEILoRQKHlGx1R781Q1AMM4RghJbpC8ye+SVn8SlcXVLj1uPBWm2sa e8nfjaJM0BC/30V15ZNVdd1SBdgtEt3gNxRvg/ByHYWErTNz9jaZqJi1cVtqchGb4/az sDwNiFd357g5vNTlJ+GD+lvYPQp1kJGEMAqauT7lTCSp97DAhq8Y0ypMk9VUb7GZudsX +ENQ== X-Forwarded-Encrypted: i=1; AFNElJ+rTKyUIyKiRs08rMzYWttyw2ZuDovf+4H+CzZm7iP4w9cUaNHzGrh213FYejKjYnBSwZNy@ietf.org X-Gm-Message-State: AOJu0YzYQ3+MRr//8NXEyhFeFl6KZtZXFQOWJrzeA7pQNycql0odIW0R 2PtnyyK7Ctc6xENJdPg13ozWqNH6xfP/psSSvOXy86+l0YOlmbnuw7Ox4kYTZr7WLfcCK8YtaOX gPtLaox0gCcw7M2GGzakFA+diJU+J7C8= X-Gm-Gg: AfdE7cmbXpy6475c/OKbwijJRqkf+b1cxiMIRIuWV8dFDnJHsMnaTvd3iCjxX/9yB9m 1xBW0PQpcAg7iHuKU0SvGnGWWajLdPn68Gp/yXH0GivhEF0De5EwzLvrj/Z3wbYSl0YnfkGyvvN 8jR5NYn6KMbAroEHIVcywrD1QchsfIsXoBO/70qKyVZJDyGH4Z/1uHiml6ERgjeE01ZBEXamPNV x/yzQDdHfcolH40FTXR9JIgojag3wGROUJz2t8pW3iehsrhza6o1lvpvPIRKZ388EXrNNEXXeBV X-Received: by 2002:a05:6808:1508:b0:495:f85b:38c0 with SMTP id 5614622812f47-49fdc43fa56mr4160374b6e.12.1783437398633; Tue, 07 Jul 2026 08:16:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:e847:0:b0:3f6:5f54:20f5 with HTTP; Tue, 7 Jul 2026 08:16:37 -0700 (PDT) In-Reply-To: References: <5f361893-bc32-4737-9578-fdb3ad7be3f9@tu-dresden.de> <9F03163D-B0F9-40DD-A4AB-69C151B872D6@aiven.io> <2b53d833-51b8-4915-82b0-ac3305e89528@tu-dresden.de> <34201e80-edb7-4f99-afa2-0d5b5799c6da@tu-dresden.de> <3f87fe50-f0bc-45f7-8ed5-0a7cc7cf975c@tu-dresden.de> <8caf22fa-907d-42fd-b3db-0aed8a9fae91@tu-dresden.de> From: Song Haowen Date: Tue, 7 Jul 2026 23:16:37 +0800 X-Gm-Features: AVVi8CfA5g5Hfp4XCtDG782RFjf5gM13sFj5xsk0dhQxrWbpAZ8ZnEB5wsBBaPw Message-ID: To: Chengxin Huang Content-Type: multipart/alternative; boundary="0000000000009ff32b065606e005" Message-ID-Hash: AUAIILSBOVGTRYMTSTQ7AK2CCOEQBLEB X-Message-ID-Hash: AUAIILSBOVGTRYMTSTQ7AK2CCOEQBLEB X-MailFrom: havan12050544@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: Steve , Songbo Bu , Muhammad Usama Sardar , Nathanael Ritz , "seat@ietf.org" , "ufmrg@irtf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BSeat=5D_Re=3A_=5BUfmrg=5D_Re=3A_Comments_on_formal_analysis_of_?= =?utf-8?q?relay_attacks_in_intra-handshake_attestation_=28CVE-2026-33697=29?= List-Id: "Secure Evidence and Attestation Transport (SEAT) WG" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009ff32b065606e005 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Usama, Slava and Jean-Marie, One point in your paper that I find especially useful is the way it cleanly separates trust in an attested TLS connection into different binding levels. From a relying party=E2=80=99s perspective, there is a real differe= nce between Evidence that is only related to early handshake material, Evidence that reaches the handshake traffic-key level, and Evidence that is correlated with the application-traffic key that will protect the user=E2= =80=99s data. That distinction makes the paper=E2=80=99s result important. I also think the result is strong because the analysis is not limited to abstract protocol sketches. It considers real-world intra-handshake attestation mechanisms and production implementations, and then evaluates them through explicit correlation properties. That is the right way to handle this problem scientifically. When TLS and remote attestation are composed, intuitive protocol reasoning may be too weak; the security claim has to be stated as a property and checked against a realistic relay-adversary model. I strongly support the results of the paper. Even if the community later refines parts of the model or the mitigation, the current result is already valuable because it identifies the kind of binding property that future attested TLS work needs to satisfy. Thanks Haowen Song On Tuesday, July 7, 2026, Chengxin Huang wrote: > 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 t= he > TLS handshake. The central question is that how strongly Evidence is boun= d > 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 h= ow > 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 th= e > paper's result instead of relying only on intuitive message-flow argument= s. > > 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 assumption= s, > 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 applyin= g > formal analysis to an active IETF protocol-standardization problem. The > paper and code can help both the standards community and the formal-metho= ds > community understand how formal models can be used in real protocol work, > including where such models are strong and where further analysis may sti= ll > 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=E2=80=AFPM Steve w= rote: > >> Dear all, >> >> I am Research Analyst at Cloud Security Alliance (CSA-GCR). >> >> Because of highly severe attacks, the intra-handshake.fail paper deserve= s >> close attention from the SEAT WG, UFMRG and the related research communi= ty. >> 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 t= his >> 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 ris= k, >> and production implementation impact. Its treatment of binding mechanism= s >> gives cloud providers, enterprise relying parties, security vendors, and >> governance teams a sharper basis for judging whether a proposed attestat= ion >> 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 =E4=BA=8E2026=E5=B9=B47=E6=9C=886=E6= =97=A5=E5=91=A8=E4=B8=80 22:18=E5=86=99=E9=81=93=EF=BC=9A >> >>> 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 a= nd >>> strongly support using them as important technical input for the ongoin= g >>> SEAT discussion. >>> >>> The paper and code is valuable because it makes the discussion more >>> property-driven. In particular, I think the WG should explicitly examin= e >>> what security property a hybrid intra-handshake plus post-handshake >>> attestation design can satisfy that post-handshake attestation alone ca= nnot >>> 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=E2=80=99s 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 precis= ely >>> 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 improv= e. >>> This is especially important where formal models, protocol state-machin= e >>> 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 >> > --0000000000009ff32b065606e005 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Usama, Slava and Jean-Marie,

One point in your= paper that I find especially useful is the way it cleanly separates trust = in an attested TLS connection into different binding levels. From a relying= party=E2=80=99s perspective, there is a real difference between Evidence t= hat is only related to early handshake material, Evidence that reaches the = handshake traffic-key level, and Evidence that is correlated with the appli= cation-traffic key that will protect the user=E2=80=99s data. That distinct= ion makes the paper=E2=80=99s result important.

I = also think the result is strong because the analysis is not limited to abst= ract protocol sketches. It considers real-world intra-handshake attestation= mechanisms and production implementations, and then evaluates them through= explicit correlation properties. That is the right way to handle this prob= lem scientifically. When TLS and remote attestation are composed, intuitive= protocol reasoning may be too weak; the security claim has to be stated as= a property and checked against a realistic relay-adversary model.

I strongly support the results of the paper. Even if the c= ommunity later refines parts of the model or the mitigation, the current re= sult is already valuable because it identifies the kind of binding property= that future attested TLS work needs to satisfy.

T= hanks
Haowen Song

On Tuesday, July 7, 2026, Chengxin Huang= <aurestarnull@gmail.com&g= t; wrote:
Hello everyone= ,

After careful review, I would like to express strong support for t= he main results of the Intra-handshake.fail paper and for considering its a= ccompanying code artifacts as substantive technical input for SEAT and UFMR= G.

The result I find most important is that the security of intra-ha= ndshake attestation cannot be judged only by whether Evidence is carried du= ring the TLS handshake. The central question is that how strongly Evidence = is bound to the same TLS connection whose keys will protect the later appli= cation traffic. This is a protocol-level issue, and it is directly relevant= to how SEAT evaluates candidate mechanisms for attested TLS.

The pa= per'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 attack= s. In my view, this gives the WG a concrete basis for discussing the paper&= #39;s result instead of relying only on intuitive message-flow arguments.
I also support the methodological direction of the paper. For work th= at adds attestation-related logic to or around the TLS handshake, explicit = security properties and reproducible formal artifacts are the right way for= ward. Authors make it possible for the community to inspect assumptions, te= st claims, compare mitigations, and improve the design on a scientific basi= s.

This work is also relevant to UFMRG. It is a practical example of= applying formal analysis to an active IETF protocol-standardization proble= m. 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 ma= y still be needed.

For these reasons, I strongly support the analysi= s of the paper and support treating the paper and code as important technic= al input for further SEAT and UFMRG review and refinement, as we move forwa= rd.

Best regards,
Chengxin Huang

On Mon, Jul 6, 2026 at 11:17=E2= =80=AFPM Steve <zhijieluo1022@gmail.com> wrote:
Dear all,

I am Researc= h Analyst at Cloud Security Alliance (CSA-GCR).
=C2=A0
Becaus= e of highly severe attacks, the intra-handshake.fail paper deserves close a= ttention 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 operat= ed at scale. In this setting, a protocol extension that adds intra-handshak= e attestation behavior affects more than message syntax. It affects impleme= ntation assurance, conformance testing, incident response, certification, a= nd enterprise risk acceptance.

The paper is therefore importa= nt industry input because it connects a concrete protocol-design question w= ith formal analysis, relay-attack risk, and production implementation impac= t. Its treatment of binding mechanisms gives cloud providers, enterprise re= lying parties, security vendors, and governance teams a sharper basis for j= udging whether a proposed attestation transport path delivers security valu= e proportionate to its operational complexity.

I strongly sup= port using the Intra-handshake.fail paper and code as a reference point for= further SEAT and UFMRG discussion, and I encourage review by WG participan= ts, 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> =E4=BA= =8E2026=E5=B9=B47=E6=9C=886=E6=97=A5=E5=91=A8=E4=B8=80 22:18=E5=86=99=E9=81= =93=EF=BC=9A
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 a= nd strongly support using them as important technical input for the ongoing= SEAT discussion.

The paper and code is valuabl= e because it makes the discussion more property-driven. In particular, I th= ink the WG should explicitly examine what security property a hybrid intra-= handshake plus post-handshake attestation design can satisfy that post-hand= shake attestation alone cannot satisfy. This question is independent of any= particular specification proposal, and it is important for evaluating whet= her additional intra-handshake complexity is technically justified.

I also support the paper=E2=80=99s narrower focus on i= ntra-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 be= tween Evidence and the TLS connection.

From WG = charter perspective, the paper is useful because it gives the community a c= oncrete object to review, challenge, reproduce, and improve. This is especi= ally important where formal models, protocol state-machine changes, and pro= duction implementations intersect.

It helps bri= ng the standards community and formal methods researchers closer to share e= xperience and ideas and provides UFMRG a concrete methodology for protocol = analysis of AI agents.

For these reasons, I str= ongly support sharing this paper and code with the WG/RG and encourage revi= ew from SEAT WG participants and UFMRG formal-methods experts.

Best = regards,
Songbo Bu
_______________________________________________
Seat mailing list -- sea= t@ietf.org
To unsubscribe send an email to seat-leave@ietf.org
_______________________________________________
Seat mailing list -- sea= t@ietf.org
To unsubscribe send an email to seat-leave@ietf.org
--0000000000009ff32b065606e005--