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

[Nathanael Ritz <[e-mail]>]

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
.