Tuesday November 4, 2025, 11:30-13:00 (UTC-4)
Chairs: Nancy Cam-Winget and Yaroslav Rosomakho
Note takers: Thomas Fossati, Muhammad Usama Sardar
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-seat-introduction-01
Chairs introduce themselves.
In scope for SEAT:
Not in scope:
Procedural: Mailing list and github (rfc8874)
Draft: https://datatracker.ietf.org/doc/draft-mihalcea-seat-use-cases/
Note: In slides 5-7 the arrows point to Attester
Slide 6: Workload owner (e.g., device owner)
The list of use cases is partial. Ionut is asking for more use cases.
Ionut goes through the properties (slides 9-11)
Ionut is asking for more eyeballs on the draft: have we missed anything?
Mark Novak: consider the problem of an admin of server running a
confidential workload;
platform and workload are typically managed by different entities:
Consider making the session administrator easier.
Update for all the clients may lead to outage.
Consider the RP
Mark Novak: Unmodified TLS stack may help in bigger deployment.
Chairs propose the concerns to be addressed in the use cases document.
Yuning Jiang was in queue but had voice issues.
Henk Birkholz was in queue but left the queue.
Giri Mandyam: re: properties. how the WG will address this. if the
properties are not narrowed down, then draft-fossati-tls-attestation
could be still considered in scope for the group.
Ionut: the binding between attestation and secure channel
Giri: prohibition of intra-handshake is not in the charter
Paul Wouters (as AD): Pick the best solution. Nothing is excluded at
this point. Do the discussion about use cases and then slowly migrate to
adopting drafts.
Yuning Jiang has audio issues. Someone in the room presents on
behalf of Yuning Jiang: we would like to contribute a use case related
to AI agents (w/ highly dynamic TCB) if considered in scope.
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-seat-insights-from-formal-analysis-01
Pre-prints:
The initial formal analysis is focused on confidential computing and
server as attester.
Presenting the analysis of pre-handshake and intra-handshake
attestation.
The analysis of post-handshake attestation is a work-in-progress that
we will keep expanding.
split between platform and a single confidential virtual machine, plus
the associated key material and related identifiers.
a more formal realisation of the properties that Ionut presented
beforehand: related to remote attestation layer and TLS layer
separately, plus a set of "composition" goals between the two layers so
that the two layers agree.
Results for pre- and intra-handshake are available (and already
presented in UFMRG), which shows that a few desired properties are
violated - e.g., freshness of evidence, server authentication and
composition goals.
We tried to answer the question: what is the best level of security we
can achieve in pre-/intra-handshake?
The best we could achieve is that we still have violation of binding
evidence to application traffic secrets.
Slide 13 is the summary / take away.
Pre- and intra-handshake attestation are not suitable choices for
standardization.
Note: The system model depends on protocol as well as architectural
details, which makes things particularly tricky.
The post-handshake is currently under evaluation.
Q0: any property missing?
Q1: what level of abstraction the WG wants to have the proofs?
Q2: Lightweight FATT for this WG too? Or at least someone having a look,
please
Giri: I do not disagree with any of the results in this formal
analysis. It may not necessarily be either intra-handshake attestation
or post-handshake attestation. A combination is also possible.
I would like to see the formal analysis extended to include what actions
could the Verifying Relying Party take that wouldn't create security
breaches by the time the protocol progresses to the post-handshake
phase?
Nancy: are we jumping the gun here? Should we do analysis once the
use cases are solidified?
Usama (responding to Giri): post-handshake analysis is in progress.
Once we have that, we can look into the combinations as well.
Jonathan Hoyland: I think the key thing is to describe the security
properties in terms of compound authentication. A single attesting
machine has multiple "identities" that it can use at once (i.e.
ephemeral keys, attester keys, etc). There are also two separate
protocols that are being combined, TLS and RATS. This is a protocol
composition and needs a compound auth, i.e. you need to prove that the
TLS terminator shares cryptographic state with the attester. (Exported
Authenticators are expressed in this form.)Usama: I believe the composition goals G-C1 and G-C2 are taking care
of this compound authentication. State is one of the explicit
parameters of agreement.
If you think it is not covered, could you please express your property
more explicitly?Jonathan: So the property I would expect would be phrased something
along the lines of "If the TLS channel is negotiated securely then the
attestation was honest" and "If the attestation was computed securely
then the TLS channel is honest", i.e. an attacker needs to compromise
both TLS and RATS to compromise the combined protocol.Usama: IMHO this is not realistic. Attestation Key is the most
protected key and very limited software has access to this key.
Breaking Attestation Key breaks everything.Jonathan: Exported Authenticators achieve this property, so it's
certainly possible.
Muhammad Usama Sardar: oh that is work-in-progress. I showed results
only for pre- and intra-handshake.Jonathan Hoyland: You might only want one-way compound authentication,
where "if the attestation was secure then the TLS session is honest"
but I would imagine that achieving the other direction as well would
be pretty easy.Muhammad Usama Sardar: sure, hopefully by next meeting, we will have
something on post-handshake.Paul Wouters: (as individual) i think a point I cant see getting
formal analyses is how you prevent an app from using the established
TLS session before the attestation part has come back with a green
light
Draft: https://datatracker.ietf.org/doc/draft-fossati-seat-expat/00/
We believe this draft is in line with the charter and relatively mature.
The core idea is to use EA (rfc9261) as the substrate for conveying the
remote attestation protocol (RATS) information elements.
What you get in the end is a secure channel bound to the remote
attestation protocol session and the underlying TLS channel.
Uses a new extension "cmw_attestation" that is used to transport the
relevant RATS credentials (evidence and attestation results).
Negotiation of the formats is still TBD.
Slide 7 provides an example of passport model
Slide 8 provides an example of background check
Modelling an API that is transparent to applications depends on some
details not yet well defined. This is TBD still.
We think this addresses the required security properties.
Asking the question whether we would like to go for adoption now? Chairs
and WG for the decision.
Chairs: "have you read the draft?"
yes: 10
no: 16
no opinion: 1 :-)
Nancy: Given we don't have use cases alignment, I'd rather do the
discussion on the mailing list.
Call for adoption on the mailing list.
Provide feedback on the mailing list.
Yaroslav (as individual): application needs a way to exported
authenticator.
Paul W (as individual): PAKEs (used as an analogy) add additional
roundtrips before the session is usable is not optimal. It'd be more
friendly to the application if a solution could simplify the user
experience. If there is no other way, we can do this.
Yaron: There are some challenges like session resumption.
Hannes (replying to Paul): This is less of an issue with this
document than with intra-handshake attestation.
Ionut: We have looked at other options.
Jonathan: Exported authenticators over the TLS channel is not a
requirement of security. It is a practical requirement.
It is also possible out of band. Do handshake first and then inject that
state into the second handshake.
Ekr agrees with Jonathan for resumption.
Ekr: Instead of the proposed empty cmw-attestation, you should have
request and response. Request is always empty and response should have
data in it. That's a fine point.
Usama (responding to Jonathan): We will definitely consider that
solution but I suspect that might not be well accepted by the
confidential computing community. That's one of the targets that we
have.
Stuart Card presents aviation perspective.
Daniel Migault is in queue but Nancy notes that we are late in
agenda. Chairs ask Daniel to post on list.
Kudos to Peg for starting the Rust implementation.
There are people eager to provide a second implementation that we can
start interop with.
Runs a QUIC connection and an expat session on top. It works! But is
limited wrt attestation backend support (only Intel TDX) is supported.
Pain points:
We probably found a bug in the spec about the practicalities of the
binding. Require 9261 experts advice.
Jonathan: what context were you trying to use in the EA?
Ionut: binding between TLS and RA credentials: we need exported key
material that can be used in the attestation evidence that is created.
It is not well defined in the draft. Is it acceptable to use the
handshake context for the binder? Or should we define something new?
Jonathan: I did the formal analysis for EA. I'd need to read it but
you probably need something new.
In chat, Jonathan offers to help offline about security guarantees.
Chairs: provide constructive feedback on the draft in the ML.
Session adjourned.