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

[Songbo Bu <[e-mail]>]

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


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