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

[Song Haowen <[e-mail]>]

Dear all,

Sophie is a highly respectable cryptographer and I ask that Sophie's input
be taken seriously. WG needs to reason based on "a lot less elegant and
harder to reason" and "binding be directly derived from the shared secret".
The latter is also the finding from intra-handshake.fail paper defining
three levels.

One of the requirements we have for our deployment is that security
vulnerabilities of critical severity be resolved. If vulnerabilities are
not resolved, nobody will use our protocol.

Best,

Haowen Song

Songbo Bu <[e-mail]> 于2026年8月13日周四 12:23写道：

> Nathanael,
>
> Thank you for the answers. They are very helpful.
>
> I have a few more narrow clarifying questions.
>
> I don't think any confidential computing hardware Root of Trust does
> attestation signature. We use Intel TDX. Signature is done by the software
> TD QE. Are you aware of any solution that really uses hardware Root of
> Trust for signatures? I expect that would kill paralleism, making it
> impractical.
>
> Thanks for the narrow correction. Is it to say that attested TLS is only
> useful with PKI?
>
> I don't think it's about the complexity earlier or later. The complexity
> later is necessary for re-attestation. The *additional* complexity earlier
> is questionable. We have already discussed it.
>
> How do you establish trust with "The Verifier"?
>
> By TCB, I meant to ask: is it possible to have WebPKI identity without
> trust in CSP?
>
> Can you narrowly clarify why you say "or otherwise". I think both are
> required. If it is not in Evidence, how can you check?
>
>
> Best,
> Songbo
>
> Muhammad Usama Sardar <[e-mail]> 于2026年8月13日周四
> 09:01写道：
>
>> Hi all,
>>
>> Based on off-list feedback, I realized that my initial email,
>> specifically the mentioned papers and discussion points were focused on
>> Confidential Computing. I agree non-Confidential Computing is also
>> important and feedback on that part is welcome, too. My request of focusing
>> this thread was just that we understand what we are talking about and not
>> to mix too many topics. This discussion is going good and I am happy with
>> it. We are making more constructive progress than I expected. Thanks
>> everyone!
>> On 13.08.26 00:53, Sophie Schmieg wrote:
>>
>> You definitely get very different requirements with just minor subtle
>> changes in the threat model in these scenarios, so it is definitely
>> important to nail this down and ensure everybody agrees what is talked
>> about.
>>
>> This is very useful guidance and the constructive way forward to avoid
>> conflicts and talking past each other. To do this, I plan to write a draft
>> on the different threat models I have in mind. As a starting point, we can
>> try to make high-level categories, such as:
>>
>>    1. Confidential Computing threat model
>>    2. Non-Confidential Computing threat model
>>
>> and maybe further subcategories and then slowly put details in, as the
>> discussion proceeds. As a starter, WG may also consider some discussion
>> points for the threat model:
>>
>>    1. How do people currently deploy it?
>>    2. Where is Attestation Key (AK) stored?
>>    3. Where is Long-Term Key (LTK) of the cloud infrastructure provider
>>    stored?
>>    4. Where are TLS keys stored?
>>    5. Which software in the system has access to the keys?
>>    6. How is the key provisioned?
>>    7. What is the life cycle of the keys?
>>    8. What is the policy around the keys?
>>    9. What else may go wrong?
>>
>> Does someone have something to share on these lines?
>>
>> ===
>>
>> Hi Nathanael,
>>
>> Thanks for the correction. I meant secrecy (confidentiality) rather than
>> entropy in my last email. Apologies!
>>
>> I think walking to the physical hardware is practically not feasible in
>> many possible use cases that I can think of. But at the same time, if you
>> check it remotely, you can have diversion attacks again [0] from the
>> security advisory [1]. We are in a very complicated situation. Is someone
>> aware of any other workarounds? How are other implementers doing it?
>>
>> Best,
>>
>> -Usama
>>
>> [0]
>> https://docs.edgeless.systems/contrast/1.16/architecture/components/manifest#referencevaluestdxallowedpiids
>>
>> [1]
>> 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]
>