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 2922E1253EB48 for ; Fri, 7 Aug 2026 01:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786092339; bh=vl6BwKaKt4t63QnBauyo0G6wyIt6YorYVt8FAZX2I3U=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=mghmgYr/EObqp4H4x93b71vRqIEh6Es8SOLl15l2+3Mf57bkJBfqeFiWfEugYoA56 DaaaP7k+T0djjhA8bOA94u54useOsqpmEHPCTfruPakTgV2HseW9oAJPDuO3uX/RNf 9ECmu9AmTp7cJHFP0LuQlLL1Bj9fIygyMXzXpHPw= 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=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 nxB6eDLVjMw5 for ; Fri, 7 Aug 2026 01:45:38 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 ABD5E1253E83E for ; Fri, 7 Aug 2026 01:45:26 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id 6a1803df08f44-8f23e851626so18765636d6.3 for ; Fri, 07 Aug 2026 01:45:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786092326; cv=none; d=google.com; s=arc-20260327; b=Br3qBbHpa4GoKoiIFqoY4w2Kl6dL+8dAZqTzbXkkPblBGfvGUHKsYxjMRBV8dBZ7Zs srp6EZKKA8Lq9GJwEzOD368Poe9RXuVoIpvc+R+DZVduX0ugIHJ3SZ4LqwvI8U3WxXgK xvW7PMnwVM+fY2NRnszqNRCAaOWGTBtDO2KMEOWnPPjTEvwR8UoR2VWNeGLrg9GEcG2f whdCEh/0tsL4H3dsS2A5j5BF0A6NSgajMvxGKnfTCZyvvgbWrIAEY/qcAXpiCxAxU2dh tKqPF5NzLSTWJX4BhNZvkA/qh0Yv2awc2KYOMr5KA7Q/YUwP6AVbUf2/gsR6bvb2EscZ mScQ== 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=vl6BwKaKt4t63QnBauyo0G6wyIt6YorYVt8FAZX2I3U=; fh=zVwvUZn6wAO3TheMJRQBqdkSwtBgQ/Y4cQ1HYYnZYas=; b=cJxdtXfTsUyBDzSk2OWpvQGicPaJyv+Gw50YfGehQMnbtjF+Zoc4TYhjoS5PedvjFG KXKK5+uSo+ZFWpkPx4mqw5ONFs6EcYkwCYBzjySZPiPxWkeNAiDk8fy5KumRpVaZ1qQ0 /eOPzb6Wp2sKgMCRJUJaajjLb0PTk5b4KjyVHIDUruvOsa77H3kn0HpuaQtaxFKoXBgY sBQwyZq2rx8//sq4CtE88mvCoKnVinFKh7LSvEIgZEBj2XrYB8weY/54kIvZymO++q5t HDRbj8UTfSKiYr0Lkld3HTmxQbX42Q/toQaF3mUio5tjQIHDwMM5G+hpxFymDdDgynky 7rHA==; 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=1786092326; x=1786697126; 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=vl6BwKaKt4t63QnBauyo0G6wyIt6YorYVt8FAZX2I3U=; b=eDxuvXW7J/GSd1TGbZyfnxlWEuq239MBODDT5L3gbqdkHfSK1S0fQKh7p+D+ggJ8hV y91VWHOVQXmZrpFMV2nXWHAKvI9eX4aX7zOTOe8Rj+6K2FJSSSKLjJwZ4iMrBthvoDnY hhOH/k2+UHN247yV+9YJhz2z+7SDojSRfqT1Z13q+i1bHzhv0tAn+kK9quB9k2UNjWr5 d38ny4s0Rx2cEKJyM8PWspxgUdGwUlCgm0zQcKkWmuHd8ebAJaL9YPEF43rK6X1jMpvg zDo30E6+XBXYWJHn586I/pGCp1hG6ecWn9oUKoNFlwu7YflWhjdR/DnY1jVWfAEhmmPU iAPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786092326; x=1786697126; 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=vl6BwKaKt4t63QnBauyo0G6wyIt6YorYVt8FAZX2I3U=; b=ZXn4Yo6plCJjiJmq7vMy0CrDIBnVuCRsEw2bUepWV5pP+nDmeF6R5DW6aZTfhMoGI9 I6GI8OxTEnf2/GtpXrgDsK1IaU1ZkGB/ADKO2WOKvMQy9hwbuUzMl7FhIB+klJUhOUxx l/dD1yT2QgjkvLFxjUt8UoHlcpuDkQJUqiayrOKZv+z21Kbb3gbX+a7c2KzZqgfW179i g0tEGDGmAt0YiYq3B9Cwc4g60W9BYsgOwURjW0iBeOmSfGiqzpwO+pChnyVterBXqhcG hj5AAYk7mLNGmMIuLnMx0DfhG3ExBK/kD1bTVEoXaE5OPId2ebEFAsFWiETXegytOswT PzUg== X-Forwarded-Encrypted: i=1; AHgh+RoaL7RewbbiGT6YZSIf+mCPRJ5YdIjjxU4bYQYDYu4x+acbVlALdynqF9kI3Ggs/ztfORa2@ietf.org X-Gm-Message-State: AOJu0Yw5romNNu7RRRPGVOXhe5d+4g92Kw/YUsoWxXdfR+wVekemv/h+ iX0NB2/P8n5oFouaMNZQf53AC35zRK2Rl7w2uBXv3auqjB35DUz2ocjGwqN8BFWdV8ZW9FW0Lg4 D1bqpOBpGQ1e4Y48/xEZ886yOa3Ah5vA= X-Gm-Gg: AR+sD11oSU6MkjaTXaZSkvsgKu7tZ3lp+R3wKjpU5Cgkv3noLe+EhsuklD+L7wxmX1X 5S4uhoSC+3sco3C0kf6yKxkyZL2cfqm2fiNXDX0hQtkitvUbZmFdZ+ZfYbU3rWowcb+BnT/+6SR xtRHqOJzbnatAKY1dyA8SBKPi5Zd8m+nZ59rvFO/wZ3Mu6HdJEXtJqw6vF/4mBK7TReN37m77P+ 7VFa0pBE+0045Mg+SIuDPOPDVPvf633clo3ZrDL2KiLj5MDvJEdtWFrAx/fvgtXzT9/vmV6M4vD /jEPMWg5tKNuVOAy4kojYNdJETMuCZjd1g5XI5diP8SE2X6OgKgpXVoFL8caGSeiVDXyDC+8ig= = X-Received: by 2002:a05:6214:e8b:b0:908:1bd5:9c38 with SMTP id 6a1803df08f44-908811b4ca9mr243281966d6.14.1786092325692; Fri, 07 Aug 2026 01:45:25 -0700 (PDT) MIME-Version: 1.0 References: <178592625332.1174.15715227575457159982@dt-datatracker-54dc84885d-8d5gh> In-Reply-To: From: Songbo Bu Date: Fri, 7 Aug 2026 16:45:14 +0800 X-Gm-Features: AUfX_mzsZJ-ESgZjcNr4opp0iqGVVM-F2mtCiHtRNVuHOXRjG0nK7BN1j9NtaOI Message-ID: To: Ionut Mihalcea Content-Type: multipart/alternative; boundary="0000000000009be6b4065871066c" Message-ID-Hash: URG3XP2RXY5YRXCSSUGYFY6XGFYQCQSW X-Message-ID-Hash: URG3XP2RXY5YRXCSSUGYFY6XGFYQCQSW X-MailFrom: bluedognull@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: tirumal reddy , Muhammad Usama Sardar , "seat@ietf.org" , nd X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BSeat=5D_Re=3A_FW=3A_New_Version_Notification_for_draft-fossati-?= =?utf-8?q?seat-early-attestation-06=2Etxt?= List-Id: "Secure Evidence and Attestation Transport (SEAT) WG" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009be6b4065871066c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Nathanael, Ironically, the approach to keep working on the solution without knowing the property is ad-hoc approach. As clarified before, the constructive purpose is to judge whether the complexity of intra-handshake attestation is required to satisfy some property. If we do not know the goal we are trying to achieve, how can we ever achieve it? So property is critical to SEAT success and this is surely a technical approach. Several members have supported this approach. Formally, attestation binder in section 5.1.1 of the draft-06 does not introduce anything new that needs a new formal analysis. Intra-handshake.fail and CVE-2026-33697 apply as is. The fundamental misunderstanding you are having is that the book by Boneh and Shoup does not talk about attestation at all. The threat model for attestation is different from traditional authentication mechanisms. Part of the server is untrusted in attestation, which is not the case in traditional authentication mechanisms and hence your citation of the book and protocol 'AKE4' is completely irrelevant to this technical discussion. Both papers ID-Crisis and intra-handshake.fail present concrete counter-examples with complete technical details with open-source code, which apply to this draft. Would we like to design a protocol that breaks if any single machine in the whole world breaks? It is unclear what you are trying to achieve by raising these questions. Best, Songbo Ionut Mihalcea =E4=BA=8E2026=E5=B9=B48=E6=9C=886= =E6=97=A5=E5=91=A8=E5=9B=9B 18:49=E5=86=99=E9=81=93=EF=BC=9A > Hi, > > Agree with Tiru, quoting from the CVE: "Because the attestation evidence > is bound to the ephemeral key *but not to the TLS channel*, possession of > that key is sufficient to relay or divert the attested TLS session" > (emphasis mine), and also from Tiru's initial email: "the resulting binde= r > is unique to the connection (two-sided uniqueness). Evidence generated in > one connection therefore cannot be replayed in another." > > I also continue to disagree with the assumption that binding to or > correlation with the application traffic secret is the only possible secu= re > construction. > > Thanks, > Ionut > > *From: *tirumal reddy > *Date: *Thursday, 6 August 2026 at 10:27 > *To: *Muhammad Usama Sardar > *Cc: *seat@ietf.org > *Subject: *[Seat] Re: FW: New Version Notification for > draft-fossati-seat-early-attestation-06.txt > > Hi Usama, > > CVE-2026-33697 was not established against this draft. The binders > analyzed in your paper differ from the one specified in Section 5.1.1 of > this draft, and the models in your paper seem to add a dual > CertificateVerify that this draft does not specify. The CVE is therefore > not demonstrated against draft-fossati-seat-early-attestation. > > If you maintain that it applies, please demonstrate the relay attack > against the binder as specified in Section 5.1.1: the > ClientHello...ServerHello transcript checkpoint plus the hash of the publ= ic > key of the attester's end-entity certificate used for authentication with= a > standard CertificateVerify specified in TLS 1.3. > > We will review any concrete demonstration. > > Best Regards, > -Tiru > _______________________________________________ > Seat mailing list -- seat@ietf.org > To unsubscribe send an email to seat-leave@ietf.org > --0000000000009be6b4065871066c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Nathanael,

