[Seat] Re: Updated Attacker Model in SEAT Use Cases Draft

[Chengxin Huang <[e-mail]>]

Hello Jakub,

You may be missing the point many SEATers are trying to clarify. The
extracted key is not of the desired server. It is of another "basement"
machine. "The Verifier" cannot distinguish the two.

Kindly read [ID-Crisis] paper and see the formal analysis
[ID-Crisis-ProVerif]. Also please check out [Edgelesssys] advisory. In my
understanding, what makes CVE-2026-33697 go in the wild is the combination
of the this paper with [intra-handshake.fail].

I kindly ask that we follow the [advice] of Dr. Schmeig and positively move
on to threat model.

Best regards,

Chengxin Huang

[ID-Crisis]
https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS
[ID-Crisis-ProVerif]:
https://github.com/CCC-Attestation/formal-spec-id-crisis
[Edgelesssys]
https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h
[intra-handshake.fail]
https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS
[advice]
https://mailarchive.ietf.org/arch/msg/seat/t8aobzB374lWiLzrVrORY7kGYyQ/

On Wed, Aug 19, 2026 at 2:33 PM Katapulta Pultalowska <
[e-mail]> wrote:

> Hi all,
>
> I agree with Nathanael. To me, the description of the attack in [0] is
> incomplete and lacks several important details.
>
> The author says:
>
> "Executable PoC Environment: The attack was simulated in an isolated
> Docker Compose infrastructure utilizing a vulnerable version of the CoCoS
> library (v0.8.2).
>
> Successful MitM: The PoC demonstrates that an attacker proxy can relay a
> ClientHello, forward valid Evidence, and complete the handshake by signing
> the CertificateVerify message using a compromised ephemeral private key
> (privEK)."
>
> However, if you look at the source code of CoCoS v0.8.2, the ephemeral
> private key is generated inside the GetCertificate() function in
> pkg/atls/certificate_provider.go using ecdsa.GenerateKey(elliptic.P256(),
> rand.Reader). The generated private key is then kept in the tls.Certificate
> structure and used for the TLS handshake. [1]
>
> This raises an important question about the PoC: how was the ephemeral
> private key obtained?
>
> The key exists in the memory of the CoCoS process running inside the CVM.
> The author does not provide any details about how this key was extracted or
> otherwise obtained. This is a critical part of the attack scenario, because
> possession of the ephemeral private key is the prerequisite for performing
> the relay attack.
>
> The CVE description itself mentions several possible mechanisms for
> obtaining such a key, including physical access, transient-execution
> attacks, and side-channel attacks. Therefore, I do not think physical
> access should be considered a strict requirement. Nevertheless, the PoC
> should explain which key-extraction mechanism is assumed and how it is
> implemented.
>
> There is also an important practical question concerning timing. The
> private key is generated in response to the ClientHello, so the PoC should
> explain how the attacker obtains the particular ephemeral key corresponding
> to the attestation Evidence while still completing the TLS handshake. In
> particular, it would be useful to know whether the key is extracted during
> the handshake, extracted beforehand, or made available to the attacker
> through some other mechanism.
>
> Without this information, the PoC demonstrates that the relay attack works
> given possession of the ephemeral private key, but it does not demonstrate
> how an attacker obtains that key in a real CoCoS deployment.
>
> For this reason, I think the description should explicitly document the
> key-extraction step and the assumptions made about the attacker.
>
> One more thing.
>
> I have noticed that on the mailing list it has been stated several times
> that the CVE is "widely exploited", apparently because several press
> articles mention the CVE.
>
> However, multiple press articles do not by themselves constitute evidence
> of exploitation, particularly when the articles cross-reference each other
> and ultimately point back to the same CVE entry or security advisory. They
> therefore do not provide independent evidence that the vulnerability has
> been exploited in real-world attacks.
>
> What would be much more valuable would be an independent technical
> analysis of the attack, preferably by researchers specializing in
> cryptographic protocols or confidential computing, including a detailed
> description of the practical attack assumptions and the key-extraction
> mechanism.
>
> Best regards,
> Jakub Maria Plutowski
>
> [0]
> https://mailarchive.ietf.org/arch/msg/seat/P_CYTycg0KG7cbKauFA-kVgX2jo/
> [1]
> https://github.com/ultravioletrs/cocos/blob/v0.8.2/pkg/atls/certificate_provider.go
>
>
>
>
> On Wed, Aug 19, 2026 at 4:29 AM Nathanael Ritz <[e-mail]>
> wrote:
>
>> On Tue, Aug 18, 2026 at 7:28 PM Songbo Bu <[e-mail]> wrote:
>>
>>> Nathanael,
>>>
>>> Thank you. I want to provide a concrete proof. Davyd Okaianchenko has
>>> developed the "concrete, runnable Proof of Concept (PoC) for the attack"
>>> for CVE-2026-33697:
>>> https://mailarchive.ietf.org/arch/msg/seat/P_CYTycg0KG7cbKauFA-kVgX2jo/.
>>> I think it is not at all difficult to develop.
>>>
>>> Several news in China have confirmed exploit in the wild.
>>>
>>> Best,
>>> Songbo
>>>
>>
>> First, the CVE description itself states that “exploitation requires the
>> attacker to first extract the ephemeral TLS private key, which is possible
>> through physical access to the server hardware, transient execution
>> attacks, or side-channel attacks.”
>>
>> Second, the CVSS 3.1 vector indicates both “AV:L”, indicating the attack
>> vector is local and “AC:H”, which indicates attack complexity is high.
>>
>> Third, it’s worth noting that the CVSS measures severity, not risk [*].
>> And finally, again from the CVE description, it states clearly what the
>> problem actual was: “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.”
>>
>> So, based on that, we should not expect a software demonstration of the
>> exploit to be hard to develop in a home lab. However, it appears it is another
>> thing altogether to actually succeed against a real CVM on real hardware.
>> In any case, all individual I-Ds proposed to the SEAT WG propose binders
>> that all tie directly to the per-session TLS channel already — complete
>> with available matching models that demonstrate their effectiveness against
>> the high severity impact that CVE-2026-33697 would represent under a
>> real-world hardware-based attack.
>>
>> Cheers,
>> Nathanael
>>
>> [*]
>>
>> https://www.first.org/cvss/user-guide#CVSS-Base-Score-CVSS-B-Measures-Severity-not-Risk
>>
>>
>>
>>>
>>>
>>> Nathanael Ritz <[e-mail]> 于2026年8月18日周二 23:53写道：
>>>
>>>> Hi, some comments inline with [NR]:
>>>>
>>>> On Tue, 18 Aug 2026 at 07:16, Chengxin Huang <[e-mail]>
>>>> wrote:
>>>>
>>>>> [SNIP] I agree with Songbo that CVE-2026-33697 must be added. I also
>>>>> suggest to add a pointer to [Edgeless] advisory in attacker model. Both are
>>>>> wildly exploited and I don't see how proposed text covers both.
>>>>>
>>>>
>>>> On Tue, Aug 18, 2026 at 4:09 PM Songbo Bu <[e-mail]>
>>>> wrote:
>>>>
>>>>> [...] On CVE-2026-33697: This is already exploited in the wild.
>>>>>>
>>>>>
>>>> [NR]: Despite repeated assersions of 'wild exploitation', SEAT recently
>>>> had another independent researcher stop by and specifically state that that
>>>> they "have not, however, been able to find a publicly available,
>>>> concrete exploitation trace or proof-of-concept demonstrating how the
>>>> attack
>>>> can be carried out against the actual CoCoS implementation." [0] My own
>>>> search has found a specific PoC for specific regressions related to new CVE
>>>> candidates including a post-TLS authenticator handshake example [1], but
>>>> such concrete tooling seems to appear in isolation. Finally, I think it's
>>>> also worth noting that NIST [2] appears to give CVE-2026-33697 an
>>>> exploitability score of 1.0 [3] and it appears Github suggests an
>>>> exploitability score of 1.1 for the same [4].
>>>>
>>>> On Tue, Aug 18, 2026 at 4:09 PM Songbo Bu <[e-mail]>
>>>> wrote:
>>>>
>>>>> Therefore, please make it explicit in the threat model. I don't think
>>>>>> "cross-connection replay" is a standard term in the literature. I think
>>>>>> CVE-2026-33697 is related to relay and not "cross-connection replay".
>>>>>> Therefore, as a first step, making it explicit in the draft is useful for
>>>>>> further discussion.
>>>>>>
>>>>>
>>>> [NR]: If we are uncertain if we think CVE-2026-33697 is related to
>>>> relay and not 'cross-connection replay' or not, I suggest such details get
>>>> narrowed down before being put into the draft. Based on the sources, I
>>>> believe we should consider the practical impact of "Key Exchange without
>>>> Entity Authentication" and "Origin Validation Error" from first principles.
>>>> This is not because these are new risks, but because they are well
>>>> established in prior literature and represent long-standing concerns for
>>>> secure transport protocols. The mailing list is the right place to continue
>>>> these discussions.
>>>>
>>>> On Tue, Aug 18, 2026 at 4:09 PM Songbo Bu <[e-mail]>
>>>> wrote:
>>>>
>>>>> [SNIP] On cross-connection replay handling: I think we can agree on
>>>>>> desired handling in this draft and solutions can then implement this.
>>>>>>
>>>>>>
>>>>>
>>>> tirumal reddy <[e-mail]> 于2026年8月18日周二 14:26写道：
>>>>
>>>>> On cross-connection replay: how a solution detects and handles it
>>>>> (abort or otherwise) is a separate discussion for the solution drafts, not
>>>>> this document.
>>>>>
>>>> [NR]: As such, I agree with Tiru on the direction with this.
>>>>
>>>> Cheers,
>>>> Nathanael
>>>>
>>>> [0]
>>>> https://mailarchive.ietf.org/arch/msg/seat/QD8QB1WVL-toNovGQ2Tk6DmmeEM/
>>>>
>>>>
>>>> [1] https://github.com/B1ueD0g/cocos-cve-regression-evidence
>>>>
>>>> [2] https://nvd.nist.gov/vuln/detail/CVE-2026-33697
>>>>
>>>> [3]
>>>> https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2026-33697&vector=AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N&version=3.1&source=NIST
>>>>
>>>> [4]
>>>> https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2026-33697&vector=AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N&version=3.1&source=GitHub,%20Inc
>>>> .
>>>>
>>>>
>>>> _______________________________________________
>>>> Seat mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>> Seat mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>