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 B2BB712717423 for ; Mon, 10 Aug 2026 03:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786358170; bh=DVHKkKqZwyqODJjJLq4a4saapjKGnegyni1yuH3fPGM=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=EyVJahG8fIdbNcWNJ56UycfaXAGGolKM+wMFyiun4jtRTusd0kicIqjRLrg6xjUzE q2PArxSGrJ1bDkXr2kD/HJms+XGnXLIUASTmkMQ2W/4Omd7Q/NbmPkGMAtVubofS3T UzilN4+kFOKa5m4tR8NlsOPNStvM4WlyVGyO+SM8= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 I0TWg6ShAUGg for ; Mon, 10 Aug 2026 03:36:09 -0700 (PDT) Received: from mail-oi2-x02.google.com (mail-oi2-x02.google.com [IPv6:2607:f8b0:4864:32::2]) (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 C647B12717418 for ; Mon, 10 Aug 2026 03:36:09 -0700 (PDT) Received: by mail-oi2-x02.google.com with SMTP id 5614622812f47-4ab2d8e7e4cso362702b6e.1 for ; Mon, 10 Aug 2026 03:36:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786358169; cv=none; d=google.com; s=arc-20260327; b=HULaimghXZchik3Sb6TyBgWgWCPlkOeWGB9j1+rlYDalT2Njz+NqsfjtzB3twYEa0u B9C1E09Yxucuv/o0aMdBWcVVoOQpM5wof9IpblP9qYLJdIDA+6Q8NvUpIGuoa2FA1Ehj 9K0610GojHpM819RMIzvU1DxYpgHYIL4wjFufLlcmTxJTjv2/CxK7mzPUQFyIdG5aCAO jVAmQJmIR2SNEkBNpetb8EbcGON3HpLbe0xsL4uywjU+n489xMwRHvGaJaYLxHVvGZzB irRve7bEyPA+7noD0LZ3ges5+7aPA3C7mGYhzKPcRCC/L+XdZiPr0GFBsk3rNmS5wTeK RbMw== 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=RRXBOmNTjqqbZfMqBxAqGdktvRSBv7clJPxaQTp9Dfc=; fh=vr0F7gM7bu0nJTSA/bKxvQiWVJIZUsXpNV46cYYfsDM=; b=eHVx20cvtdD+Nk9WgQNn+2f7Sw5HXZ0xnZeKZE6EenMPtdsMbdGIr4goAqoBf3gdya UtyAfwPMmCbjT7bI5Ek42RPRo3VFZqRKcCNSeLHLLHsyT2HOglVjL5cLmzR97FsgKl/p m4FVy/lO+EOXvadlkiZSYvPCDz+S358v/zt57oB7C/QwTIULWtJ2ZqCtAhqhE3KKTk4H iM6g860luYdiiDyy3eH30tB1wn18KmeQ46eKPACnS21GW1Wg301aELb998MorbG1Pleh 4Lt9R1gO5Js46IlrtsqsxUV4WMTVPjOYumYaEMOZhD8b741HSJ0XYU93FnkkE+RbsDGM d0HQ==; 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=1786358169; x=1786962969; 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=RRXBOmNTjqqbZfMqBxAqGdktvRSBv7clJPxaQTp9Dfc=; b=BVzGHIUxa5a63W1iWjxG+uy6sgzL3/oUwvWdMI5nsaTiMnU4tggnsGOTaCxYdtRhk6 3/M8HCn2erbYzmtE/gAkXnOUiotuOfHxgnZEBa3nA0/VwXRD9diR/L3a2YWWqfqJvewq AxgiFuXOrzea+00CB5GJX2iBysUPLA46PmwYrbZAotVEJuKfuInNWL9z/TY0TKgj0DAa Q8iq5K5KssHhs4Uzut1Qtbh0UaGDliUvA2H7Fw7lFiqK44wAgdLLDbFAzGIaSqEhL3JD VnFBpX4NnQvaLcj+/obZZi2nTJyGPpys8hvEbxeu9HsK/QR9heWrXaN93MiOq37X2iVA F40Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786358169; x=1786962969; 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=RRXBOmNTjqqbZfMqBxAqGdktvRSBv7clJPxaQTp9Dfc=; b=eqVIQfOfvcxA+n/xPUhXHHqYEP2/A8RmD5v+utKPcQfYgiKzwtTT6rdNY4CXcQJAIT mADTQoAy2CRE2wUCHBxFqwvr4P6plmiBS0izv1O0H2TZK/J1+8nSEhgSnvaugIcnrQ4S MyIh/+Deh4RU7ukLnq/fFfTefFWBjNiKba9L3MQlzRDf/x0sxvbLjIzbXDC2iUfAxBj5 KDdkV1Riyo0aZxUxiwbo24HbSwS9V/82z7g1suHDf6J6HeiMYZaS3O1fr2KzLX5aH1yE ZYxarxjsB6ukDuVXU4ZRhGh55/469HyZuVtbM2LCGLzMJDfea6srIEf1JPs+x+S30x8m Havg== X-Forwarded-Encrypted: i=1; AHgh+RojUlFUnBW+oL9ofIj5UwL3I02HlaNABEkTR9ksIUM63NdLc/PvJ8dW4FOmuYOwoGothJEt@ietf.org X-Gm-Message-State: AOJu0Yyeyg0N527qukP7hcUFWk0czikzkLA4XxPyNNTg1hrSdse82m/y UDQTNBftApqp5//lx+OlKoFaL1+3cSJlTghxxt1w8QwiNLci7zZtkevbAj5gKxssPcpq4cA7OND MuJOhycFC7zM83iFe1G4yJ5ilUSeWReQ= X-Gm-Gg: AR+sD13/qnIJkYbExYB9kUVnyFdSiFBRYakGpVgu8Z7n8QUHODkJvhPL0vNNyUOHr2R LFNgZWlA4y3eG58QGDtZUS7Og7mmeH3UkjVIhlA+xpRkApGMD3bgzT2JVflTm3YzRB4+mdvENK8 RF4G3ER+USuo/HhLvdPvMPmMt3rCRI/wPNK3a04EX1UkMrOam4aSQe0y0+Bjv14cJUjeISUu5kx uROZa+FNJhauSpU9dT1OUXPbgD+EZbJPmJgBkmCaSTNvBnxIzvrOeMJ0HLJ58B6e/te6SnYSWGR 0rvUI6/rpfm4k0+9N4aG4NGSk9U9+r/1Q3Bz5HBDPzI= X-Received: by 2002:a05:6808:4f53:b0:486:8a11:6e8b with SMTP id 5614622812f47-4b1e75eb9ffmr320509b6e.2.1786358168859; Mon, 10 Aug 2026 03:36:08 -0700 (PDT) MIME-Version: 1.0 References: <178592625332.1174.15715227575457159982@dt-datatracker-54dc84885d-8d5gh> In-Reply-To: From: Song Haowen Date: Mon, 10 Aug 2026 18:35:55 +0800 X-Gm-Features: AUfX_mxyuVObGeW17TJ_Y0nlivvVwRdqyAvpzJeMejP5PmlgvsyFu8yKIFx9Eg8 Message-ID: To: tirumal reddy Content-Type: multipart/alternative; boundary="00000000000018b8340658aeece4" Message-ID-Hash: LWVP5NZKBWBNUWL2KB7EGRLONOEXUV5L X-Message-ID-Hash: LWVP5NZKBWBNUWL2KB7EGRLONOEXUV5L 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: Songbo Bu , Ionut Mihalcea , 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: --00000000000018b8340658aeece4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Without any stated assumptions, system model and threat model, Tiru's statement is provably false. The real problem is in considering server as honest, whereas in attestation, it is not. There is an attesting environment which is trusted but there is target environment which is untrusted. That is the whole point of attestation. Please read RFC 9334 to understand this fundamental difference. Applying standard TLS 1.3 threat model to attested TLS simply does not work. That's also why I appreciate Usama et al.'s careful work in formalising all of this. Tiru's statement about never discussed by the WG is also incorrect. For example: https://datatracker.ietf.org/meeting/125/materials/slides-125-seat-security= -analysis-00 As intra-handshake.fail paper says, what we need is a connection-bound secret for fully authenticated server in the evidence. ClientHello...ServerHello transcript is publicly available to the attacker. I agree with others that CVE-2026-33697 applies directly to this draft version. Regarding demonstrating relay for this draft, it is very simple (a million thanks to Usama et al. for flexible artifacts). Substituting rdata =3D (log_SH,pubEK) in https://github.com/muhammad-usama-sardar/intra-handshake.fail/blob/819bb7f2= 0ac458b27c9be2c91cce1e72b8b5f4f7/aggregate/tls-lib-simple.pvl#L692 and https://github.com/muhammad-usama-sardar/intra-handshake.fail/blob/819bb7f2= 0ac458b27c9be2c91cce1e72b8b5f4f7/aggregate/tls-lib-simple.pvl#L795 in accordance with section 5.1.1. of this draft proves that the property G3 fails. Hence, CVE-2026-33697 applies to this draft. I am thunderstruck by Tiru's ask for "clearly stating the attacker capabilities" for something which has been clearly stated to the extent of being formally specified in https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-= 2026-33697_High-severity_CVE_in_Attested_TLS and https://doi.org/10.1145/3779208.3785387. Maybe a good starting point for him is to state what is unclear in the threat models and formalisation of these papers, or what precisely is his disagreement. As I said before, ignoring several years of work which is peer-reviewed at top security conferences and acknowledged by all vendors and instead starting from scratch is wastage of WG time. Do we want to develop a protocol which is exploited in the wild like CVE-2026-33697? Thanks Haowen Song tirumal reddy =E4=BA=8E2026=E5=B9=B48=E6=9C=8810=E6=97= =A5=E5=91=A8=E4=B8=80 16:06=E5=86=99=E9=81=93=EF=BC=9A > Hi Songbo, > > You haven't addressed my core point: *two TLS connections cannot share > the same ClientHello...ServerHello transcript.* Without showing how an > attacker can force an honest peer to repeat its random and ephemeral key > shares, relaying Evidence bound to a transcript isn't possible. > > Regarding the papers you referenced: > > - > > *WG Consensus Needed:* The threat vectors and adversary models from > these papers were never discussed or agreed upon by the WG. > - > > *State the Model Directly:* Rather than pointing to external papers, > please state the specific attacker capabilities you want the WG to > consider. The WG needs to evaluate whether this adversary model is in = scope > before we assess any solutions against it. > > Let's focus the thread on these two points: > > 1. > > Demonstrating how transcript collision/relay is possible in your model= . > 2. > > Clearly stating the attacker capabilities for the WG to evaluate. > > -Tiru > > On Mon, 10 Aug 2026 at 13:09, Songbo Bu wrote: > >> Tiru, >> >> Thank you. >> >> I agree with the threat model explained in section 6.1 of >> intra-handshake.fail ( >> https://www.researchgate.net/publication/408219182_Intra-handshakefail_C= VE-2026-33697_High-severity_CVE_in_Attested_TLS) >> and in more detail in section 4 of ID-Crisis ( >> https://doi.org/10.1145/3779208.3785387). So I am not sure what's the >> point in repeating it here. Do you disagree with that threat model? If y= es, >> what narrowly? >> >> Breaking the single server is explained in Section 9 of ID-Crisis. Do yo= u >> disagree with that? If yes, what narrowly? >> >> On identity: I asked identity and proof-of-possession of the key of the >> *cloud provider*, not the one with TEE. This too is demonstrated in >> ID-Crisis. >> >> Best, >> Songbo >> >> >> tirumal reddy =E4=BA=8E2026=E5=B9=B48=E6=9C=8810=E6= =97=A5=E5=91=A8=E4=B8=80 12:53=E5=86=99=E9=81=93=EF=BC=9A >> >>> Hi Songbo, >>> >>> It is not possible for two TLS connections to share the same >>> ClientHello...ServerHello transcript. Each peer contributes a fresh ran= dom >>> and a fresh ephemeral key share per connection, so the transcript is >>> jointly determined by both peers. This holds even when one peer is the >>> adversary: it cannot force the honest peer's independent per-connection >>> random and key share to repeat. The transcript of one connection theref= ore >>> cannot be reproduced in another, so Evidence bound to it cannot be rela= yed. >>> >>> If you disagree, please demonstrate how two TLS connections can have >>> the same ClientHello...ServerHello transcript. >>> >>> On identity: Section 5.1.1 binds the hash of the attester's TLS identit= y >>> key (i.e., the public key of the attester's end-entity certificate used= for >>> authentication), and proof of possession of that key is provided by >>> CertificateVerify in the same handshake. >>> >>> Please also explain *how compromising a single server breaks security >>> for connections to other servers*. >>> >>> You may want to state the attacker capabilities directly rather than by >>> reference to the paper, since the threat model is what is under discuss= ion. >>> I would like the WG to discuss this attack and decide which adversary m= odel >>> is in scope, so that it can be added to the use-cases draft as you prop= osed >>> in the other thread, and each solution can then be assessed against the >>> agreed attack model. >>> >>> Best Regards, >>> -Tiru >>> On Sat, 8 Aug 2026 at 19:21, Songbo Bu wrote: >>> >>>> tirumal reddy =E4=BA=8E2026=E5=B9=B48=E6=9C=887=E6= =97=A5=E5=91=A8=E4=BA=94 18:29=E5=86=99=E9=81=93=EF=BC=9A >>>> >>>>> The attestation binder in Section 5.1.1 binds the Evidence to the >>>>> ClientHello...ServerHello transcript, which commits to both peers' >>>>> ephemeral key shares. The binder additionally incorporates the hash o= f the >>>>> attester's TLS identity key (the public key of the attester's end-ent= ity >>>>> certificate used for authentication). The binding is therefore speci= fic to >>>>> the two endpoints of the TLS connection in which the Evidence was pro= duced. >>>>> >>>> Hi Tiru, >>>> >>>> It is important to understand that: >>>> partial transcript binding =E2=89=A0 channel-secret binding >>>> There is no secret in ClientHello...ServerHello transcript, and can >>>> simply be relayed over by the target environment, analogous to the one >>>> shown in intra-handshake.fail paper. >>>> >>>> Also, for example, it does not bind to is the identity and >>>> proof-of-possession of the key of the cloud provider. So we do not kno= w >>>> which server it is and hence, it breaks if a single server in the whol= e >>>> world breaks, as shown in the ID-Crisis paper. >>>> >>>> Best, >>>> Songbo >>>> >>> _______________________________________________ > Seat mailing list -- seat@ietf.org > To unsubscribe send an email to seat-leave@ietf.org > --00000000000018b8340658aeece4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear all,

Without any stated assumptions, system model and thr= eat model, Tiru's statement is=C2=A0provably false. The real problem is in = considering server as honest, whereas in attestation, it is not. There is a= n attesting environment which is trusted but there is target environment wh= ich is untrusted. That is the whole point of attestation. Please read RFC 9= 334 to understand this fundamental difference. Applying standard TLS 1.3 th= reat model to attested TLS simply does not work. That's also why I appr= eciate Usama et al.'s careful work in formalising all of this.

Tiru&= #39;s statement about never discussed by the WG is also incorrect. For exam= ple:=C2=A0https://datatracker.ietf= .org/meeting/125/materials/slides-125-seat-security-analysis-00<= /p>

As= intra-handshake.fail paper says, what we need is a connection-bound secret= for fully authenticated server in the evidence. ClientHello...ServerHello = transcript is publicly available to the attacker. I agree with others that = CVE-2026-33697 applies directly to this draft version.

= Regarding demo= nstrating relay for this draft, it is very simple (a million thanks to Usam= a et al. for flexible artifacts). Substituting=C2=A0rdata =3D= (log_SH,pubEK)=C2=A0in=C2=A0https://github.com/muhamm= ad-usama-sardar/intra-handshake.fail/blob/819bb7f20ac458b27c9be2c91cce1e72b= 8b5f4f7/aggregate/tls-lib-simple.pvl#L692=C2=A0and=C2=A0ht= tps://github.com/muhammad-usama-sardar/intra-handshake.fail/blob/819bb7f20a= c458b27c9be2c91cce1e72b8b5f4f7/aggregate/tls-lib-simple.pvl#L795= =C2=A0in accor= dance with section 5.1.1. of this draft proves that the property G3 fails. = Hence, CVE-2026-33697 applies to this draft.

I am thunderstruck by Tir= u's ask for "clearly stating the attacker capabilities" for s= omething which has been clearly stated to the extent of being formally spec= ified in=C2=A0https://www.researchgate.net/publication/408219182_Intra-handsh= akefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS=C2=A0and=C2=A0= = https://doi.or= g/10.1145/3779208.3785387. Maybe a good starting point for him is to state wha= t is unclear in the threat models and formalisation of these papers, or wha= t precisely is his disagreement. As I said before, ignoring several years o= f work which is peer-reviewed at top security conferences and acknowledged = by all vendors and instead starting from scratch is wastage of WG time.

= Do we want to develop a protocol which is exploited in the wild like CVE-20= 26-33697?

Thanks

Haowen Song


tirumal = reddy <kondtir@gmail.com> = =E4=BA=8E2026=E5=B9=B48=E6=9C=8810=E6=97=A5=E5=91=A8=E4=B8=80 16:06=E5=86= =99=E9=81=93=EF=BC=9A

Hi Songbo,

You haven't= addressed my core point: two TLS connections cannot share the same Clie= ntHello...ServerHello transcript. Without showing how an attacker can f= orce an honest peer to repeat its random and ephemeral key shares, relaying= Evidence bound to a transcript isn't possible.

Regarding the pap= ers you referenced:

  • WG Consensus Needed: The threat ve= ctors and adversary models from these papers were never discussed or agreed= upon by the WG.

  • S= tate the Model Directly: R= ather than pointing to external papers, please state the specific attacker = capabilities you want the WG to consider. The WG needs to evaluate whether = this adversary model is in scope before we assess any solutions against it.=

Let's focus the thread on these two points:

=

  1. Demonstrating how transcript collision/relay is poss= ible in your model.

  2. Clearly stating the attacker capabilities for the WG to evaluate.

-Tiru


On Mon, 10 Aug 2026 at 13:09, Songbo Bu <bluedognull@gmail.com> wrote:
Tiru= ,

Thank you.

I agree with the threat model explained in sect= ion 6.1 of intra-handshake.fail (https://www.researchgate.net/publication/4= 08219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_T= LS) and in more detail in section 4 of ID-Crisis (https://doi.org/10.1145/37= 79208.3785387). So I am not sure what's the point in repeating it h= ere. Do you disagree with that threat model? If yes, what narrowly?

= Breaking the single server is explained in Section 9 of ID-Crisis. Do you d= isagree with that? If yes, what narrowly?

On identity: I asked ident= ity and proof-of-possession of the key of the *cloud provider*, not the one= with TEE. This too is demonstrated in ID-Crisis.

Best,
Songbo

tirumal reddy <kondtir@gmail.com> =E4=BA=8E2026=E5=B9=B48=E6=9C=8810=E6=97=A5=E5= =91=A8=E4=B8=80 12:53=E5=86=99=E9=81=93=EF=BC=9A

Hi Songbo,

It is not p= ossible for two TLS connections to share the same ClientHello...ServerHello= transcript. Each peer contributes a fresh random and a fresh ephemeral key= share per connection, so the transcript is jointly determined by both peer= s. This holds even when one peer is the adversary: it cannot force the hone= st peer's independent per-connection random and key share to repeat. Th= e transcript of one connection therefore cannot be reproduced in another, s= o Evidence bound to it cannot be relayed.=C2=A0

If = you disagree, please demonstrate how two TLS conn= ections can have the same=C2=A0 ClientHello...ServerHello=C2=A0transcript.

<= span style=3D"background-color:transparent">On identity: Section 5.1.1 bind= s the hash of the attester's TLS identity key (i.e., the public key of = the attester's end-entity certificate used for authentication), and pro= of of possession of that key is provided by CertificateVerify in the same h= andshake.

Please also explain how compromising = a single server breaks security for connections to other servers.=C2=A0=

You may wan= t to state the attacker capabilities directly rather than by reference to t= he paper, since the threat model is what is under discussion. I would like = the WG to discuss this attack and decide which adversary model is in scope,= so that it can be added to the use-cases draft as you proposed in the othe= r thread, and each=C2=A0solution can then be assessed against the agreed attack model.

<= p dir=3D"ltr">

Best Regards,
-Tiru

On Sat, 8 Aug 2026 at 19:21, Songbo Bu <bluedognull@gmail.com> wrote:
t= irumal reddy <kon= dtir@gmail.com> =E4=BA=8E2026=E5=B9=B48=E6=9C=887=E6=97=A5=E5=91=A8= =E4=BA=94 18:29=E5=86=99=E9=81=93=EF=BC=9A

The attestation binder in Section 5.1.1 binds the E= vidence to the ClientHello...ServerHello transcript, which commits to both = peers' ephemeral key shares. The binder additionally incorporates the h= ash of the attester's TLS identity key (the public key of the attester&= #39;s end-entity certificate used for authentication).=C2=A0 The binding is= therefore specific to the two endpoints of the TLS connection in which the= Evidence was produced.

Hi Tiru,

It is important to understand that:
partial transcript binding =E2=89=A0 channel-secret binding
There is no secret in ClientHello...ServerHello transcri= pt, and can simply be relayed over by the target environment, analogous to = the one shown in intra-handshake.fail paper.

Also, for example, it d= oes not bind to is the identity and proof-of-possession of the key of the c= loud provider. So we do not know which server it is and hence, it breaks if= a single server in the whole world breaks, as shown in the ID-Crisis paper= .

Best,
Songbo
_______________________________________________
Seat mailing list -- sea= t@ietf.org
To unsubscribe send an email to seat-leave@ietf.org
--00000000000018b8340658aeece4--