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

[Markus Rudy <[e-mail]>]

Hi SEAT,

Edgeless Systems has been using intra-handshake attested TLS in production since 2022, in at least two distinct confidential computing software products. From the [use-cases], we align mostly with *3.2. Secure Provisioning*: automatic dissemination of configuration and secrets between mutually attesting TEEs. I'd like to share my experience and perspective on the debate around intra-handshake and post-handshake attestation.

The basics of [aTLS] are similar to [early-attestation] with only ephemeral keys, but since we needed (wanted) to work with existing TLS software, the messages are conveyed over different (potentially unrelated) extension points. We originally opted for an intra-handshake protocol to keep the attestation and verification parts out of the application logic, and to leave cryptographic heavy-lifting to the TLS stack. If we had known about [exporters] back then, we might have chosen a different approach.

I identified the following issues with our current implementation, which are partially reflected in [intra-vs-post]:

1. "Keeping attestation out of the application logic" is not as straightforward as it sounds. In the background-check model, the attester needs to collect evidence in response to the relying party's challenge (nonce). We were lucky that the Golang TLS stack can be supplied with arbitrary closures that are called during the handshake, but in my experience this is a rare design choice and may also be difficult to implement in other languages.

2. Conveying the evidence is not enough, it needs to be verified as well in order to end up with a trustworthy channel. We decided to integrate verification into the handshake, too, but that has massive drawbacks: Verification can take orders of magnitude longer than normal TLS handshakes, and usually involves remote calls, affecting all sorts of timeouts. However, doing the verification at the application level would require forwarding information from the handshake (e.g. nonce), at which point the application needs to be fully aware of the handshake protocol in order to verify it, breaking the intended layering.

3. There's only so much information in a TLS alert message, and it's definitely not enough to understand remote verification failures. While I understand this to be a deliberate design choice by TLS, I found this to be a hindrance for operating and debugging a large number of services in practice.

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.

All of the above leads me to a strong preference for a post-handshake protocol. In addition, I have justified hopes that a post-handshake protocol would also have the following benefits:

A. It's much easier to adopt an attestation protocol if it does not require TLS libraries to add support first! Established libraries are slow to change and may even be reluctant to implement all published extensions.
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).
C. (Formal) verification of a protocol and audit of its implementations might be much easier if it ran *on top of* TLS. Existing proofs and certifications would not need to be reevaluated.

Thanks for the consideration!

Cheers, Markus

[use-cases]: https://www.ietf.org/archive/id/draft-mihalcea-seat-use-cases-00.html
[intra-vs-post]: https://www.ietf.org/archive/id/draft-usama-seat-intra-vs-post-00.html
[aTLS]: https://github.com/edgelesssys/contrast/blob/3bd17f8/docs/docs/architecture/attestation/atls.md
[early-attestation]: https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-02.html
[exporters]: https://www.rfc-editor.org/rfc/rfc5705.html ff.
[id-crisis]: https://github.com/CCC-Attestation/formal-spec-id-crisis

________________________________________
From: Muhammad Usama Sardar <[e-mail]>
Sent: Thursday, January 15, 2026 1:31 AM
To: [e-mail] <[e-mail]>
Subject: [Seat] Fwd: New Version Notification for draft-usama-seat-intra-vs-post-00.txt
 
Hi,
To the best of my current knowledge and understanding, this draft presents a fair view of benefits and limitations of all categories. Pre-handshake attestation is only lightly covered since that has so many security problems.
For broader access, I have kept the formalization out with only pointers for interested WG members.
Section 6 asserts our motivation for post-handshake attestation, and section 7.2 complements it by providing evidence that Google, Microsoft and SCONE have implementations of post-handshake attestation, which are in use in practical scenarios and that post-handshake attestation is most likely not such a big problem as it seems. 
In particular, Google has specified it [0] and an open source implementation is available [1]. They consider TLS Client as RATS Attester. They use RPC on top of TLS and that looks promising to me. Does someone see something wrong with it?
Pavel has kindly contributed text in Sec. 4.1.1 and 5.2.1 in the draft, and firmly committed to pursue this forward. Peg did the review.
I and Pavel welcome WG feedback/thoughts/critique on the draft.
-Usama
PS: I pitched post-handshake attestation as a project for formal adoption at CCC Attestation SIG [2] and presented agentic AI use case in the CCC Attestation SIG meeting yesterday. There seemed to be no objection in the CCC Attestation SIG meeting and I am almost sure the project will go through.
[0] https://github.com/CCC-Attestation/meetings/blob/main/materials/KeithMoyer_STET.pdf
[1] https://github.com/GoogleCloudPlatform/stet
[2] https://github.com/CCC-Attestation/governance/issues/20


-------- Forwarded Message --------
Subject:
New Version Notification for draft-usama-seat-intra-vs-post-00.txt
Date:
Wed, 14 Jan 2026 13:58:57 -0800
From:
[e-mail]
To:
Muhammad Sardar <[e-mail]>, Muhammad Usama Sardar <[e-mail]>


A new version of Internet-Draft draft-usama-seat-intra-vs-post-00.txt has been
successfully submitted by Muhammad Usama Sardar and posted to the
IETF repository.

Name: draft-usama-seat-intra-vs-post
Revision: 00
Title: Pre-, Intra- and Post-handshake Attestation
Date: 2026-01-14
Group: Individual Submission
Pages: 11
URL: https://www.ietf.org/archive/id/draft-usama-seat-intra-vs-post-00.txt
Status: https://datatracker.ietf.org/doc/draft-usama-seat-intra-vs-post/
HTML: https://www.ietf.org/archive/id/draft-usama-seat-intra-vs-post-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-usama-seat-intra-vs-post


Abstract:

This document presents a taxonomy of extending TLS protocol with
remote attestation, referred to as attested TLS. It also presents
high-level analysis of benefits and limitations of each category,
namely pre-handshake attestation, intra-handshake attestation and
post-handshake attestation.



The IETF Secretariat