Session Date/Time: 17 Mar 2026 08:00
This is a verbatim transcript of the entire SEAT Working Group meeting at IETF 125.
Yaroslav Alexandrov: Yaroslav, I can take some notes, take, make sure that the actions are covered and the detailed minutes are in Etherpad anyway.
Hannes Tschofenig: Thank you, Hannes. Really appreciate that. Okay. Can we please close the doors at the back? There is quite a bit of noise going from there. Thank you. Thank you very much. Okay. Hello, everybody. Thank you for joining SEAT working group meeting. Again, make sure that you are in the right place.
Before we begin, please do pay attention to the Note Well. I know that it's the second day, it's the fourth meeting of the second day, you might have seen that already, but again, this is important. We have all agreed to Note Well by signing into IETF, by joining this meeting, but please keep in mind that we are expected to behave in professional manner. I know that attestation for many of us is an exciting topic and sometimes we cannot contain that excitement, but we still need to be respectful of each other and make sure that we criticize ideas and not people. If you know about intellectual property associated with things that are being presented here, make sure that you disclose that and yeah, make sure that you follow all other items in the Note Well.
With that, we have five main items on the agenda. So first chairs will take a few minutes of your time, then we will dive into pre-intra and post-hand attestation comparison work that Osama has been doing. After that, Nathaniel is going to present his proposal for factor-based attestation and credentials transport scheme. After that, Tiru and Osama are going to walk us through the latest revision of remote attestation with exported authenticators, draft that has been around for a little while, and then finally Yaron will take us through early attestation proposal. Any agenda bashing? Speak up now. Okay. Osama, anything, anything you'd like to—
Osama Abbas: Yeah, I would like to, I would like to ask if it would make sense to have the two intra-handshake proposals together? Maybe before or after, but I think that would be nice if they are both together. I mean three and five.
Hannes Tschofenig: Sorry, sorry. It's a bit hard to hear you. Could you repeat that, please?
Osama Abbas: Oh, sorry. Okay. So I'm saying that maybe it would be better to have three and five together. That's what I meant. The intra-handshake proposals together would probably be nice.
Hannes Tschofenig: Uh, okay.
Nancy Cam-Winget: I don't know what that means, Osama. Do you want us to change the order?
Osama Abbas: Yes, I was asking if three and five could be presented together. They are both intra and it would probably be better to have them together, but it's fine if you think that's— just a suggestion.
Hannes Tschofenig: All right. Unless there is strong desire to change the order, let's, let's keep it as it is. Okay. Before we dive into other things, one point of order. Please do submit slides timely. So, I think the agenda was published a week before the meeting. Nancy and I sent requests for slides, we've asked presenters to submit their slides before the end of Sunday. Unfortunately, we have received some slides just an hour and a half before the meeting. The reason why slides are submitted upfront is so that chairs would be able to review them and ask to make some changes in some cases. So if you submit them late, then we don't have an opportunity to do that. We will be enforcing more strict submission timelines by the next meeting. So if you don't submit your slides timely, you risk to either present without slides or fall off the agenda. Please do submit slides timely next time.
Okay, so we have had interim, very lively discussion on two topics. One was use cases. So, unfortunately, use cases draft was not updated in time for this meeting. So we today have six use cases that cover nine different integration properties. And as chairs, we believe that use cases should be eventually adopted and should be the foundation for any protocol definition work that we would be doing in this working group. So with that, let me start our first poll. Do you think if draft, use cases draft is ready for adoption? So please do answer yes if you've read it and you think it is ready for adoption, no if you've read it and you think it's not, and no opinion if you haven't read the draft or otherwise you don't have an opinion. This is not an adoption call, an adoption call we will be making on the mailing list, of course. This is just to get temperature in the room. Hank?
Hank Birkholz: Yeah, hi, this is Hank. Uh, for me, it's the very first time ever that someone wants to adopt use cases as a document. Is this intended to be published as an RFC?
Hannes Tschofenig: I don't believe so. Just to keep this more official as a working document.
Hank Birkholz: Exactly. So as a living wiki? Like, okay, that's fine. And then maybe we can transfer some the generic one into the main document or something. Then then I'm fine. Okay. That was just a clarifying question.
Hannes Tschofenig: Thank you for the clarifying question, Hank. Okay, so we have six yes, seven yes, zero no and thirteen no opinion. So thank you very much for those who read the draft. Please do read the draft. We will be making a call for adoption on the mailing list soon and, of course, we need enough votes to adopt anything.
The second interim topic was early attestation proposal. So the proposal that describes how attestation can be performed within a TLS handshake. So the initial proposal was clearly out of scope for, out of scope of our charter, so we cannot adopt that. However, authors took the feedback and adjusted their proposals and they now claim that the updated specification is within the charter. As the reminder, our charter claims that the attested protocol extension will not modify the protocol itself, may define extensions to support its goals, but will not modify, add, or remove any existing protocol messages or modify the key schedule. So we will have a presentation of this proposal, however we would really like to know who, if anyone other than authors, read this latest revision of the draft. Let me type in the poll. So the poll started. Please answer yes or no. If you don't remember if you read it, you may answer no opinion, but better be precise. And I kindly ask authors not to vote. Okay, out of fifty-three attendees, according to Meetecho, we have seven who has read the draft. That's not a lot. Please do read the draft. It was, it was published in good time before the meeting.
Okay, and with that, again as a reminder, our mailing list is seat@ietf.org. That is our main communication venue for anything that is related to the working group. All the adoption calls and all the other official business will be conducted via mailing list, so please do use that. And once something gets adopted, we will be following RFC 8874 and managing adopted documents on the GitHub. So there is nobody in the queue and with that, let me transfer to Osama to take us through his comparison of pre, intra, and post handshake attestation. Osama, is that the right slide deck?
Osama Abbas: Yes, that's correct.
Hannes Tschofenig: Excellent. Let me pass the control to you. Go ahead.
Osama Abbas: Thanks very much. Welcome, everyone. I'm Osama and together with Vyacheslav and Jan Perry, we have done some research in the past years and which we kind of summarized in our draft Intra versus Post, with the motivation that starting from the use cases, it kind of sits in between the other drafts in the sense that it will kind of compare what are the different options, pre, intra, and post, presenting the taxonomy, and from that taxonomy, doing the kind of the comparisons which then we can see like which direction is most feasible and so on. So this is one specific part of that, so I requested thirty minutes slot, then Nathaniel also came up with a proposal so it's kind of not covering all of the space and a specific one for security comparison, the research that we recently did.
So with that, just as a quick reminder, we have attested TLS and the whole protocol domain can overall be classified into three different classes. First one, pre-handshake attestation, the signing of the claims is from the remote attestation side the most important thing because it's the thing at which the cryptographically the all claims are set and then they are protected. So if that happens before the TLS protocol has started, that's pre, if it is in between, that's intra, and if it's after, that's post-handshake. So that's the kind of the taxonomy we have. People can think of other ways as well, I cryptographically and from my formal methods background, I find it the most feasible because this has direct meaning for what we will do in the property side and that's why it's the temporal kind of the scale and not in what ways you do attestation. So independent of the methodology, this is dividing into three different schemes.
Then there is a typical comparison. Just as a reminder, we made some changes to the one we had before, which is that there are three different layers at which we can compare protocol deployment and higher layer, meaning that whether the protocol changes in one of those, whether the deployment needs to change, or whether the higher layer, meaning some application layer or so on, needs to change. Tick represents that there is no change, cross represents that there is some change required. And in intra-handshake, for example, in our assessment, it needs invasive changes to be secure. And in pre, it requires deployment changes. And all of those require basically higher layer changes, meaning that we are doing the comparison for the case of mutual attestation as well, so from the client side, basically you always need to do some kind of verification and that's typically at the higher layer and also from the attestation side. So that's always the case that unless you do, unless you restart the connection, basically that's always post-handshake.
So with that little background, our AD instructed to exhaustively explore intra-handshake attestation and as I said, I will just focus on this specific part and kind of summarize the other results what we have in the last slide. So what we did for that is we took the Agentic AI case use case, that was one of the use cases presented in a draft submitted to the SEAT working group and in the bottom left side you see Agentic AI use case, from that we derive the security goals. From the security goals, one of the most important one we define is the correlation property, how strongly the evidence is correlated with the underlying handshake. That's what the property defines and we define three different levels that appears as the binding levels underneath that. And then there is a threat model as always for security analysis and based on that threat model, we do the formal analysis. On the right top, you see different binding mechanisms and practical implementations. We took all the possible implementations that we could find and asked in different forums whatever was there so we took all of that. And that we take as the formal model. I have on the left top, I have this layered attester and composite attester. So from attestation perspective, we can think of the layered attester and composite. So basically that covers all the trusted execution environments that we have and that forms the system model. With now the properties and the model, we can do the formal analysis and from the formal analysis with correlation properties, we find relay attacks, propose some mitigations and then we go back in the loop to do it again and repeat that until we find a possible solution.
So that's overall the approach and I will not read all of that. So basically, I have two categories. The first four are the base possible base binding mechanisms and the rest three are the combinations of those. Attestation nonces you always need, that's why we take it always. So different combinations are possible, but we take the ones which are most relevant or makes the most sense. And one discussion point specifically that I have is that is there any other binding useful binding mechanism or combination that folks think that should be considered other than the ones we have in the slide? And the second thing that I would like to discuss and then I do the mapping over to different mechanisms like practical implementations. Meta's AI, for example, follows one, draft CoS-TLS attestation version six follows five, and H-less systems Contrast, CoCo's AI, Confidential Computing Consortium Proof of Concept use number six. And that's another discussion point if there is any other intra-handshake implementation known to somebody, that would be very useful for us to kind of analyze that as well so we can have really exhaustive analysis over that. So I will probably pause here for a second to see if there are any opinions or thoughts on this before proceeding. On these two questions.
Hannes Tschofenig: So far none.
Osama Abbas: Okay, so then I proceed. Then this is something that Ecker brought up at the charter time. There was a discussion that traffic secrets, handshake traffic secrets and application traffic secrets. So we define three different levels and the first one is the gxy, that's the Diffie-Hellman shared secret. Second one is the handshake traffic secret of the client, and since we're dealing from the client side, and the third one is application traffic secret of the client. And the reasoning here is two folded, sorry, not level, sorry. Two, twofold so to say, not level, sorry. The first one is the handshake traffic secret is basically used to encrypt those communications, these handshake messages, Client Hello, sorry, not Client Hello, Encrypted Extensions, Certificate, Certificate Verify and so on. These are the messages which are encrypted. And what I did is basically I removed all this encryption, encryption of these messages and no security property changes. So that's why I write irrelevant for security goals. And on the other hand, if we have the application traffic secret, which is written at the bottom, that's a really useful thing because the last step which is shown as three with the secret, the secret that the client will send at the end of the protocol, if that is now unencrypted, that's basically becomes available to the adversary and all the security is then lost independent of whatever nice things we have done in the protocol. So that's really, really important to do have some correlation to the application traffic secret rather than the handshake traffic secret. Second point that I want to raise here is you see in the three steps on the right, unauthenticated key exchange, authentication and application traffic. The second one is authentication and for the intra-handshake, basically, the evidence is generated between step three, sorry, the Encrypted Extensions and the Certificate, so one c and two a and in between that, the authentication process has not even started. That means basically server is not yet authenticated. So what we are attesting to is basically an unknown party and that could itself be an attacker. That's the main issue here.
So I show here two different types of the relay attacks that we have during this analysis. So I showed you seven different mechanisms. This is the first of those mechanisms and in this case, we had the TLS nonces used as the binding mechanism. So what an adversary in the middle can do is it can simply just relate over to a genuine attester, in this case we have taken the AI agent, so that would be that will generate an evidence and with the right measurements, give it over back and then it will show as its own evidence. And then the attested channel will be created between the verifying relying party and the adversary rather than the verifying relying party and the genuine AI agent.
Second attack is for mechanism number four, which was for the public part of the key which the agent has and it's possible by different means, for example, that the that key is accessible to some entity other than the AI agent, the genuine AI agent I mean. For example, if it was provisioned at the runtime, it means it is accessible to at least somebody other than the AI agent itself. And also, for example, it can be leaked via vulnerability in the code, even if the trusted execution environment is perfect, there are no vulnerabilities within the trusted execution environment, the code that we put into it, for example like Heartbleed and so on, that can be problematic. So that can actually break the guarantee, this key can be leaked and if this happens then the adversary has the access to this key and intra-handshake mechanisms actually then break out flat because there is no other thing which can protect them from this kind of attacks. So what happens is basically the adversary has the private key, it can then form these messages which are shown here, Server Hello, Encrypted Extensions, Certificate, Certificate Verify, Finished, and then the verifying relying party will basically accept it and send over Finished, establish the connection which is actually between the adversary and the verifying relying party thinks it is connecting to a genuine AI agent.
So the core problem that we see here is the binding evidence to unauthenticated peer. Tiru has some question. Go ahead, please.
Tiru Reddy: Thanks Osama for the detailed analysis. If you could go back to the previous slide? Right, I think you mean the the identity private key that you're referring to that's used in PKI, right? That's the one you're referring to getting leaked or are you referring to the attestation key getting leaked?
Osama Abbas: No, it's not the attestation key. So that is in this case this key is the one which is with the trusted execution environment and for example if you have the virtual machine it will be within the virtual machine. Not the one with the cloud provider.
Tiru Reddy: So if if my private key gets leaked, then anybody can mimic me, right? I mean, I mean then all security is off the table, right?
Osama Abbas: Right, for this, these protocols specifically, but it's possible to protect it via post-handshake in which you can if even if this key is leaked and the session keys are not leaked, you can still have because the exporter that that draft then we will present in there, that can still protect in that case.
Tiru Reddy: Yeah, my question is if an attacker gets access to my private keys, then all that they have to do is just take an act as a, break my connection, send reset packets, and I'm forced to establish a new TLS session and it could easily act as a man in the middle, right? I mean, I mean all bets are off if if private keys are lost. There is no protection, long-term protection, if private keys are lost, right?
Osama Abbas: I'm not sure what you are heading to, so that's what I'm also saying. So are you saying that it's impossible to protect or what?
Tiru Reddy: I'm saying none of the solutions can offer any protection if the long-term private keys are stolen, right?
Osama Abbas: It's not the long-term key. It's the, it's the key with the, so the the scheme is the one which I presented in the last meeting, that is the ephemeral key is the one which is with the VM and the long-term key is the one which is from the cloud provider. That you have two roots of trust. If you lose one, the other one can still protect you. So that's the threat model that we have as presented in the last meeting. Does that clarify your question?
Tiru Reddy: No, I'll let others talk but I probably will take it offline. Yeah, thanks.
Osama Abbas: Okay, sure. Thanks, Tiru.
June Park: Hello. I'm not an expert in the formal analysis, but I would like to know that so how to guarantee that the code you write for the formal analysis itself is correct? So can we use the AI agent to write the formal analysis?
Osama Abbas: So I will not answer the part for the AI agent. I don't believe in AI agents to do formal analysis, but I can answer the first part, which is to say, I write my code, I submit to a conference. So this work that I'm presenting is being submitted in the ACNS conference, Applied Network Security Conference, which is one of the—
June Park: Still reviewed by human, right?
Osama Abbas: It's reviewed by humans. Sure. I mean—
June Park: So how we guarantee that code is correct? I mean that—
Osama Abbas: Sure. Sure. I got you. Okay, June, let me complete first. So I'm saying that, okay, so that's first level of defense, right? So they can actually check the code and that's in good conferences that's a requirement to check the code and so on. So it's just not accepting papers. Second thing is then I will make the public make the code publicly available. All of you and are welcome to analyze that. If, for example, you are not an expert, we have experts in UFMRG and actually I think to tomorrow or something like Thursday, I am actually presenting in the CFRG, which is the Crypto Forum Research Group. So we have all these experts there who have spent their lives doing with the crypto work and we can get their feedback on it, right? So there are multiple levels. It's not just that somebody has done it and if you are not an expert, of course, and if you trust in AI agents, you're welcome to run AI agents on the code that I will make it public, so that will be under Apache License 2.0, so I think you can just do anything that you want with that code. And if you—
June Park: What you just said is contrast to what you said— can you go back some slides? You see that okay if some code is not written, where is it, in this page. So there is a leakage because okay you see that you do not believe the code write by human, but then you see that you believe the the formal analysis written by human. So this is in contrast, right? In one way you say that okay, the the code is not well-written and in other way you see that formal analysis is well-written.
Osama Abbas: So they are two different things, June. One is talking about—
Hannes Tschofenig: Just as a reminder, we have three minutes remaining, so we may want to keep the questions and answers concise.
June Park: Okay, I will leave.
Osama Abbas: Okay. Sure. So maybe I just quickly pass through the slides and then come to you, Jonat. Is that fine for you?
Jonat: Sure. Sure, yeah.
Osama Abbas: Thanks. Okay, so I think I have only a couple of those so let me quickly go through them. The problem is binding evidence to unauthenticated peer, as in the slide which was quite long, I showed that basically the server was not even authenticated at that point in time when in intra-handshake we bind the attestation evidence to that. So there is a need for implementation guidance, meaning that many implementations that we saw including Meta's AI, and just as a reminder, Meta's AI was already reviewed by Trail of Bits, that one of the security assurance companies or whatever we call it, right, the auditors of that, so they had already reviewed it but we still found problems in that. So there are subtle problems that cannot be found without formal methods, so it provides quite a lot of value by doing formal analysis. So conveyance of attestation nonces, different people were using like SNI or ALPN, which is not really meant for this specific purpose and that's the need for implementation guidance and standardization is really there and that's where we see the value in this work specifically and CCC attestation, attested TLS proof of concept is a project at the CCC. There has been no update in that for last three years and one question I have for discussion which I will then surely you can send over the mailing list was that if there is any other intra-handshake attestation implementation within the SEAT working group charter that we should consider. Finally, I think this is the probably the last slide. So the relay attacks that we discovered in this work have already been acknowledged by CoCo's AI and they have like the one that I also sent to the SEAT mailing list, that's just a rephrase of all that what we have shared with you. And then finally our summary is that pre-handshake attestation has replay and diversion attacks, that was the one of the first papers we shared, and then intra-handshake diversion and relay attacks. Diversion was the AsiaCCS paper, relay attack this paper. And to our knowledge, there is no currently known attacks on post-handshake attestation. And the last point I have already mentioned. So Jonat, please go ahead.
Jonat: Okay, yeah, thanks. So I'll try to be quick. So I just wanted to make one comment. So you one of your slides essentially relies, yeah, that slide essentially you say that, oh, if the attacker leaks the private part of the EK, then, you know, this this sort of binding is lost. And my point is why do you think the attacker can or would stop at just the the private part of EK? I mean basically everything like master secret or application traffic secrets are all in the TEE memory. So if if the attacker can leak this part then they can definitely leak the other things which breaks any binding. So my point would be, you know, either either broader broaden the attack surface and just say everything can be leaked or get rid of this attack avenue.
Osama Abbas: Sure. I will very quickly answer this, Jonat. So there is like there could be a specific vulnerability in the code. It's not necessarily that the TEE is broken as I said. So one of the options I write here is leaked via vulnerability in code. The code within the TEE let's say is broken. It doesn't necessarily mean that both will be leaked together. It could they are both independent, right? So even though they are stored together, the vulnerability might just leak the private key and not the other key.
Hannes Tschofenig: Thank you, Osama. Let's move on to our next item on the agenda. Nathaniel, let me pass you the control.
Nathaniel: Okay. You should be able to control the slides now. Go ahead. Okay. Thank you very much. So, I have been a long-time lurker, first-time poster, first-time IETF, so I really appreciate the opportunity to present with such a healthy time slot for a 00 draft.
So FACTS is a hybrid intra-handshake remote attestation protocol with strong binding and per-session freshness without modifying the TLS state machine. That was the design goal when I was working on this protocol over the past while and it was motivated on the debate that was happening on the mailing list regarding affecting the TLS state machine with new messages as well as changes to the key schedule. And I was approaching this not from the confidential computing side specifically but still had the same threat model. I was approaching this from how do we access remote ephemeral VMs on really cheap $5/month VMs, that sort of thing. And I've been using Proverif as a way to do QA basically to see, okay, I'm experimenting with this, what are the security properties. And then when Osama and colleagues started releasing their findings regarding relay attacks, diversion attacks, and released their open source model, I was able to take advantage of that and experiment with that some more. And when it came up to the opportunity to develop a draft and submit just before the deadline, I was like, okay, we have early attestation which in the 02 draft had a attestation message that was violating the state machine and about an hour or two before I was ready to email the mailing group, 03 came out, threw away the attestation message, came up with a new cryptographic binder and I'm like, oh, okay, I'm not exactly sure what to do now. So I have been working on Osama's model extensively and I have no disagreement with any of the findings. The what happens with the naive binding with the old TLSA-SA spec does not provide strong binding and a comprehensive agreement on all the parameters. So even if you have the attestation signing key and the ephemeral key and they are not compromised, everything's fine, you still don't get any of the security benefits and that's proven in Osama's model and I took that and I developed from there.
So factor-based attestation is taking a unique approach besides adopting Osama's model. I have a private signing key and I had devised a second authorization mechanism before I approached this with the secure enclaves and the TEEs. So that's why the architecture here is so strange is because I was looking at this, okay, how do we secure— how do we have any assurance at all without just using a short-lived JOT to deploy services through Spiffy Spire or on cheap VMs? And then using Osama's model and the remote attestation and TEEs, I found that we were able to bring them together. When I ran the attestation binder from the early attestation 03, I found that it ended up having the exact same security properties that I had been working so hard on FACTS and so that was an interesting finding and I shared that with the mailing list. And I understand that Osama's had very many meetings, we'll continue engaging on the mailing list to see what my approach with his model is, where the challenges are, but what I found was that the security properties for both 03 and FACTS met the security challenges or surpassed the security challenges that the original identity crisis model had.
So I take the long-term identity key, I take a key encapsulation mechanism, it doesn't have to be PQ, it can be ECDHE KEMs to encapsulate nonces and then bind them to evidence using an attestation key. So the threat model that I had developed is basically assuming that there was an active man-in-the-middle the entire time and that's where this encapsulated nonce system comes in. So there's a pre-authentication process where either the verifying client has an signed attestation result that already has a KEM for the public or for the server public KEM already available or if there is an enrollment process, that's also how it can be found, but the presupposition is that the client already has access to the server's public KEM. Similar in concept to encrypted client hello but that's focused purely on privacy and not on attestation. So the client encapsulates a challenge, a nonce, only the recipient server has that, it takes that, unseals it, creates its own challenge nonce, encapsulates that to the public key for the client, sends that back, and the man-in-the-middle is assumed in this case to have both the long-term signing key and the attestation key compromised. And going through the standard TLS state machine, you basically have a handshake in a handshake is what FACTS effectively is without the attestation part. So adding attestation allows for additional— instead of just a single key compromise, which is what early attestation offers, where either the attestation key or the long-term key can either individually be compromised, FACTS allows two out of three keys to be compromised and still maintain security.
Here's the slide out of order. So pre-authentication has overlapping concepts in terms of being able to take a JOT or a CBOR CWT, gather public commitments off of that and then use that to encapsulate the nonces back and forth and then at the end of that process, I have a proposal which I would have to approach the TLS working group about for EKU, where the encapsulated nonces can be derived into an ephemeral PSK and provide that third layer of protection. Now if we take out this exotic encapsulation key process, it's effectively the same security properties as early attestation.
In terms of key life cycles between the three drafts, I noted that effectively all of them have a very firm policy-based bound on key life cycles. There's no specific cryptographic way to be absolutely confident that a particular key is inside a TEE and so that's the security posture that FACTS has is that it assumes that a number of keys can be compromised. Again, if we're working on systems that aren't attestation-aware, there is going to be a much higher chance that keys can be compromised. And FACTS essentially adds an additional layer with that KEM process. In either case, if you have a system, a TEE with running an intra-handshake with FACTS, you have that additional assurance. If not, then you still have the resilience to single key compromise: either you have the attestation key lost or the long-term key can be compromised and you still have the security properties that you're expecting from attested TLS.
So there's three different binding choices that are currently on the table right now. Early attestation has that new binder that they've just proposed, that's the one that I ran directly in competition to the one that I had come up with on my own that came up with the same security properties through Osama's proven model. And I found, okay, I should let the authors at early attestation know that their binder appears to meet the requirements to mitigate the relay and diversion attacks as far as I've been able to see. And again, I'll need to interact with Osama and colleagues and other experts to make sure that the models that I've come up with are actually sound. But across all of them, and Osama also asked me on the mailing list to model his version as well, so all three of those are modeled, they're put up onto GitHub so that anyone can take a look at that, download it, run it and provide feedback to see where the security properties actually are based off of security assumptions.
So that's effectively it. Again, I've put together a Proverif playground with all three of the models that are currently proposed in the working group, just focused on the binder itself. Sure, Osama.
Osama Abbas: You can finish. It's fine. Are you done?
Nathaniel: No, I am almost done so. Those models are online and I wasn't sure how long it would take to go through these slides, so there's a lot more in the draft that goes through mutual attestation, mTLS, I have gone through the other drafts to look at the different security properties. So one of the things that I noted from the X-PAT draft was the ability to say, hey, a client is coming in trying to get the server to attest, let's wait, let's get the client to attest first during the intra-handshake and then have the server attest afterwards. All that's in the in the draft, I haven't had a chance to put that into the slide, but there's a lot of detail in there and I am interested of course in substantial review and collaborators on the FACTS draft, either from the existing authors or new collaborators. And I just wanted to— there's a bunch of names at the bottom there, they're all the different authors from the working group. Bruno Blanchet is of course behind Proverif and I have— the work that I have put together and presented is based off of all of the work standing on the shoulders of the community. So I just wanted to acknowledge all of you. So go ahead, Osama.
Osama Abbas: Yeah, a huge thank you to you for doing all this work. I think this is very useful work and we should really be doing this attestation as the chairs also said is not an easy topic and formal methods, I believe, are the only way we can proceed forward. Yeah, and thanks also for doing the analysis for our draft specifically for the X-PAT draft. I really appreciate that. I didn't get the time, sorry for that, to check your models in detail, but I will definitely look into it. So that's as an author, of course, I can be biased. That comes back to the June's question. So he was arguing that, okay, so you as a person write it and I would like to know your thoughts on how do you how do you as a developer as well as, let's say, you you are also an author, you are also doing the formal analysis of your own draft. How do you see being biased about it, like you could probably be biased. Of course, your models are available, we can check it, but I wonder like what opinion do you have on June's question. Thank you.
Nathaniel: Sure. So because I'm operating by myself right now, certainly that's not the desired long-term goal here. But as I was looking into the problem space, examining the use cases in terms of remote attestation outside of hardware roots of trust and all that stuff, I was not extremely confident in my own ability to create sound protocol decisions and so I came across Proverif incidentally during my research and I've been using it actively as a QA kind of tool. So I'll come up with an idea, I'll do a bunch of research, I'll go through an implementation process, I'm like, okay, so at least the code works, now let's go put that back into my Proverif model. And before you released your model to the open source, it was just my own handmade stuff, but I was double checking, oh okay, this isn't going to work, Proverif found an attack. Now because you have a model that is released with a published paper coming up, that gives me a lot more confidence. So I don't have any skepticism about the attacks. I do have skepticism about intra-handshake being completely unsecuring because it looks like my models say otherwise but of course we're going to have to go on list and talk back and forth to figure out exactly, you know, where exactly the balance is here. But that's my that's my position, that's how I've been working through this.
Osama Abbas: Yeah, thank you very much. I think the the code that we will share for the relay attacks, that's not yet in the AsiaCCS paper, that was in the ACNS paper, so we will hopefully release it very soon so hopefully that would be helpful then I can look into your code, you can look into my code and then we will reach some kind of agreement. Thanks very much for all the work.
Nathaniel: And thank you for the opportunity to present. Thank you.
Hannes Tschofenig: Thank you very much Nathaniel, that is super especially given that it is your first presentations. So welcome and thank you very much for your contribution to the SEAT working group. Looking forward to seeing more of you on the list, more of your contributions and presentations at the at the following meetings. Thank you.
Okay, and now we move to our next presentation, which is exported authenticators. Tiru, Osama, which one of you will be driving the slides?
Osama Abbas: So I will do first and then we will keep switching between, sorry for that. So that will be—
Hannes Tschofenig: Okay. No worries, no worries. Just let me know if you want me to pass over the control to Tiru.
Osama Abbas: Okay. Sure. Thanks. So hi again. This is our X-PAT draft, the first draft of the SEAT working group. Sorry, so we are a team of Thomas, Tiru, Yaron, Hannes and Jonat. And I and Tiru will present some parts of the draft, what we have done since IETF 124. So I'm going to describe about the community interest since IETF 124. So we have four different companies: GFO-GH, Elixir Europe Pavel is doing the development there, H-less Marcus is doing the development, Osama, Ayub, and Flashbots SpacJohn. So we have four different developments that will come out and hopefully we will have a lot of opportunity of improving the specification and seeing where the problems are and seeing what the best way is for the development to proceed. CoCo's AI as I mentioned in the previous talk, they have acknowledged the attacks, they have published their plan to move towards post-handshake and then there are four drafts, four internet drafts which are using our protocol already. Three of them have it published and the fourth one is in the editor's version, I have the link down there. And other than that there is another draft which has made a public commitment, I have put the commitment link in there. This work was cited in the CCC response to NIST request for information on AI agents and it was the only attested TLS protocol which was cited in there. Other than that I had an invited talk from Global Platform where they were interested in the attested TLS topic and attestation in general, we presented our draft there and finally in several of other meetings of the CCC attestation SIG which we by charter are required to coordinate with and other forums, reputable forums like FOSDEM, Linux Plumbers Conference and GFO-GH, it has been presented several times and now I would request the chairs to pass the control over to Tiru, please.
Tiru Reddy: Thanks Osama for the start. Can you hear me?
Hannes Tschofenig: Loud and clear. Go ahead.
Tiru Reddy: Wonderful. Thanks. Yeah, so this document pretty much relies on RFC 9261, it extends RFC 9261 by adding new extensions. A quick recap on RFC 9261 is is basically a post-handshake authentication mechanism. It basically uses authenticator request and authenticator to send a certificate request and to get the entire certificate, certificate verify and finished. It's relying on the TLS exporter to basically derive the handshake context and as well as to derive the HMAC key for the finished messages. So pretty much this draft is extending RFC 9261 to convey the evidence or attestation results.
So to meet the charter of the SEAT, right? I mean I mean even without meeting the charter of the SEAT from day one, we have been since this draft has been even before the working group was created, we have been doing changes to the to this document just to make it post-handshake, so the intent was never to modify any of the TLS handshake protocols. And if you look into this example, the client is basically asking the server to provide attestation evidence or results, so it would basically send an authenticator request and the server would provide the evidence back in the certificate message with the new extension defined in the document. So one difference that I think Osama has highlighted in the previous deck is that by the time this attestation is exchanged, the the client and server authentication would have completed as part of the TLS handshake and this is an additional exchange that would happen to do the attestation in addition to basically reauthenticating the server as well because we are piggybacking on the certificate messages.
Some of the key benefits that we see from this document is it's a simple clean solution, it requires minimal changes to TLS and to integrate remote attestation. Osama and team have been doing the formal analysis and so far he has not identified any threats that would ask us to change this document. We're just adding new TLS extensions as I previously said and we don't modify the key schedule. RATS currently supports two models, one is the background check and passport model, both the models are supported in this document. And the most important functionality that that interests me is basically the re-attestation part, especially for long-lived sessions. For instance, in 3GPP networks, we have most of the sessions are quite long-lived and we would like to see a re-attestation done periodically. Tiru, we have question from Jonathan. Would you like to take it now? Sure. Jonathan go ahead.
Jonathan Hammell: Hi. Um, so I just had another thought. The nonce that you're— we didn't use the client— the certificate request context as a nonce, or we didn't model it as a nonce, and you actually would only— if you use it as a nonce, you only get freshness for one side. So the server, I think it was in your diagram, you could send them the same certificate request multiple times and they wouldn't notice because you only get a nonce in one direction.
Osama Abbas: Ah, yes. Just to be on the same page. So the figure I'm showing here is the server as the attester, so there is only one party being attested and you could have also the other party being attested, meaning mutual attestation. In that case, there would be similar message like the authenticator request going from the server to the client and that will contain the nonce from the server side to the client side. So the kind of thing that I am showing here, authenticator request would be then the same for the other one. Does that make sense or did I get it wrong?
Jonathan Hammell: Yeah. I I mean it makes— I can't see an obvious an obvious attack, but just like we never modeled that as a nonce and so it's not obvious to me that that would give you freshness in—
Hannes Tschofenig: Unfortunately, we are out of time, we need to move on to our final presentation of the day. Just one point I'd like to make, Osama, in terms of adoption call: first we need to adopt use cases and then judge any proposal, specific proposals, against those those use cases. Yaron, over to you.
Yaron Sheffer: Thank you, Yaroslav. Can you actually hear me?
Hannes Tschofenig: Loud and clear. Go ahead.
Yaron Sheffer: Thank you. Okay, so I'll be discussing the early attestation draft. We have made very significant progress since the last discussion of this draft. We got a very strong message that some people at least like the approach but that we are clearly not within the SEAT charter and we'd better do something about it, so we did. The new attestation message was replaced by an extension to the certificate message, also called attestation, and the binder was rewritten so now it is wholly decoupled from the TLS key schedule, so there's no reason to suggest that we are changing the key schedule. We believe that this brings us completely within the definitions of the charter. In addition to these two major changes, we looked at some of the design options for attestation and I'll go into details later and in particular the internal architecture between the TLS stack and the TEE. Yaroslav, sorry, your your voice is really choppy now. Maybe you want to stop your video and save some bandwidth. Sure, let me do that. Okay, now now it's better. And also, do you want to take questions now or go through the slides first? Let me at least complete the slide.
So we have discussion diagram on how the TLS stack and the TEE interoperate and what that means for some of the finer points of security of the protocol. And lastly, and this is not on the slide, I'd like to thank Nathaniel for basically working with Proverif to prove that our binder design is sound and does in fact fulfill the security properties. Yes, Osama.
Osama Abbas: Right, so I have a bit of a concern on when you say that it's within the SEAT charter. The reason is that basically you are using the key derivation functions, right? And it doesn't matter whether you use it for a nonce or wherever you use it, I believe that if you are using these key derivation functions, they are basically part of the key schedule. And I don't fully understand why that is the case that you claim that it is within the SEAT charter while it says that we will not modify the key schedule itself. Can you explain that, please?
Yaron Sheffer: This is totally on terminology and in fact we do call out explicitly in the draft that even though it's called secret, it is not a secret. So I'm not sure of the point you're making. No, this is not making any sense to just the TLS key schedule.
Osama Abbas: So I mean I'm giving you a counter example to what you are saying. I'm saying that early secret is derived via two inputs, both of them are zero and zero. So that's there is no nothing coming from the key schedule into it, that's the starting point where it starts and we we still call that early secret because it's using these KDF functions and all that nice things. So I wonder why you why you don't consider that these functions so as the part of the key schedule itself. So I would like a bit more clarity on that.
Yaron Sheffer: I think we have a disagreement on what constitutes a change to the key schedule and let's leave it at that. There are two two more people in the line and only four minutes remaining. June.
June Park: Can you go back to the page five? I will try. This one? Yes, so I have a question about the the nonce because you see that there's nonce goes down, but there's no nonce goes up. Does that means that you have a cache of the nonce in the early attestation adaptive layer or you included it in the signed evidence?
Yaron Sheffer: We included it. So, yes, we include it in the signed evidence. It's a nonce that's used while signing the evidence/attestation results.
June Park: So in that case you do not need to include the nonce in the CMW nonce because it is already inside the signed evidence.
Yaron Sheffer: You're probably right. You're probably right. Yes.
June Park: Okay. Thank you.
Yaron Sheffer: Nathaniel.
Nathaniel: Hi. I just wanted to clarify that yes, I did do the formal modeling. I am not an academic and so I have released the models to the public for public review. It's not exactly orthodox with formal modeling but that's the disclaimer. But in terms of phrasing and wording, considering the the hang up on the use of the word derived secret, a proposal change to the draft is just to use just cryptographic primitives that aren't being called from the TLS thing. It's still a public commitment, it's not a secret, so a change of phrasing would have the exact same security properties so maybe that's a way to approach it.
Yaron Sheffer: Yeah, we're just being very conservative on what primitives we are using, but let's have that discussion offline. You may be right, it may be a good solution.
Hannes Tschofenig: Great. Thank you very much, Yaron, for your presentation and thank you very much for staying on time or ahead of time. So thank you all the presenters who presented today. One thing that I would like to highlight is use cases really what should be defining the solution that we will be developing within the working group, not formal analysis. Formal analysis is something that we would like to optionally see happening later, so use cases would be defining security properties of the solution that we will be developing, not other way around. It's not security properties defined in use cases. So I kindly ask everyone to please take a look at the use cases draft, see if you're happy with the use cases, is there something that you strongly believe should be added or modified in the document, and then we will be taking a working group further once use cases have been adopted. So, Nancy, anything from your side?
Nancy Cam-Winget: No, I appreciate you running all the meeting while you're there.
Hannes Tschofenig: My pleasure. Thank you. And thank you very much for remote participants for being with us regardless of faraway time zones where you might be. Thanks again and have a good rest of your morning, day, evening, night. Thank you.