Session Date/Time: 21 Jul 2026 09:00
[00:00:55] Yaroslav: Hello, everyone. Thank you for joining us on time. This is SEAT working group meeting. So if you are in the wrong meeting room, you're still welcome here to learn all about, secure evidence and attestation transport. My name is Yaroslav. I am a co chair.
[00:01:18] Nancy: Good morning, everyone, and I'm Nancy Nancy. I'm also co chair.
[00:01:23] Yaroslav: Great. So if you have not joined MeetEcho On-site tool, please do join, even if you are not planning to ask any questions or participate in the chat, that will help us with capacity planning for the next meeting. So please do join the on-site tool. And if you are joining us remotely, well, thank you for joining. We have a really busy agenda today, but before we dive into, a reminder, this is second day of IETF. You might have seen Node 12 already, but it is still important. Please don't be a jerk. Please respect others. Criticize ideas and discuss ideas. Don't criticize people. I know that attestation is a very hot, passionate topic for some of us, so please stay professional. Also, when it comes to intellectual property rights, if you know something, say something. So you if you if you're aware of any IPR associated with an item that we're discussing, you have to disclose it. So agenda for today. As I said, we have a busy agenda, and we will be enforcing timings. So we will be running timers for all the sessions, all the presentations, and we will have to cut off if we run out of time because we have a loads and loads of things to cover. But first, an exciting update. We have our first working group official document. So use cases draft is adopted. So congratulations to everyone. Thanks to everyone who contributed. We do not intend this document to become an RFC, so it will stay as a working group live document that will guide potential protocols to implement those use cases. So to streamline progress, Eonut, moving forward, will be the only document editor. So thanks everyone who contributed again to this document. So there is no plans to progress it outside of the working group. And Eonut's, as an editor's job, will be to make sure that discussions on their mailing list and working group consensus are properly reflected in the use cases draft moving forward?
[00:03:54] Nancy: Yes. So the draft will now be posted in the SEAT git repo. And so Yonit, the editor, will have the pen. But we do encourage those who wanna provide feedback to do to put the issues there so that it's there for the record and Yonit can then address them accordingly and work through that process.
[00:04:16] Yaroslav: Right. Yes. So that document is already on the GitHub. So we have our working group GitHub, IETFWG SEAT. Right now, there are two repositories there, our charter and the first adopted document. So we will be using that alongside with the mailing list to progress the draft. And with that, let's move to our first presentation, which is update of use cases from Yonit. Yonit, I will pass you slide control. Please take it away.
[00:04:52] Yonit: Okay. Thank you. Just to confirm, can you hear me?
[00:04:56] Nancy: Yes.
[00:04:57] Yonit: Okay. Yeah. Great. Right. So, yes, I'll be talking about the use cases and security goals draft, the one that's just been adopted. And I'm gonna give you a brief update of what things we've been working on since ITF one to '5. So just for background, for those who've not heard or seen the draft before, we're essentially trying to condense a set of reference use cases that are of interest to the seat working group and trying to to settle the stage for for the protocols that are to be implemented. Based on those use cases, we're also trying to establish a set of common security goals for the designs produced by the working group. And it's worth noting here that since the last ITF, we've reframed properties as security goals. So that's been changed in the name. In terms of the actual changes that we've made since since the last meeting, we've we've had a bunch of reviews coming on both on the mailing list and privately or or on the GitHub. And these reviews have have raised a bunch of concerns primarily about the quality of the draft, about the quality of the the use cases in particular, and the fact that they're not particularly consistent with each other in the way they're written up and how they're connected to the security to the security goals. There's been some lack of clarity there. So what we've been doing to try to address this was to well, partially to reframe security considerations and goals, take things out of the security consideration section, redistribute it for the documents since this is mostly about security anyway. We try to address some of the concerns about, for example, runtime attestation and the the requirements for for runtime attestation and then how negotiation should be done and why. So one of the things that the chairs have mentioned is that there's been, say, slow progress on addressing some of the issues, and we've we've tried to to work together as an authoring team. But this had resulted in a bit of a gridlock given our split views on what needs to actually be encoded in draft and how to encode it. And also due to the fact that we filed a fairly fuzzy threat model to work with and fairly unclear boundaries between seat and other working groups around. So that kept the discussions looping. So in order for the draft to be adopted, we we had to freeze a number of outstanding changes that were being discussed. In terms of what what issues we were discussing before we froze them, we had a number of use cases that we were trying to fit in. So one would be around actor identity continuity, where actors could be either people or AI agents that work on multiple platforms and perhaps our relying party would be interested in tracking continuity of state across those. We also had a use case around identity injection for WebPKI, so for containers in particular, and also for supporting TLS terminating proxies, doing that station over TLS terminating proxies. In terms of security goals, we had we had been looking at expanding the, let's say, target area of the binder. So, basically, what what we bind to to create that secure connection between remote attestation and the secure channel and expanding what is included there as a mitigation for certain classes of attack. And we're also looking for adding support for diverse trust boundaries. So whether this is a split model where where the tester is split between a t and outside the t or for supporting, again, the TLS terminating proxies and having the tester behind that proxy. In terms of next steps for the draft, I think we need to do a lot of clarification work to first, to clarify exactly what what the use cases represent and what what we're trying to fulfill for them and what the relationship between these use cases is and the security goals. So it'll also be good to clarify the exact treadmill or treadmills, the kinds of adversaries or attacks that we need to defend against, and then looking at the security goals and trying to link those to to the models and attacks that we're trying to protect from. And, also, we we would really benefit from having a clear boundary between Seat and the other working groups and trying to figure out which problems need to belong to which groups. So what do we need to divest to TLS or to Rats or Spice since we already rely on a lot of, let's say, base protocol stuff and also extensions like EKU or, yeah, other things from other other working groups. So it would be better to perhaps not try to solve everything. See so that's that's my presentation. And if anyone has any questions, happy to take questions on.
[00:11:09] Yaroslav: Any anyone have questions for Yonut? Tiru.
[00:11:22] Tiru: Thanks, Yonit. I think I I like the direction that of the next steps. I think now the more emphasis is gonna be on adding these new steps basically than adding new use cases, which may not bring in unless they bring in new security requirements. Right? So I would prefer to contain the requirements at this stage use cases at this stage and focus more on the requirements, threat models, and clarify expectations on the on the existing use cases itself unless we have, like, some of the new use case which brings in new new requirements that the seat working group needs to look into. Thank you.
[00:12:05] Yonit: Yeah. I I agree. And I think one thing I didn't mention was that maybe apart from boundaries between working groups, we should also have boundaries between documents more clear. I think Nathaniel is presenting an architecture draft, so it would be good to define very well what goes in where.
[00:12:25] Yaroslav: Mark?
[00:12:26] Mark: Yeah. So just a ten second summary of what I put on the mailing list today. A lot of the customers likely customers for this technology would be large enterprises and regulated enterprises. So you need to worry about things like single points of failure and regulatory requirements around trust anchor separation. And I think putting them make making them prominent in the use cases and the architecture would at least help steer development.
[00:13:03] Yonit: Sure. Thank you, Mark. Happy to take that input and keep you in the loop.
[00:13:10] Yaroslav: Okay. Thank you very much. Let's thank you, Yonit. Let's move on to the next.
[00:13:18] Nancy: Appreciate you being on time. Next is architecture.
[00:13:27] Yaroslav: Okay. Nathaniel, you have control of the slides.
[00:13:34] Nathaniel: Alright. So thank you for coming today. So the the seed architecture draft is put together as as a as a document designed to gather a sort of a a bottom up and a top down synthesis of all of the input that has been shared with the working group over the last seven or eight months since its inception going back to the and the work for years that actually led, up to this. And finding, a single place or a single home for a lot of the different vibrant discussions that have happened on on the mailing list, where, when a discussion has happened and, the the working group is minded on an idea, it can be, locked into one place, and then, be, brought to, future drafts that are going through this. The that's that's what we're, looking for. So, I am talking ahead of my own drafts, or my own slides. So The SEAT architecture document. You have one security argument. Again, there is a lot of discussion, happening, on on list, in discussions about, exactly what needs to be attached to what, other thing, and that is a discussion that is ongoing. But once that is figured out, having that in a a single draft makes it so that we're not having to worry about, oh, is, the post handshake document making the right arguments here and does the intra handshake draft doing it over here. They can just be focused on, you know, the important part for them and have a a single home for, what the actual goal is for remote attestation over secure transport. Cross cutting concerns, don't have any other home. The use cases draft, especially since it's not going to be, leaving the working group. There's certain properties that, the authors believe are really important to nail down, get correct, get well vetted, well argued on the mailing list to a high level of quality that, industry will take seriously and then leave the use cases document to focus on, you know, the the specific properties or goals of that particular use case without having to boil the ocean for every single, unique, use case that might be in there. There's different, requirements for IoT versus, confidential computing, that sort of thing. So taking, creating a separation of, concerns is kind of the goal there. One coherent answer to the IAB statement. So the IAB, statement is, the one regarding, privacy, regarding, remote attestation. That is something, again, similar to, the other arguments here. You have the one argument that's well argued by the working group. Consensus, lands on a specific, okay. This is what we're going to be doing, and then, you don't have to worry about the the different drafts, drifting or, trying to reiterate the same concerns over and over in the use cases document. And solution drafts need a shared vocabulary. So between the different documents that are shared with the working group, including formal models, my own draft that I presented at the last meeting, the other two individual solution drafts, they all have different key names. And if you are very familiar with a particular draft, you are used to a very particular set of keys and what they mean and what they're supposed to do, but to an outsider, that might not be so clear. And as the working group may move on from TLS to, SSH, IKE, or other documents, having a, set of keys or names, that the working group all understands, collectively what these are what they're supposed to do, is, something that I think, would have an incredible amount of value to it. So, the one security argument, this slide here is not, here to be the final, litigation of, you know, the the final decision here, but the the point is that, we have a different way of, binding, evidence with a connection, depending on what the timing window is. Different use cases are going to have a preference for whether or not it's, you know, intra handshake or post handshake. If you have a cached attestation result and you're looking at rapid assurance where you're happy with what an attestation result can get you, the saved round trips and an intra handshake attestation or an intra handshake, binding, has a specific approach that's unique from post handshake. But when it comes to the individual solution drafts, regardless of, you know, if it's, Lake RA or TLS or something else, having a single place where, the working group has, well argued, well vetted, and reached a consensus in a single place, I think, would serve the community well. Cross cutting, properties again. So the points here are basically all the the same thing. We have, different approaches for binding a tested state to connections, the arguments for per connection freshness for evidence versus attestation results. The seat charter is actually mandating per connection freshness to an activation result, figuring out exactly what that means, how it's interpreted, what that means for solution drafts. Litigating that in each individual solution draft, doesn't make a lot of sense. And, finally, the coherent answer to the IAB statement. Now this is, again, with privacy, depending on the approach. IntraHandshake has might be presenting evidence immediately to a relying party, but the relying party might have no business, knowing certain sensitive data that might be in evidence. So that can be addressed, in a couple of different ways, including with, say, object level encryption. So completely decoupled from the actual transport layer, whether it's TLS or something else, object level encryption following the individual draft that was, brought forward to rats, with the privacy framework. That's one way to do it. Another way to increase privacy, might be for selective disclosure, Alice Spice, with an attestation result. Depending on the use cases, they might take different approaches, but having a single place, a single home where the working group is said, okay. We are going to make a commitment to privacy, and these are the ways that, it could be approached and go, talk to the rats people about specifically what that might be, or if you're interested in selective disclosure, talk to spice, that sort of thing. And finally, again, naming things is hard, And these key names I picked, which are different from the key names that are in the other drafts, including, the draft that I had presented for myself, last meeting, and I'm already eager to change the names again for whatever the zero one release might be. This is something that, again, needs community input. I think, we need to understand what these keys are, what the responsibilities are, and have a common understanding about, you know, what the relationship is to the transport and to remote attestation so that, you know, three years down the line, when somebody's proposing a new solution draft, they can say, okay. This is how I'm going to talk about my solution, and people aren't gonna have to guess about if e k means the ephemeral key or the endorsement key or, you know, what what the heck is h b HBK. Right? So, figuring that out, landing on, what those names should be, and locking that down in a single document that the working group has, again, well argued, I think, is is valuable to the group. So, that's the basically, the the next steps here. I'm anticipating that there will be ongoing discussions regarding key names. If it's not on the mailing list, amongst the authors, there is the question about, deceit charter in terms of what it means to have attestation freshness or or per connection freshness, for attestation results versus evidence. And there are solutions that have come to mind for me that the office are like, Kate, you can't put that in the architecture draft, but, you know, figure out what those what that separation is, what the, higher level description of, what this interpretation of the charter means versus, you know, letting the solution drafts, as they are adopted, you know, actually implement what makes sense to them. Again, privacy, a lot of that's going to be downstream or rather upstream to rats, but, we might also, again, want to reach out to spice the formats regarding solution drafts and that kind of thing. And finally, we are definitely open to ongoing discussions, suggestions, and input. So that's the end of the, presentation, and I am quite happy to, take on questions and feedback.
[00:26:07] Yaroslav: Thank you. We have Usama first in the queue.
[00:26:16] Usama: Thanks. Sorry. Usama to you, Dresden. It was interesting. And I see a little bit of overlap between what I have in my draft intro versus post. But if you go back to slide seven first, I saw a little bit of a contradiction to what you had in slide number six. That is to say six was kind of arguing that you don't want to go to solutions and you want to stay to properties, but it's very clearly going into the solutions intra and post straight away. My technical comment here specifically is, like, on the left side when you have the context, the client in TLS 1.3, the client hello message is sent unencrypted unless you use encrypted client hello. And the server in this case is malicious if we take the server as the as the attester. And then the combination that you have here for client hello and server hello both are available to the adversary, meaning the adversary itself, server hello, generating server hello, and the client hello being sent unencrypted. So this binder that you have on the left side, basically, and depict depicted here as context is not really providing you something which the adversary cannot generate. It can generate both the client hello is public, server hello, it can generate on its own because the adversary itself is malicious. Right? So that's the confidential computing, specifically about the confidential computing scenario. So that's one technical issue. In the next slide, you had you talked about the slide eight, please. You talked about here going to other protocols that's nice and is supported by the charter that we might go to other solutions, but that's not currently in the charter. That could be if there is sufficient interest or something like that. But you I I really want to criticize on a specific point you make about ad hoc protocol. It's not possible because ad hoc RA is an adopted draft of the lake working group, and that work we cannot do even if we expand it over to different protocols. That work should not be done within this working group because that's already an adopted project, adopted draft of the lake working group. That work should happen there. We could go to IPSec or we could go to, let's say, other protocols, whatever the working group will decide and if there is sufficient interest and so on. That's, I think, a very nice direction that we develop one solution which is applicable to many protocols. But the issue here I see is that at least we should not go to overlap the, like, the things which are really adopted. If it were not adopted, we could make a case, like, in collaboration with the lake working group that, hey. We we we might develop a solution that might be good for you, but it's being adopted. It's being worked upon. It's in the like, it's a much mature document. So so ad hoc, we should really not take into account in my opinion. So then if you go to slide number 10, there you talked about the terminology. And I wanted to point out that there's a very well vetted set of artifacts by Kartik et al, and in a very good conference of security, security and privacy, which is one of the top conferences of and that's well vetted by the TLS working group. We should really use these artifacts rather than developing our own vocabulary, so to say. And confidential computing consortium itself from remote attestation side, they have done a lot of remote attestation artifacts. They have set vocabulary. It's already, like, vetted in a number of, how to say, like, SIG meetings, attestation SIG meetings, and vetted by a number of good conferences like and so on. And I would suggest that we take these two things which are available to us readily rather than developing a new technology, new terminology, which might create a lot of confusion and conflicts with what others have done in the community.
[00:30:49] Yaroslav: Oh, Osama, we are running out of time. Okay. Sure. I would encourage you to open issues in the GitHub repo with your points so that they would be addressed. Yaron?
[00:31:01] Nathaniel: So I just wanted to say that, yes, absolutely. I I hear all of all of those points, and I'm happy to continue those discussions on list.
[00:31:15] Nancy: I mean, keep in mind, this is not an adopted draft, so keep the comments on the nay list as well and open issues for the authors. K. You're gonna have to keep them brief because we're
[00:31:26] June: I will.
[00:31:27] Nancy: Go ahead.
[00:31:27] Tiru: Do my
[00:31:28] Yaron: best. So first, I'm supportive of this work. And then two quick comments. One is, I think it's it's a good thing to try to unify terminology. I think we should not go as far as trying to unify key names because that brings you directly into solution space. And if we ever come up with a third solution, they might have their own keys. And and so trying to unify or to correlate keys across solutions, in my mind, is a is a, well, a fool's errand.
[00:32:08] Nathaniel: Yeah. I I I hear you. Just having descriptive names of, you know, the identity signing key perhaps, but defining what what interactions there are between the different parties and what is signing over what is is really what we're wanting to nail down. For example, there is a very specific difference between what signs over the evidence versus what signs over an attestation result. And the formal models that I've been working with, put those two things together, where it's meaningful to separate those things out. But, yes, I can definitely understand. I've already come up with my own name for a different key for binding attestation results session binding. And so I definitely hear you. So we'll continue that discussion.
[00:33:06] Yaron: And second comment, your draft and actually other other drafts in this working group put the focus when talking about freshness on the exact moment when the evidence is signed. And I think we keep ignoring and it's time we stop that. We keep ignoring the time of measurement. And measurement might happen very early on at boot time then be cached essentially forever in the server. And we should at least say something about that and not only talk about the time of signature. Thank you.
[00:33:52] Yaroslav: Thank you. Thiro, please be concise. We are out of time.
[00:33:57] Tiru: Thanks. I'll keep it short. As someone who's working on both the solution drafts, right, I think irrespective of what the working group picks, right, I think this architecture draft is quite helpful on all the bullets that you have mentioned. Yes, there are issues, but I think we can work through them.
[00:34:12] Yaroslav: Thank you. Thank you. Thomas?
[00:34:17] Thomas: Yes. Two points as a co author. Firstly, we are here because we have realized that the use case draft, even with the security goal extension, is not sufficient as a breach to the solution drafts. So this is a document that sort of captures and names concepts and patterns and we think is very useful and I would argue is an essential addition to the working group toolbox. Secondly, think if we move this forward, as I hope, there is some coordination with the use cases draft that is needed to avoid overlaps and conflicts.
[00:35:01] Yaroslav: Thank you. Thank you very much, Nathaniel. We now moving on to our next agenda item.
[00:35:14] Nancy: It's the introduction to security and
[00:35:17] Yaroslav: Yep. Yep. June, just a moment.
[00:35:22] Nancy: You can come up while he brings up the slides.
[00:35:28] Tiru: Yep. Yep. So
[00:35:33] June: hello. So this is June from Huawei. So this is the version one of the the selection of the test that try to balance the security and deployed ability. So usually, I mean, that in every draft we have the section about the security consideration. But in the practical, so we also need to keep thinking about the balance between the security, which is the outbound, and the packet deployability. So for the attest TRS protocol, so naturally, we have attestation and the TRS, need to consider the binding between them, whether it is secure enough to ensure that the the attestation, the evidence, and attestation allows are fresh enough. And also that if you want to take into consideration of the privacy, you need to have some technology like the the zero trust, but it depends on the scenarios. So for some certain scenarios, maybe the the user does not concern at all about the the privacy. And so we can use the formal verification to see that whether there's some some leakage of the information, whether there's some bugs of the the protocol. But remember that so for any complex systems, so it is different, particular code to guarantee that the formal analysis is complete because they always have some cases and you have some cases it does not take into consideration in your formal analysis. And also, we need to consider the attack window so that during the time of the attestation and the time that you need to establish the TRS connections, there will be some windows that it is possible to reduce some old evidence so that you can treat the server side. And so in the practical deployment, so one phenomenon you need to consider is the middle box compatibility. So I remember it's one year or two year before so that we have the problem to access the the site of the IETF because when I enabled the post quintu features, but such kind of features will be blocked by some older servers so that they were stripped off those post quantum features. So I have to disable the post quantum features to to to access the the IETF site. So the same phenomenon will happens for the ATS, on the Internet, so that even you have some implementations to to to to for the to consider both TRS and attestation, but some features will be dropped off by these firewalls or the load balances. And so for some implementations, so some libraries is not well supported and impractical, so we created some some problem. And so for when you consider that, when you have the the IoT devices or you have some very strong servers, they will they will have different time to do the attestation and the signing, and we all have the impact on the latencies. So for some services, it's latency sensitive, so you need to consider the implementation of the I a t attest protocols that fit into such scenarios. And so when you consider that, so you implement the verification and depends on where you implement the verification. So in some cases, it will increase the operation complexity. And so for some implementations, you have the potential leak of the informations. So these also need to be considered. So currently, so as we know that we have certain three categories of the attests, pre handshake, intra handshake, and the post handshake. So in general, we can see that in the secret part, so where how well the the the binding between attestation and the tiers is one thing to be considered, and how large is the attack window need to be considered is also another thing. And for the deployabilities. So in terms of the pre handshake, so it can prevent the DDoS attacks because you do not need to establish test connection because when the attestation fails, you you you reject it directly. But the the bad part is that usually you need to rely on pre established channels to deliver the attestation information. And so I think that so so for instance scenarios, for the for the network admission controls, it fits for scenarios. And for the intra handshake, the good part is that it does not introduce the the the extra runtime trip for the after the the because it can do the attestation and the tears at the same time. So it does not need to one more handshake. But the the bad part of it is that for the general Internet, it may have the problem with the compatibility of the middle books. And so I think it is more fit for the controlled environment for for the private networking enterprise, in or some protocols with naive support that you can embed it such kind of evidence into the TS connection. So for the post handshake, I think that the good part is, okay, is you do not need to change TS protocols so it can fit for the the general Internet, but it introduced extra latency so that I think it's good for the general Internet. Now I've seen that. Also, one thing that we need to consider is that when the attestation fails, so there's two kind of failures. One is hot failure that, okay, if I do not pass the attestation, I cut off the connection directly. And another is the soft fail, so that even it does not pass the attestation, so I will reduce the service levels, so as long as the user is aware of that. So this is examples that so how we choose the attest PRSPURCOL so that so it's from starting if so we can choose the network, and so we are targeting for the network added mission control. So we choose the pre handshake with hot fill. And so if it is not, we will choose the post handshake with soft fill. And so if we can update the TS stack, so we can use the intra handshake. Thank
[00:42:57] Yonit: you.
[00:42:58] Yaroslav: Thank you. Paul?
[00:43:01] Paul: I was just asking if you're gonna take questions during the slides, but I guess this is the last slide.
[00:43:05] Nancy: It is.
[00:43:06] Paul: Okay. So one comment I do wanna make is that for the intra handshake, you could get library support in common TLS libraries because it's part of a TLS handshake without having to make too many application modifications. Like, if I can tell the library, this is my PKI's this is my PKI trust anchor for attestation and this is my web PKI trust anchor, I can just use the library to make the call. And the application doesn't need to know much. When you go into post handshake, now it's all up to coding it in the each specific application that needs to support this. Right? So you don't add that in your comparison, but I think that is the single biggest issue here why you could prefer intra handshake.
[00:43:52] June: Yeah. So so, I mean, that this is one example of the customer into consideration because taking into consideration is quite different implementations of the intra handshake and post handshake. So might be more complex compared with this gram.
[00:44:14] Usama: Thanks. It was interesting comparison. I have a few comments. Slide two. If you go back to slide number two, where you were mentioning about formal analysis is not complete. I think nobody in academia actually is saying or ever has said that, hey. We are done with it, and that's done. So there are vulnerabilities which are found often even in TLS. We have these CVs and so on. So it's never nobody I'm aware of has ever claimed that formal analysis is done. Now we are finished, and now this is all over. So I don't think that claim is correct. So we always say that we have a specified threat model. And under that threat model and under that specific formal model we have developed, there is this vulnerability and so on. So I didn't see that as a fair critique. So formal analysis gives you some guarantees, but or formal verification, as you say, but it doesn't necessarily eliminate all the vulnerabilities it gives you under certain conditions.
[00:45:17] Paul: You talked about I
[00:45:18] June: can answer this question. Sure. In general, for the general scientific research. I mean, so when we write a paper, we make some assumptions. Okay. So this is the the the the the assumptions, and we do this experiment. We get the result. So remember that we do this kind of testing in certain constraint environment. But these may not really reflect the truth. So it's same for the formal verification. So you will do some modeling and to reflect how this protocol really works. But in some cases, when you do the formal verification, you based on your own understanding. So may not really match the real case. So this is the part that not avoidable. So it will give some hint of what might happens, but you cannot totally 100% sure that. So you say, okay. I've proved that this protocol is is 100% secure. You cannot prove.
[00:46:16] Usama: Sure. That's what I I think we are on the same page we are saying with different words, but that's what I said. Like, it's in a constrained environment, and nobody actually has claimed that it's perfect. So everything has limitations. For instance, like, in formal analysis using these symbolic tools cannot go into the cryptography. And similarly, then you have the cryptographic tools like the cryptoverif and so on, where you actually check this cryptography, so things are actually like kind of complementary, and I always say that it's basically four methods by itself is a complementary tool rather than saying that it's it's just one tool. So it's Yes. So so that's So we are on the same page, just to say.
[00:46:59] June: I say that it's useful that it's it's included in the offsets that when you consider the security considerations. So, we'll give some hint that, okay, how good, how bad this protocol. But it self cannot be the only point to guarantee the security property of
[00:47:17] Usama: Right. It cannot guarantee, but then when there is a vulnerability, it can guarantee the vulnerability. So second point I wanted to make was the next slide where you are mentioning that and Paul also made a comment that you have to make it for a specific application. That's not correct. SCONE is has developed this post handshake solution, and it's used widely for practical implementations. And you do not have to change a specific implementation. You have a runtime where you have those changes, and that runtime is taking care of all the things. And you don't need to change your application specifically at all. The application remains the same as it is without any changes, and that runtime after the TLS connection is taking care of this establishing the connection, getting the evidence, getting it verified, and so on. So the detailed analysis and practical evidence exists that you do not need to change anything in the application at all. So that's something that I wanted to add. Of course, like, latency is one factor, but we also have to take into consideration that attestation is not a onetime impact. Like, it's if I take an evidence right now, it's applicable only right now. Doesn't make any claims what will happen just a second after. So then I need to do another attestation of another claim set and another signature to say what happened afterwards. So just a single latency point because there is a there is another round trip, I don't think that is realistic. We have to take into consideration that it's a continuous process, which one continues over the time to take into consideration at different points in time. Thanks.
[00:49:01] June: Yeah. So so for actually, for the latency is interesting problem because
[00:49:05] Nancy: You're not
[00:49:05] June: that's two kind of latency. One is the latency for the first time establishment, And it's the also, it is the latency where you have the continuous service. So sometimes you can reduce attestation evidence that to in order to have the good trade off between the performance and security. So so I would say that it really depends on the implementation of the protocol.
[00:49:28] Yaroslav: Okay. And I'll be real brief in twenty seconds. If you go back to previous slide Yes. When it
[00:49:34] Nancy: come as an individual.
[00:49:34] Yaroslav: I'm speaking as an individual. Yes. Thank you very much for for this. So you say that middle box may strip unknown TLS extensions or block non standards. I mean, in TLS 1.3, middle boxes essentially has to establish a separate TLS connection from to the client and to the server, so they cannot really not block unknown TLS extensions because they form separate connections.
[00:50:01] June: So, that's why we see so many interrupting.
[00:50:06] Nancy: Yeah. Sorry. We had to cut the queue because we're at time. So for those that have comments, just reflect those on the mail list. Alright? Thanks. Okay. Next up, early attestation. Is that you, Tito? Or Hannes or Doug?
[00:50:27] Tiru: No. That's not the one. No.
[00:50:30] Yaroslav: That's That's not the Which which one?
[00:50:32] Tiru: I meant to present the first part in the.
[00:50:35] Nancy: Oh, that's the one.
[00:50:37] Yaroslav: We are doing TLS details. Yep. That's the one.
[00:50:46] Nancy: Okay. So how are you splitting the time?
[00:50:49] Tiru: We'll manage. We'll work with you. Okay.
[00:50:53] Nancy: Well, because we're gonna have to flip slides too.
[00:50:55] Tiru: No. No. It's the same slides.
[00:50:56] Nancy: That's Oh, no. That's a the same thing.
[00:50:58] Yonit: You're getting me confused with all the slide
[00:51:00] Nancy: decks. Okay.
[00:51:01] Yonit: Go. Hello again.
[00:51:05] Tiru: Let's start.
[00:51:07] Yonit: Okay. Are you okay. You're driving the slides. Sure. So, yeah, I'm gonna be talking about early attestation. So this is an intra handshake attestation mechanism. So I'm just gonna give an update from the last ITF meeting. So we've had two versions since. We had three three major changes. So the first one was to refine the attestation binder definition to avoid misuse of some some primitives available into TLS handshake. We introduced a new design option for reattestation for the client in particular, and we've also redesigned the extensions we have for the TLS handshake to align better with RFC nine eight four six. Next slide. Okay. On the attestation binder side, so this is still completely separate from the TLS key schedule. Obviously, the the role it has is to bind the attestation credentials to the TLS connection, and, also, they include the tester's PKI identity. So we've made a change to essentially push the client hello to server hello transcript through HKDF expand label instead of derived secret. This is in order to avoid abusing any of the inputs for derived secret and potentially losing some of the properties we care about since since that transcript is not necessarily secret. We yeah. So, basically, HKDF expand label is available. It's available within the handshake, obviously, and it's defined in RFC five eight six nine. So, yeah, again, we don't we do not modify the TLS protocol or the key schedule. We're just doing stuff on the sides with the transcript. Next slide. Okay. In terms of reattestation, we don't exactly define very rigorously how reattestation should be done. At the moment, we only define a set of potential avenues that we could take in the future. So draft o four adds client side at the station via post client authentication. So section four point seven point two and RFC nine eight four six. So now we have four different options. So the first one is this one, the post handshake client authentication. We've also suggested extended key updates. Also, just not having specific or an explicit realization mechanism, just reestablishing the connection or doing post handshake authentication oh, authorization using certificate update mechanism. Next slide. K. So another big change we've made is to compress the various extensions we had. So previously, up to version o four, we we had separate extensions for negotiating functionality. So we had different extensions for the server and for the client and also for negotiating evidence or artificial results. And then we also have this separate extension in the certificate message. And then version o five, we merge all of these into one single extension, the remote station extension. And this one defines how the client should encode proposed schemes for both client and the server to you to work as a testers. These cover both evidence and results. And then the server can choose one of the schemes for both itself and the client and populate them in the encrypted extensions message or in a certificate request message. And then whoever's attesting can then populate the corresponding extension, the certificate message as was negotiated. Next slide.
[00:55:08] Tiru: Go ahead. Thanks, Ayanet. I'll take off from here. Hello, everyone. I'm Tiru. I'll be talking about some of the attacks that have been discussed in the mailing list to clarify on these attack vectors and how our our analysis shows that they are not applicable. The first attack that has been brought up, I think discussed in both the architecture and other documents is the relay attack. I'll briefly talk about the attack and then how the solution that we have mitigates that. Right? The attack is basically the evidence has to be bound to the specific TLS connection in which it is exchanged so that the evidence used in one TLS connection cannot be used or replayed in other TLS connections. Right? And intra handshake evidence is, as I know it has explained, is not bound to the application traffic secret, whereas the post handshake is using the exported key material. Does the binding of the handshake transcript achieve the same per connection uniqueness as EKM? I think it's s. Let me explain why it's an s. Post handshake uses the exported key material to derive the secret, which is input as nouns to the evidence, whereas earlier discussion is using the transport hash from the client hello and server hello. The interesting part of client hello and server hello is it's unique for every TLS session. Right? The client and servers have to use fresh ephemeral keys in traditional scenario where you're using EC dashi or in case of PQC, it's gonna be the client is gonna provide ephemeral PQC public key, and the server will provide a random ciphertext, which will have the shared secret encrypted, and and the client and server also provide random values. So it's impossible for someone who is monitoring the TLS handshake, right, to basically replay the same client server random keys and public keys and create a session successfully unless the private keys have been compromised. So that's the reason we believe that even if an adversary looks into the clear text client hello and server hello, it will not be impossible it will be impossible for the attacker to mimic the same client hello and server hello messages unless the keys are being compromised. So there were some suggestions on why not use the EKM itself. Right? And we looked into that. Right? The post handshake exporter does not exist when when the latest session is happening. EKM is only derived after the handshake completes. We also looked into the early exporter with no PSK since we are not none of the drafts are working on PSK enabled. The early secret basically uses both both inputs are zero in this case, and the early exporter master secret, which is derived, has no secret input, no client server, handshake transcript embedded into that. So that's the reason we picked this alternative. And and the reason why we picked this alternative is both the peers are providing randomness and ephemeral key shares, and neither side alone controls it. So it provides both sides contribute to the uniqueness. The other concern that has been raised is when the server is the attestor, it sends attestation before the client authenticates. So any unattended client can read the claims in the server's evidence. I mean, this is inherent to the way TLS works that the the server basically authenticates to the client before the client authenticates to the server and provides the entire certificate and certificate chain. And there's been a lot of work happening in RAT's working group on selective disclosures. SDJWT, I believe, is it's how to say data queue already. This basically allows the server to decide on what claims to be exposed to an unauthenticated client, and the protocol does not mandate disclosing sensitive ones. So I see documents being discussed in the rats working group. I think the also, Mike's draft will be presented in the rats working group, which is gonna talk about the privacy framework for rats. So this draft could pretty much leverage the work happening in RATS and doesn't have to define something new. And and the third option is the server can present a compact verifier send registration result and detailed evidence states with the verifier and never reaches the client. The draft has been revised in the the the last few revisions to stay within the seat charter, and we believe it fulfills all the security requirements. And we are requesting the working group to adapt it and keep giving us comments so that we can work on and improve it. Thank you.
[00:59:49] Yaroslav: Thank you very much, Tiru. Nathaniel?
[00:59:55] Nathaniel: Hello. So leading in, to your, leader set of, slides there, and also addressing, the concern raised about, unauthenticated client hello and, server handshake. The the same thing is unencrypted for, the, definitely, Hileman and the shared secret before authentication happens with, certificate, verify. Right? So, that's, that's how I I see it. We we anticipate that, g x y can go across the world, but we have, very concrete evidence that the connection that we're, actually talking to, is who we think it is despite that. So that's just my comment there.
[01:00:55] Yaroslav: Thanks, Thank you. Usama, please be brief and concise.
[01:01:00] Usama: Okay. So I will try to be brief. So first of all, I will I already posted the comments for version number four, which said, like, unnecessary complexity, which is to say that you have to do continuous attestation anyway. Why add this intra handshake, which is a new added complexity for no reason? Like, you have to do as I said, if you do attestation now, it's valid at this point in time, not afterwards. You have to do post handshake anyway. Second comment was about the HKDF. If you go back to slide number, I think it was when you were mentioning the HKDF that you have replaced it with the sorry. The drive secret replaced by the HKDF, it doesn't change anything in the concern that was addressed mentioned that I mentioned in the last meeting because it's just a wraparound that. So if you add a new wraparound something, it still remains the same. It doesn't change anything. You are, by charter, required not to change the key schedule, and this is an extension of that key schedule, so it is still problematic. And slide number eight, if you go back there, please, there was I think you are in eight and nine. You are actually contradicting yourselves. In slide number nine, you are saying there is no secret. And on this early attestation slide, basically, you are saying client hello and server hello, which are actually not secrets. And on next slide, if you go to slide nine, please. In this, you are making the argument that these are not secrets, so that's why it doesn't matter. So, basically, there is a contradiction already that server hello and client hello, as I said before as well, they are not secrets. They are public information. Right? So server, we have to take that as malicious, although it is encrypted. But server itself is malicious. Client random and server random, you talked about both of those. They are both that they can both be proxied. And the point being that they are publicly available. That's not a secret value to be put into it.
[01:03:03] Tiru: Hey. Thanks, Usama, for the comments. I'll I'll try to answer one one after the other one. Right? Yeah. On on the unnecessary complexity one. Right? Imagine there are there are this draft talks about two scenarios if you recollect. Right? If I have a short lived TLS connection, right, there are many many live deployments today which use lost short lived live connections, which could just do the TLS handshake, exchange data, and shut down the connection. That's pretty much done today. Right? And the second issue is free attestation. Right? Free attestation is also possible with this. There are several design choices that we have considered. For instance, the post handshake client attestation. Right? TLS already supports post handshake client authentication on which reattestation could happen, but we are looking at new specs in TLS working group itself to enhance them to support reattestation. So reattestation is also possible with this spec. The second question is using HKDF extract. Right? I think you're coming to this comment. Right? Yeah. So HKD of expand label is is pretty much a basic construct, which is defined in RFC five eight six nine. They're just leveraging the construct to create a transcript for the client hello and server hello. That's in no way giving giving any inputs or updates to the key schedule. The third the third comment you had was with regard to using secrets. I'm I'm just reiterating that we didn't find any secrets that that were there, which was supposed to be used that were available during the pre handshake stage. But further to that, we didn't see a need to use any secrets at all in the first place. So your attack scenario where the server is malicious, right, the if the server is malicious, the client is providing the uniqueness to the client hello. Client hello, this client is providing its own ephemeral public key. And if you see the latest revised TLS RFC mandates the client to provide an ephemeral key, and and the client and server are also providing random values. So if you if you see an attack where unless both the peers are compromised, right, and both peers want to play fall, you can't do anything. But if you can show me an attack where both one of the peers is compromised and attack replay is possible, please send that attack on the mailing list, and we will take it up. Thank you.
[01:05:28] Usama: I mean I mean, it's in the papers.
[01:05:30] Yaroslav: So Usama, we are case are invalid. We are out of time. Let's continue with our busy agenda. So, again, please do take it to the list. We will continue discussion there. Okay. And now. Expat. Zero, you you're kicking kicking off? Yeah.
[01:05:59] Tiru: I'll take this one. Yeah. Thanks. I'll talk about the remote attestation with exported authenticators. The this solution is pretty much relying on r s c nine two six one. R s c nine two six one allowed applications to basically exchange certificates after the handshake, and we are pretty much extending that to carry new extensions so that attestation evidence can be carried within these new extensions that we have defined. As pointed out in the earlier analysis, right, it requires no changes to the TLS handshake or its messages or the key schedule. We have introduced a new CMW attestation, which carries the attestation evidence inside the certificate message. It supports both background check and passport models, and it also supports free attestation. How the support for CMW attestation is negotiated? It's similar to any other extension that an endpoint that wants to receive attestation evidence includes an empty CMW attestation extension and a certificate request or client certificate request message. The peer responds with the evidence or attestation results. And if it's an unrecognized extension as as TLS one dot three already says, the peer ignores it, so you won't get any attestation in the response. How does this draft accomplish the binding to the TLS session and read test station freshness? So it's it's relying on two inputs, basically. The TLS exporter is relying on the exporter secret, which is derived from the TLS traffic secret, and it's also relying on for freshness, it's relying on the certificate request context, which keeps changing for every certificate request. So within a TLS session, you we are relying on the TLS exporter secret, which gives you an unique value, which cannot be replayed in other TLS sessions. And within the TLS session, the certificate request context changes for every certificate request. So adding that to the to the eventual TLS exporter derivation as a context value gives you fresh values fresh nouns values that will be embedded within the evidence. There were some interesting comments that came from the working group with regard to what happens if resumption happens without attestation, and how does the client know how to reject PSK resumption. In the latest version of the draft, right, we if the server really wants any any attestation, the idea is server do not hand hand out session tickets so that session resumption cannot be used. Clients don't send early data. If clients start sending early data, then that means that it would completely bypass the attestation requirement that this document is is is relying upon. And if indeed the servers misbehave somehow and sends a ticket, then the client just throws it away and does not use that. This draft requires, since it's relying on the TLS exporter secret, it requires a full handshake. Or if you are using PSKs, it requires you to use ephemeral key exchange to do a fresh key exchange. So that becomes a mandate for this document to be relied upon. We request further comments and suggestions on this, and we request a working group adoption on this.
[01:09:29] Yaroslav: Hold on.
[01:09:43] Usama: Sorry?
[01:09:45] Yaroslav: We'll finish. It's one presentation. Yeah. In two.
[01:09:50] Usama: Thanks, Tidu. Thanks, Js. Basically, this is the continuation of the same presentation. That's the expert draft. So I'm going to describe about the properties for the same draft that Tidu was just presenting. That is to say, specifically focusing on the binding properties. Of course, I'm not saying that the other properties are not important. I'm focusing specifically on the binding ones because that's a source of many attacks. So I'm defining here three different levels. That is to say how strongly an evidence is connected to the specifics connection that we are talking about. That is a server and a client are having a specific connection, and we want to ensure that the entity which has generated this evidence is really the endpoint that I am actually talking to. This is the guarantee that I need in order to avoid the relay attack, and that's what I'm going to describe it in three different ways that how strongly is that evidence now connected to that specific connection. So we really need a secret in order to do that, and that's my belief. Because if that is not a secret, that is available to the adversary. Like, client hello, server hello, as I was mentioning in the mic as well before, they are the kind of things which are available to the adversary. G x y is the first unique secret which is not available to the adversary, and that is because of the reason that the x and y, which are used to generate that GXY, are only available with the client and the server unless there is a problem. So that is the first unique secret for that specific connection, and that is the state that it contains or the kind of state that is contained in this is g x from the client hello side from publicly that the adversary can see. It can only see g x and not the private x. And it is cons it contains also g y from the server side. That is the and not the y part, of course. That is remains private with the server. The second level, so to say, contains more strictly more information, which is the handshake traffic seek secret of the client. And I'm taking here the server as the attester, which means the client is the verifying relying party in a simplistic model just to not to bloat everything into there. And the point is that it contains the client hello message and the server hello complete message that is the derivation of the TLS 1.3 key schedule section 7.5 of RFC nine eight four six. So nothing changing the standard TLS. And the third one is the ATSC, application traffic secret of the client, which contains all the way up to the server finished, which means I'm really sure that the entity I'm talking to is also the one which has generated this evidence, and a strong binding between the two representing that that is really the entity that generated this evidence. So the claim here that we are making is that it's increasingly stronger binding to that specific connection. And if I have a security goal which satisfies or if I have any protocol which satisfies g three, it automatically satisfies g two and g one levels, but not the other way around. That is to say that g one implies g
[01:13:18] Yonit: two or three.
[01:13:18] Yaroslav: Osama. Paul, you look like you want to jump the queue. You're Yeah.
[01:13:23] Paul: I had a clarifying question, so I was waiting for him to finish this slide, and then
[01:13:25] Nathaniel: I was gonna ask my Sorry?
[01:13:29] Yaroslav: You're short on the queue.
[01:13:30] Usama: I'm just finished. The next one is the last, so we can take questions then.
[01:13:34] Mark: Okay.
[01:13:34] Usama: Sure. Is it fine for you?
[01:13:36] Nathaniel: Okay.
[01:13:38] Usama: And then we have the binding to client handshake traffic secret is not sufficient. So that's a question that is coming up, like, recently that, hey. Why is that not sufficient? Because of this reason, the two reasons I have mentioned here that it's basically irrelevant. If you look back at the chartering time so we had discussion with Eker, and he make a comment that it's actually not security relevant. That is to say that if you kind of remove theoretically all the encryptions that are done here, more specifically, like I'm talking about these encryptions of the handshake messages, not the encryption, of course, of the last final secret. If you remove all of these encryptions for these handshake messages, there is nothing changing in the security protocol at all because these are meant to be for the privacy purposes and not for the security purposes. They protect that who was talking to whom and so on.
[01:14:37] Yaroslav: Somewhat, we have five minutes left on the queue.
[01:14:40] Usama: Yeah. I'm just finishing. I'm done with the HTSC part, and then there's HTSC part that's just finished. So I think I just need one minute. Application traffic secret of the client is the key which is actually used to encrypt the final secret that this client will send over to the server and with which that let's say, the container or whatever will be decrypted and so on. So that's the database that with which it will decrypt everything and have a look at all the data. So that's the real one which is relevant for security goal to protect that specific health information or medical or, let's say, financial or government data that is being sent after doing all this at the end of the protocol. So that's the main argument that we are making here, like the ATSC sorry. The HTSC, the handshake traffic of the client irrelevant to the security goals and server not yet fully authenticated at that point in time. And then that for the ATSC, that is fully authenticated, and that's why binding to that level is quite secure. So that's pretty much it. So we can go ahead now with questions. Marcus? Hey,
[01:15:52] Marcus: Usama. Thanks for the presentation. I wanted to ask about the slide earlier. So you're you're making or you're suggesting that the binding is actually getting stronger the more, like, later you move in the handshake. But I think, like, if you would watch, like, not at the point of where you generate the evidence, but when you are actually done with the entire TLS connection, I'm not sure that this holds anymore. So I I shared an argument for this privately with you. I can share that on the list too. But I think you can achieve equivalent. So you can prove g three is stronger than g one, but you might also be able to prove g one is equally strong as g three at this point.
[01:16:36] Usama: Right. Thanks. We will we are looking into it, and we will then provide you a proof of that as well. Thanks. Nathaniel?
[01:16:45] Nathaniel: Hello. So following on with what Marcus just shared, and I've looked at, the recent, academic, paper and the, pen paper proof of the g three g two g one. This is a very nice proof of how transitive binding with TLS 1.3 works. So it's completely correct that if you have an unauthenticated TLS connection where you have an untrusted signing key, g one and g two are useless. You can have a secret g x y, but if you can't have something that vouches for the signing key on certificate verify, that g x y secret is irrelevant. Same thing with the handshake secret. But if you have g three authenticated certificate verify with a key that you trust, that vouches for g two and g one, and you are very confident that the secret from g x y or with post p q. Either way, g three vouches for g two, vouches for g one, and that's based off of what you trust with the signature over a certificate verify. So you're not wrong about what's authenticated, but it all comes together. And at the end of a handshake, you are trusting g one because you trust g three.
[01:18:33] Usama: So very quickly to respond to this one, I really want to make one argument, which is to say it's a single point of failure if you don't have this binding. Because if the private key is leaked, and we should assume that the private key can be leaked, the whole purpose of attestation to TLS was that if the private key leaks, you still can somehow detect by another method, a parallel pillar to that, which is that if private key leaked, I still have the guarantee that attestation should not fail. So if that private key is leaked, we have these these secrets to protect us that, hey. The private key has leaked, but these secrets are still not leaked.
[01:19:15] Nathaniel: Well well, the list.
[01:19:16] Yaroslav: Yeah. Unfortunately, we need to take it to the list. I see there is a disagreement in the room. Yeah. Paul, thank you for your patience.
[01:19:26] Paul: So sorry. Just When you described the server on this slide, I got really confused because you
[01:19:31] Usama: Is it for me or for in this slide?
[01:19:33] Paul: In this slide, the current slide, yeah. I got really confused by the term server here because you seem to be thinking that the server would be the attestation server, and so it would actually be doing part of the either handshake or the the Diffie Hellman values of the TLS connection. To me, that's a clear separation where I would have my tester run separately from the web server. So the web server, including its private key, would be attested by the attester. And so the attester has no role in the web PKI part of the TLS connection. And so I did not understand these levels at all.
[01:20:09] Usama: Right. So so the scenario that you have, I'm not aware of any implementation. But as a short answer, we will follow-up on list. Like, I don't know any implementation.
[01:20:18] Paul: There is no implementation of what we're designing in this working group yet. So, yes, there's no implementation of anything we work on
[01:20:23] Usama: here. Mhmm. Okay. So, I mean, there exists some implementation like SCONE and so on. People are using it in the in the real world, but that specific implementation you mentioned, we are not aware of that.
[01:20:40] Yaroslav: Thank you. Thanks everyone for the question. And again, Thiru with third proposal, application layer transport for exported authenticators and attestation.
[01:20:51] Tiru: Thanks. This is not a third proposal. I would like to clarify that first. Don't want to bring another third solution to the working group. So this is basically for the prior draft that was presented, which was relying on RFC nine to six one. I have some in experience in implementing RFC nine to six one because we want to deploy that in three g p p networks. I believe we have a parallel session happening in TSVWG where we are basically discussing on how to leverage RFC nine two six one, which pretty much requires you to either implement a shim layer or an application layer change because the TLS messages are not exchanged by the TLS stack by default. Yeah. You need an application layer which will collect these TLS structures and then exchange it across the peers. So that's what RFC nine two six one does. It does not define how these structures, the authenticator, authenticator request, and error messages can be exchanged between the two peers. And and the same goes with the draft that we have defined in this working group. And it's left to every other application to
[01:21:59] Nancy: File.
[01:22:02] Yonit: Yes.
[01:22:06] Yaroslav: Thank
[01:22:09] Tiru: you. So it's left to every application to decide on how they decide on to exchange these authenticator and authenticator request messages, and that's what this draft is trying to fulfill. Right? In case if the SEAT EXPAT draft is adapted, then we need this solution as well. Otherwise, it becomes incomplete. Right? I looked it to the other working groups which were leveraging RFC nine two six one. Right? HTTP base came very close and and and a very realistic example on how they are changing the HTTP protocol to basically exchange secondary certificates from the server. And I saw some discussions a priority on client providing certificates later, but I don't think their draft got adapted. And and, basically, I don't see any discussion in that working group which talks about reauthentication where the server reauthenticates at a later point of time, and it says that this the client is supposed to cache that and and cannot do reauthentication. And there's no way for this draft for the server to challenge the client, but, yeah, the draft could another draft could be enhanced. That's potentially possible. I looked at the Google's split trust encryption tool. It's pretty much relying on gRPC. Right? And I don't think we want to rely on gRPC's at least in in today's world. Right? So what what this draft does. Right? I mean, we have just taken a approach similar to what other protocols have done. I've taken the TLS one dot three presentation layer. The peers agree on the attestation model. Basically, they negotiate the capabilities whether to pick background or passport and what kind of of CMW encoding. And, basically, what I did was I leveraged the HDB protocol. Basically, the the messages are carried as capsules, is already defined and extensively used today, and leverage the extended connect, which runs over HTTP two and HTTP three. And and then we also defined a shim mode, basically, for scenarios, especially if you have a short lived session and you don't want to use HTTP, then you can use the shim mode as as shim mode doesn't support reattestation because once shim mode is done, you have to give control back to the application layer and you can't do anything after that. So this pretty much works only for short lived connections. Yeah. So among there are various options to do this. Right? You could do WebSockets, various other ways. So I thought capsules is the new way of doing things and and it gives it gives us all the machinery that's required. It gives you extended connect. It allows you to define the upgraded token, which is we define I define we define exported authenticator and and we leverage the capsule protocol for exchanging these binary messages. And one of the good advantages of this is it's one connection, multiplex, so you can run this binary protocol as one of the streams, and and the other data can be exchanged on other streams. It would work for HTTP, HTTP three dot o, and the rest part, it's bidirectional. Any peer can ask for attestation and the other peer would provide in response to evidence. It's forward compatible in case if there are new unknown capsule types that can be silently ignored, and the best part is it supports reattestation. So basically it's we have defined four new capsule types. One is to one is for authentication capability authentication authentication capability exchange to negotiate the models and CMW types and there is authenticator request followed by the authenticator which carries the evidence and then an error message for various errors that would come. This is the flow basically. Right? The client does an extended connect. It gets sent 200 okay from the server. They negotiate the capabilities and agree on the model and the CMW type and then the client can initially ask for evidence and the server can later ask for evidence and the peers at any time can exchange evidence on this screen. So this shim layer is like if you don't want to use HTTP, you want to use for short lived connections, you are using DTLS one dot three where HTTP can be used, you could do a shim layer where we created auth frame framing basically with a magic value to distinguish from the application traffic, a length, and then the the the deal structure to carry these messages, basically. This would not just for work for registration. If someone wants to do just post hand authentication, it would also work. Right? But you don't have to exchange the capability exchanges. It becomes optional in that case and the keyless layer continues to be untouched and this would work for any existing RFC nine two six one implementation. I think this draft belongs to seat alongside the seat expert, and we would like to hear whether there's better ways to do this or or you believe this could be a good way of doing this and if it could be at a later stage.
[01:27:29] Yaroslav: Okay. Osama, please be brief.
[01:27:31] Nancy: You have thirty seconds.
[01:27:33] Usama: Okay. Thirty seconds. So speaking as the author of expert draft, I really want to thank you for this work, and I really see this work as very complementary to our draft. This is in the sense that I mentioned about SCONE. They are using it in live production post handshake solutions. But if we can standardize that, that's really helpful for others also to follow a standard, which we can then like, people can then be secure and then be useful for others as well to have a unique standard. So in that sense, I really see the value of this, and I would like this to be seen as complementary to our draft. Of course, you are a coauthor with us as well, but I'm speaking as an individual author of the
[01:28:15] Tiru: Thank you.
[01:28:15] Yaroslav: Thank you, Sama. Nathaniel?
[01:28:19] Nathaniel: Hi. So I like this a lot. I have a wacky proof of concepts that I've been working on privately since forever that is all had ad hoc. This provides a bunch of concrete details, so, plus one for that. I had a question related to post handshake. The the can't the refusal to have resumption, is that have you thought about it with post sorry. Within a cast cached attestation result?
[01:29:04] Tiru: This that comment is not for this document. I believe it's for the previous document. Right? We have not evaluated that.
[01:29:12] Nathaniel: Okay. That that's fine. Thank you.
[01:29:15] Yaroslav: Okay. With my chair hat on, I would strongly recommend to run HTTP specific things through HTTP working group. There is a history that I've observed of some working groups using HTTP incorrectly and then going too deep into design space and then having to go back into drawing board once checking with HTTP. So it's better to do it early, and I'm sure they they might find time on the on the next meeting agenda.
[01:29:47] Tiru: Definitely. That makes a lot of sense. Thanks.
[01:29:50] Nancy: So so you can ask for an HTTP director review if it's a working group draft.
[01:29:56] Yaroslav: Right. But asking for a slotted session to do it less formally, I think, also works.
[01:30:02] Nancy: They do they take people like that? Aren't they busy?
[01:30:08] Nathaniel: Oh my god.
[01:30:08] Yaroslav: If if you ask nicely.
[01:30:10] Nancy: If you ask nicely? Oh, okay. Okay. Money. Cookies, maybe. Cookies.
[01:30:20] Tiru: Thank you.
[01:30:24] Yaroslav: Okay. Thanks everyone. We are right on time. Thanks to the presenters and to those who asked questions. We have quite a number of drafts that are asking for adoption. It would be great to have more discussion on the mailing list. There were a few questions that created some debate. Let's again take to the mailing list so that we would reach some kind of consensus or rough consensus on open items. Thanks again, and see you in San Francisco.
[01:31:05] Nancy: Nice, Ori. Here you go. Like, you can really no comment.
[01:31:10] June: Do I make comments?
[01:31:14] Nancy: I don't know. Yaron may not have read the the chat. What's that?