Ironically, the approach to keep w= orking on the solution without knowing the property is ad-hoc approach. As = clarified before, the constructive purpose is to judge whether the complexi= ty of intra-handshake attestation is required to satisfy some property. If = we do not know the goal we are trying to achieve, how can we ever achieve i= t? So property is critical to SEAT success and this is surely a technical a= pproach. Several members have supported this approach.

Formally, att= estation binder in section 5.1.1 of the draft-06 does not introduce anythin= g new that needs a new formal analysis. Intra-handshake.fail and CVE-2026-3= 3697 apply as is.

The fundamental misunderstanding you are having is= that the book by Boneh and Shoup does not talk about attestation at all. T= he threat model for attestation is different from traditional authenticatio= n mechanisms. Part of the server is untrusted in attestation, which is not = the case in traditional authentication mechanisms and hence your citation o= f the book and protocol 'AKE4' is completely irrelevant to this tec= hnical discussion.

Both papers ID-Crisis and intra-handshake.fail pr= esent concrete counter-examples with complete technical details with open-s= ource code, which apply to this draft. Would we like to design a protocol t= hat breaks if any single machine in the whole world breaks? It is unclear w= hat you are trying to achieve by raising these questions.

Best,
= Songbo

Ionut Mihalcea <Ionut.Mihalcea@arm.com> =E4=BA=8E2026=E5=B9=B48=E6= =9C=886=E6=97=A5=E5=91=A8=E5=9B=9B 18:49=E5=86=99=E9=81=93=EF=BC=9A
Hi,

Agree with Tiru, quoting from the CVE: "Because the attestation eviden= ce is bound to the ephemeral key *but not to the TLS channel*, possession o= f that key is sufficient to relay or divert the attested TLS session" = (emphasis mine), and also from Tiru's initial email: "the resulting binder is unique to the connection (two-sided u= niqueness). Evidence generated in one connection therefore cannot be replay= ed in another."

I also continue to disagree with the assumption that binding to or correlat= ion with the application traffic secret is the only possible secure constru= ction.

Thanks,
Ionut

_______________________________________________
Seat mailing list -- sea= t@ietf.org
To unsubscribe send an email to seat-leave@ietf.org
--0000000000009be6b4065871066c--