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

[Ayoub Benaissa <[e-mail]>]

On Fri, Jan 16, 2026 at 3:26 AM Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi Ayoub,
>
> On 15.01.26 16:59, Ayoub Benaissa wrote:
> > From a practical perspective, I think a post-handshake implementation
> > makes more sense. We have been building an Attested TLS protocol for a
> > web-based application, and we had to do a post-handshake
> > implementation. Intra-handshake requires too much change. For example,
> > you have to reimplement or customize how Nginx (or other) servers
> > speak TLS. This would take months and more to have a standard
> > implementation that is somehow safe to use. It's different in a
> > post-handshake implementation where you can have a full working
> > example in a matter of weeks.
>
> Could you possibly share more details?
>
> Also, we are collecting use cases of attested TLS [0]. Would you be
> willing to share your use case and co-author the use cases draft [0], as
> in write goal, use case and requirement? Thanks.
>
> -Usama
>
> [0]
>
> https://tls-attestation.github.io/use-cases-and-properties/draft-mihalcea-seat-use-cases.html#section-3
>
>
 I will gladly share our use case. How should I do that?

For what I said about post-handshake vs intra-handshake, I will try to
elaborate with a few points:
- TLS might not be well suited to include this in its protocol. Not sure
TEEs are even as mature for the people to see that it should be included
right now. The plan to make it a post-handshake protocol makes more sense
right now. A future where it's incorporated into TLS might exist, but I
don't think there is enough motivation right now.
- An intra-handshake requires much more work compared to a post-handshake.
People need to agree on how to add this as optional in TLS (we can't force
everyone to use it of course), the standard needs to be implemented by
major libraries, and then it will be available in major client/server
applications. If any of the prior steps doesn't go through, it means you
have to patch your components to make it work, which is not convenient /
less secure.
- We already implemented a post-handshake protocol and have a full demo
working. We were able to do this in a matter of weeks. That's because you
don't need to modify any TLS implementation, but only add a few
verification steps after the usual TLS handshake. This is almost the same
on the client and server side.
I also want to point out that the need for such a protocol is high. I can
talk about how LLMs are being served with TEEs, and everyone is doing the
attested TLS differently. A standard leading to a major and secure
implementation that can be used in browsers and so on would really benefit
the people.