[Seat] Re: Threat model and properties for attested TLS

[Chengxin Huang <[e-mail]>]

Dear Nathanael,

I don't think I am misinformed. I clarified to Paul that some identity
exists and this is not a barrier to his solution. Do you disagree?

To justify what I said, my perspective is the one of a user, not Edgeless.
Even from Edgeless perspective, I think it is a "workaround" and neither a
patch nor a solution. In the following, I explain the basis of my
understanding.

First, citing from the security advisory [Edgeless]: (emphasis mine)

"This vulnerability **can't** be patched in source code **alone**, since
the vulnerability arises from the confidential computing threat model
itself, see the background section for details. However, we introduced
patches in `v1.16.0` that allow working around the issue, see the
**workarounds** section next."

It reads to me that Edgeless probably cannot do it *alone* and it is only a
*workaround*.

Second, from [Edgeless]: (emphasis mine)

"AMD **does not document** the validation process for SEV-SNP reports, and
**nowhere in the specifications** do they explain that one should validate
physical security, or how. **Neither the `sev` crate nor the `go-sev-guest`
module offers APIs for that**. Intel published guidance after the 2025 wave
of physical attacks, in the form of Platform Ownership Endorsement,
nominating the Platform Instance ID as the ownership anchor. However, this
use of the PIID was not documented before, and suitable APIs for extracting
the PIID were neither in DCAP nor in `go-tdx-guest` until 2026. To the best
of our knowledge, the distribution channel for POE certificates is **still
undecided** and **no cloud provider currently offers it**."

It seems to me that a lot of information is still missing for Edgeless:
1. AMD APIs
2. Distribution channel for POE certs
3. As I mentioned in my previous email, no cloud provider offers it. How
can I, as a user, populate values for some cloud?

Third, the starting of the paragraph you cite from [Edgeless] says:
(emphasis mine)

"We decided to implement a simple **workaround** for the time being, using
the **limited information available**."

Therefore, my understanding from the above is that Edgeless has done a
"workaround" for now but they are probably lacking the above information
from the TEE and cloud providers for a complete solution.

Please clarify what is misinformed in my reading of the security advisory
above.

Best regards,

Chengxin Huang

[Edgeless]
https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h

On Fri, Aug 14, 2026 at 11:39 AM Nathanael Ritz <[e-mail]>
wrote:

> On Thu, 13 Aug 2026 at 21:14, Chengxin Huang <[e-mail]>
> wrote:
>
>> My understanding from the security advisory [Edgeless] is that while some
>> TEEs (Intel, AMD) have some form of identity (PIID, CHIP_ID), there is no
>> way to check at the verifier side.
>>
>> From a formal analysis standpoint, this means that a genuine machine in
>> the genuine datacenter and the compromised one in someone's basement are
>> indistinguishable, unless datacenter releases a list of all the machines
>> that it owns. In my understanding, cloud providers are probably not willing
>> to release that list.
>>
>
> This is misinformed. From [Edgeless]:
>
> "On TDX, users can set an explicit list of PIIDs in the manifest, *which
> will prevent reports from other TEEs to pass validation. *On SEV-SNP, we
> try to mirror that approach with an explicit list of HWIDs (chip_id),
> assuming that they are a suitable identifier for this purpose.* We highly
> recommend setting these fields to avoid relay attacks*, until more
> scalable solutions are available in practice."
>
> Emphasis mine.
>
> Cheers,
> Nathanael
>
> On Thu, 13 Aug 2026 at 21:14, Chengxin Huang <[e-mail]>
> wrote:
>
>> Dear Paul,
>>
>> My understanding from the security advisory [Edgeless] is that while some
>> TEEs (Intel, AMD) have some form of identity (PIID, CHIP_ID), there is no
>> way to check at the verifier side.
>>
>> From a formal analysis standpoint, this means that a genuine machine in
>> the genuine datacenter and the compromised one in someone's basement are
>> indistinguishable, unless datacenter releases a list of all the machines
>> that it owns. In my understanding, cloud providers are probably not willing
>> to release that list.
>>
>> Does this help you in your solution? If you can precisely state the value
>> of `rdata`, I will happily do the formal analysis for you.
>>
>> Best regards,
>>
>> Chengxin Huang
>>
>> [Edgeless]
>> https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h
>>
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>