[Seat] Re: Fwd: New Version Notification for draft-usama-seat-intra-vs-post-00.txt

[Markus Rudy <[e-mail]>]

Hi Usama,

Contrast is the main product that should be named. Constellation was using the same protocol, but the project is archived since 2026. Funnily enough, I just learned that our earlier SGX-based products did post-handshake attestation.

I don't know whether our patterns justify a new use case, but since you asked: A Contrast system has three types of participants - User, Coordinator, Workload. The latter two types run in TEEs, with the following communication flows (numbered for reference, not for temporal ordering):

1. The user creates an aTLS channel to the Coordinator, and if it passes all checks the user configures it with root key material. The Coordinator creates an internal CA for workloads. Only the Coordinator attests. This happens infrequently.
2. Workloads create aTLS channels to the Coordinator and send a CSR. If the Coordinator is satisfied with the workload's attestation, it signs a certificate for the workload. Together with the CA certificate, workloads can now communicate with standard mTLS using these certificates (no more attestation involved). This happens frequently (with Kubernetes pod starts/restarts). While the CSR could be signed without an attested TLS channel, it's easier for the workload to trust the response this way. Furthermore, some workloads also obtain a persistent secret seed over this channel, which they can use to derive durable key material themselves (e.g. volume decryption key).
3. Coordinators contact other Coordinators to obtain the root key material for themselves. Both sides need to attest to ensure trustworthiness. This happens infrequently.

I did a quick experiment in our testing lab, running on the same machine as the Coordinator:

1. TCP connections are local, and thus the TCP connection establishment unsurprisingly takes only 0.5ms. But even to neighbouring nodes in the same cluster, the TCP handshake takes below 2ms.
2. I measured generation of evidence including the TLS session establishment, but with these numbers I don't think it makes a lot of difference:
   - SNP: Median time of 140ms from TCP SYN to TLS channel established and evidence sent to the client.
   - TDX: Median time of 1020ms, same procedure. I don't know why it is that slow, it should only be making machine-local remote calls, if any.
3. So far, I only managed to measure TDX verification, which adds another 340ms. This is bound by remote HTTP requests, afaiu, and could be optimized with locally cached collateral, CRL, etc. I'd expect SNP to exhibit similar timing, because verification does similar remote calls.

Cheers, Markus
________________________________________
From: Muhammad Usama Sardar
Sent: Friday, January 16, 2026 7:34 PM
To: Markus Rudy
Cc: [e-mail]
Subject: Re: [Seat] Fwd: New Version Notification for draft-usama-seat-intra-vs-post-00.txt


Hi Markus,
Thanks very much for sharing your insights. I believe these are all very good and practical points. Unless someone objects with valid reasons, I will add them in the next version adding your name in the contributors.
Please see a few notes inline:
On 16.01.26 14:41, Markus Rudy wrote:
Edgeless Systems has been using intra-handshake attested TLS in production since 2022, in at least two distinct confidential computing software products.
>From your presentation at CCC Attestation SIG, I am aware of Contrast. Would you mind sharing other Edgeless Systems products using attested TLS? I would like to mention them in "scope" in the editor's draft [0] for next version.
 From the [use-cases], we align mostly with *3.2. Secure Provisioning*: automatic dissemination of configuration and secrets between mutually attesting TEEs.
As author of [use-cases] draft: Please feel free to share your use case more precisely or propose edits. -00 was just a starting point. I would very much like to hear from the community how they are actually using it in production. So your input is crucial here. If you feel you have other use cases, I welcome those use cases too. Please share a short paragraph or two explaining the use in particular:
Whether server is Attester or client is Attester (there may be mutual too, but we are trying to identify which is the main party being attested)
What kind of secret is sent after successful attestation?
What does the Attester do after getting the secret?
An updated version with more use cases is at [1].
4. I don't think saving extra roundtrips is an appropriate design goal when attestation is required. Generating evidence alone takes much longer than normal network roundtrip times, not even speaking of verification.
It was one of the key points raised by the proponents of intra-handshake attestation. So in an attempt to be unbiased, I just put it in the draft for WG discussion.
If you could please provide some numbers from your production, it will be great as an independent data point. For example, given a specific TEE (e.g., AMD SEV-SNP, Intel TDX or Intel SGX) and a specific scenario:
Typical time for generation of evidence
Typical time for appraisal of evidence
Typical network time from Client to Server and back to Client (without any operation in between)
B. It should be possible to port the general shape of a post-handshake attested TLS protocol to other protocols that provide secure channels and session binding (Noise comes to mind).
I see a lot of value in what you are proposing. Design, verification and audit effort will be one-time and any protocol (not just Noise) which has support for exporters can then use it without changing each and every protocol. This requirement was also mentioned at Linux Plumbers Conference 2025.
-Usama
[0] https://muhammad-usama-sardar.github.io/seat-intra-vs-post/feedback/draft-usama-seat-intra-vs-post.html
[1] https://tls-attestation.github.io/use-cases-and-properties/draft-mihalcea-seat-use-cases.html#section-3