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

[Songbo Bu <[e-mail]>]

Nathanael,
Thank you. I have a narrow clarifying question.

I use Intel TDX in a public cloud provider infrastructure. Where can I get
values of PIIDs of the cloud provider machines to put in that field that
Edgeless has defined? To my knowledge they are not available, and hence
Chengxin is right.

Best,
Songbo

Nathanael Ritz <[e-mail]> 于2026年8月14日周五 18:01写道：

> On Fri, 14 Aug 2026 at 02:52, Chengxin Huang <[e-mail]>
> wrote:
>
>> 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? <SNIP>
>>
>> Please clarify what is misinformed in my reading of the security advisory
>> above.
>>
>> Best regards,
>>
>> Chengxin Huang
>>
>
> The statement was "My understanding [...] is [...] there is no way to
> check at the verifier side." If this were true, then Edgeless would not
> offer extensive documentation at explaining in great detail to configure
> their verifier/rp client to appraise an attester's Evidence in such a way
> to achieve exactly [that check].
>
> For more information, see the RATS Architecture RFC9334 Sec. 8 on
> Appraisal Policies for how this applies to threat model for far more
> diverse than just this one very specific example [1].
>
> Cheers,
> Nathanael
>
> [0]
> https://docs.edgeless.systems/contrast/1.16/architecture/components/manifest#referencevaluessnpallowedchipids
>
> [1] https://www.rfc-editor.org/rfc/rfc9334.html#name-appraisal-policies
>
>
>> [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]
>>>
>> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>