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

[Sophie Schmieg <[e-mail]>]

The concrete threat model I had in that work was as follows:

There are machines and jobs, with jobs running on the machines. Machines
are somewhat semi trusted: If they are running the job (either client or
server) in question, they are trusted, otherwise they aren't.

The question explored was: Assume the jobs have a (low bandwidth) secure
channel established. The machines can negotiate a channel, without using
any PKI. What information do the jobs need to exchange on their channel to
ensure that no untrusted machine inserted itself in the middle. With a PKI,
this is a lot easier, as I can just separate trusted and untrusted
machines. Without a PKI, I need to ensure that whatever information I share
uniquely identifies any negotiated channel itself, in such a way that any
MitM becomes obvious. That is where the strong binding requirement comes
from. For example, in the case of RSA-OAEP, the MitM can just select the
shared secret for the second connection in any way they chose, not
incorporating any information from the other side, thereby coming up with
the same channel identifier. Nonces only partially help in this scenario,
as they can be repeated to the other connection. Public keys and transcript
hashes can fix this information as well, but lack any proof that the shared
secret is known.

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.

On Wed, Aug 12, 2026 at 11:22 AM Nathanael Ritz <[e-mail]>
wrote:

> Hi,
>
> Comments inline with [NR]:
>
> On Wed, 12 Aug 2026 at 04:54, Songbo Bu <[e-mail]> wrote:
> > [snip]
> > However, entropy in public values is not sufficient to prove
> channel-secret possession or same-endpoint control for attestation.
>
> [NR]: Yes, that's correct that entropy in public values is not sufficient
> alone.
>
> > A live relay can carry fresh, high-entropy public context.
>
> [NR]: Also true.
>
> > The critical security question is which authenticated cryptographic
> operation relates the attestation evidence, the exact TLS session, the
> attested component, and the component controlling the traffic keys.
>
> [NR]: Exactly. Nonces and transcript hashes are public parameters rather
> than secrets. However, when a given hardware Root of Trust collects a
> snapshot of the TLS 1.3 CH...SH transcript checkpoint inside the
> attestation quote, it creates a cryptographically unforgeable link to those
> specific ephemeral key shares without requiring secret-derived material.
>
> > Sophie mentioned about binding directly from shared secret. Nonces and
> transcript hash in the binder are not shared secrets.
>
> [NR]: To provide a "narrow" correction, Sophie mentioned that binding
> directly from the shared secret was required if the goal was to do it
> *without relying on a trusted third party* and went on to repeat the same
> idea: "If you rely on a trusted third party, and in particular a PKI, you
> have more options to introduce channel bindings."
>
> > In your key takeaway, you seem to miss Sophie's key point "a lot less
> elegant and harder to reason".
>
> [NR]: I don't think I did. Pretty sure I answered with "That's fair."
> without contesting the opinion. I then went on to explain to the room that
> attestation and the RATS ecosystem itself often involve a complex web of
> distributed TTPs already by default. Whether the complexity of remote
> attestation happens early inside the TLS handshake or later in the
> Authenticator's handshake, that complexity is already there. Early
> Attestion just... does attestation earlier.
>
> > Nathanael, could you narrowly clarify: for confidential computing, which
> trusted third party are you talking about?
>
> [NR]: It depends on the needs of the teams deploying and maintaining a
> RATS ecosystem, but in each one of Usama's own models for example, the
> Attestation Key (AK) is preconfigured by the co-located Verifier<->RP
> client to trust the signature of the AK out-of-band. Examples of what that
> abstraction can represent in the real world could be:
>
>    - The Silicon Manufacturer (providing the hardware Root of Trust and
> endorsement certificates)
>    - The Verifier (evaluating Evidence against appraisal policies to
> produce an Attestation Result)
>    - The Software Supply Chain (signing firmware, bootloaders, and
> workload components)
>    - Some or more than all of the above the above
>
> > and how would that be possible without including the cloud service
> provider (CSP) in the TCB?
>
> [NR]: Sure, the goal of Confidential Computing is to minimize trust in the
> CSP. If by "TCB" you mean the distributed web of trust configured for a
> RATS ecosystem, one option could be to walk up to the physical hardware you
> are leasing from your contractor and record the physical ChipIDs from the
> very machines you expect your workload to be deployed. Then you could add
> those known IDs to an allow-list that the RP would then expect to see
> present in Evidence or the Attestation Results or as otherwise configured
> within their appraisal policies (e.g. [0]). RATS architecture is not a
> monolith however, even in Confidential Computing. Therefore, others may
> have a completely different kind of threat model and therefore a different
> appraisal policy with different requirements.
>
> Cheers,
> Nathanael
>
> [0]
> https://docs.edgeless.systems/contrast/1.16/architecture/components/manifest#referencevaluessnpallowedchipids
>
> On Wed, 12 Aug 2026 at 04:54, Songbo Bu <[e-mail]> wrote:
>
>> Sophie, Nathanael, Usama, all,
>>
>> Thank you. Sophie's separation of trust on third party in the threat
>> model is very helpful and welcome input for the working group and in
>> particular use cases draft.
>>
>> I agree with Nathanael that public is not the same as zero entropy.
>> TLS randoms, ephemeral key shares, and transcript hashes can contain
>> or commit to unpredictable values even though they are public. I
>> therefore would not describe the early-attestation binder as having
>> zero entropy. On that narrow point, Nathanael's correction is valid.
>>
>> However, entropy in public values is not sufficient to prove
>> channel-secret possession or same-endpoint control for attestation. A
>> live relay can carry fresh, high-entropy public context. The critical
>> security question is which authenticated cryptographic operation
>> relates the attestation evidence, the exact TLS session, the attested
>> component, and the component controlling the traffic keys.
>>
>> Nathanael, I have a few comments and narrow clarifying question.
>>
>> Sophie mentioned about binding directly from shared secret. Nonces and
>> transcript hash in the binder are not shared secrets.
>>
>> In your key takeaway, you seem to miss Sophie's key point "a lot less
>> elegant and harder to reason".
>>
>> Nathanael, could you narrowly clarify: for confidential computing,
>> which trusted third party are you talking about? and how would that be
>> possible without including the cloud service provider (CSP) in the
>> TCB? This may be related to Usama's discussion questions 4,6,7 and 8
>> in the first post in this thread.
>>
>>
>> Best,
>> Songbo
>>
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]