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

[Nathanael Ritz <[e-mail]>]

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]
>>
>