Session Date/Time: 23 Jan 2026 16:00

SEAT

Summary

This interim meeting featured updates on the "Use Cases and Properties for Secure Establishment and Attestation (SEAT)" draft and a presentation on the "Early Attestation with TLS" draft. Key discussions revolved around the granularity and focus of the use cases, the definition of attestation timing (intra-handshake vs. post-handshake), and the compliance of the "Early Attestation" proposal with the SEAT working group charter, particularly concerning modifications to TLS messages and the key schedule.

Key Discussion Points

Use Cases and Properties for SEAT Draft (draft-ionita-seat-use-cases-props):
- Overview: The draft aims to define reference use cases and properties for Secure Establishment and Remote Attestation.
- Existing Use Cases (IETF 124): Included Confidential Data Collaboration, Security Provisioning and High Assurance Operations, and Network Infrastructure Integrity, with specific examples like data clean rooms, runtime secret provisioning, and attestation of network functions.
- New Use Cases Added:
  - Operation-triggered attestation for dynamic high-impact application operations (e.g., AI agent performing sensitive actions).
  - Attestation of a certificate's private key (e.g., proving non-exportability during TLS handshake).
  - Platform-to-platform communication (e.g., workload migration over attested channels).
- Use Case Analysis Lenses (Yuning Zhang): Proposed categorizing use cases by roles (attester/relying party as client/server/mutual) and attestation timing (initial connection, runtime, or both).
- Review Status: A poll of the room indicated low review engagement from non-authors (6 "Yes" reviews vs. 8 "No").
- Discussion on Use Case Granularity: An individual contributor noted that the draft might focus too much on industry-specific examples rather than identifying distinct protocol requirements. It was suggested that use cases should highlight different protocol work needed, followed by industry examples.
- Chair's Feedback: While industry applicability is valuable, the draft needs to more clearly articulate the technical requirements for TLS protocol assessment, such as when attestation is required (pre-handshake, intra-handshake, post-handshake).
- Definition of Intra vs. Post-Handshake Attestation:
  - A discussion arose regarding whether the distinction is about the layer in the protocol stack where attestation is integrated (Yoran's view) or the timing relative to the TLS handshake (Usama's view, referring to signatures being within or after the handshake). Usama cited existing literature and global platform definitions supporting the timing-based distinction.
  - An individual contributor (Pavel) emphasized that both "when" (lifecycle) and "where" (layer, message embedding) attestation happens are important, along with scalability considerations, and should be explored in the use cases document.
  - Didu highlighted the importance of understanding application changes implied by different attestation approaches.
Early Attestation with TLS Draft (draft-yaron-early-attestation-tls):
- Motivation: The draft aims for the simplest possible application integration (application sees plain TLS), minimal disruption to the TLS handshake and protocol (e.g., DTLS supported as is), support for various attestation technologies, and re-attestation capabilities.
- Application View: Attestation is presented as a configuration, not additional code, with re-attestation possible transparently (periodic) or API-driven.
- Charter Compliance Concerns:
  - The proposal explicitly adds a new "Attestation" message to TLS, which conflicts with the charter's mandate that the attestation protocol "will not add or modify any existing protocol messages."
  - The proposal adds a derivation of new secrets (an "attestation binder") to the TLS key schedule, which is seen by some as a modification to the key schedule, also conflicting with the charter.
  - Authors claim no decrease in security/privacy properties of generic TLS/DTLS.
- Proposed Additions: Negotiation extensions (evidence proposal/request, results proposal/request, acknowledged as complex and needing simplification), a new Attestation message (containing a RATS CMW structure), and an attestation binder (derived from TLS main secret, message transcript, and attester's public key).
- Re-attestation: Proposed using the Extended Key Update (EKU) exchange (a TLS WG draft) to bind new attestation into a new main secret.
- Alternative under Consideration: Replace the new Attestation message with an extension to the TLS certificate message, which would be more aligned with the charter.
- Formal Analysis Discussion: Usama reiterated his previous IETF 124 finding that ClientHello and ServerHello alone are insufficient for certain attestation purposes, which the authors of this draft disagreed with.
- Chairs' Summary of Charter Concerns: The core issues are the introduction of a new TLS message (should ideally be an extension) and the derivation of new keys from the key schedule (should potentially use existing secrets like early exporter secret).

Decisions and Action Items

For draft-ionita-seat-use-cases-props:
- The authors are requested to refine the draft to better articulate the specific technical requirements for the protocol work within the SEAT WG, moving beyond purely industry applicability. This should include exploring timing (pre/intra/post handshake), layer integration, scalability, and security properties driven by the use cases.
- The authors will post a new version of the draft incorporating these requirements.
For draft-yaron-early-attestation-tls:
- The authors will explore modifications to the proposal to better adhere to the SEAT charter, specifically by investigating the use of a TLS certificate message extension instead of a new TLS message and considering the use of existing TLS secrets for the attestation binder.
- Further technical discussion on these approaches is encouraged on the mailing list.

Next Steps

The working group is encouraged to provide more reviews for the "Use Cases and Properties" document on the mailing list.
Discussion will continue on the mailing list regarding the "Early Attestation with TLS" proposal, focusing on its charter compliance and technical feasibility within the specified constraints.
The working group will collectively focus on the interest and viability of intra-handshake attestation work at the TLS level for the identified use cases.