**Session Date/Time:** 24 Jul 2026 12:00

[00:00:07] **Justin Richer**: Alright.

[00:00:07] **Deb Cooley**: It's on the clicker. And then when we get to Ounsworth, we have to come out of it and bring but he's after David.

[00:00:12] **Mike Ounsworth**: So Yeah. He's the

[00:00:13] **Roman Danyliw**: last one. I'm giving this one more go. What? Woah. Woah. Woah. Look at that.

[00:00:20] **Deb Cooley**: What did you

[00:00:23] **Roman Danyliw**: Pull the pull the presentation and then pull it back up again. And there's no switching,

[00:00:30] **Mike Ounsworth**: and there's no more updates.

[00:00:34] **Deb Cooley**: That assumes oh, look at that. It worked. Is that not awesome? They got quiet. Why did they get quiet? We're we're still fiddling around. Hold on.

[00:00:56] **Roman Danyliw**: Yeah.

[00:00:57] **Deb Cooley**: No no puppies. Okay. Time has opened.

[00:01:14] **Roman Danyliw**: It's 02:01.

[00:01:16] **Mike Ounsworth**: We'll get started in just one moment.

[00:01:23] **Deb Cooley**: Is Christina here? Because I understand she's now me. That means she gets TLS, by the way.

[00:01:36] **Roman Danyliw**: She's the one who

[00:01:37] **Mike Ounsworth**: who's got your badge?

[00:01:38] **Deb Cooley**: She has my badge. I do wanna know the story. I probably left it on the table someplace and she took it, but whatever. Yeah. Yeah. It's Christina. I know Christina has it because she posted a picture of it.

[00:01:57] **Justin Richer**: It's

[00:02:01] **Deb Cooley**: fine. I mean, the the security guy knows me anyway because I say hi. No. But it's too late for coffee to respond. What? I I have a badge. What more do you want? Christina took it. No. We put everything together in a big deck. Don't don't don't don't be so worried. Okay. Well, this is SAAG. So if you don't mean to be in SAAG, you should leave. If you do mean to be SAAG, hi. Thank you. And this is Chris Inacio, is not in person at Shenzhen. So just in case you have not seen him this week. Hi, Chris. And I'm Deb Cooley. I can't prove it right now, but I am Deb Cooley. Okay. So this is the note well. You have possibly seen this more than once this week. It's a reminder about the processes and policies, including conduct, privacy, and intellectual property rights that you agree to follow when you participate in the IETF. Please read it carefully. You're encouraged to read the source documents to which the note well refers. If you have questions, please talk to the working group chairs or area directors. So that's the note well. Meeting tips, you know, turn off your mics, videos, whatever. Don't use hot spots. Okay. Right. These are just general resources for IETF 126 on Friday afternoon. So this is our agenda. We're gonna do the normal working group reports. We've got two talks lined up, one by David Benjamin and one by Mike Gundworth. We did get your new slides loaded, by the way. Yay. Any agenda bashing? We should we should have some time at for open mic at the end, I think. So these are the changes that have happened since 01/25. We had a BOF called current. There will be more coming on that later. Currently, there is nothing in initial chartering at the ISG. We have we've done a little bit of a update for the sec sec dispatch working group. We're now combined sec dispatch and dispatch, and then also the non transport areas of WIT into a updated working group called dispatch. So Aart technically holds it, but we are responsible for parts of it. We are gonna close sec dispatch. We will attempt to roll the working the mailing list and whatnot in a way that people don't get lost in the process. We are also looking for a new chair for the sec area of dispatch if you're interested. Needs to be somebody experienced, I think, because you need to be able to judge whether something is useful for sec or not. And we are we have rechartered OAuth, and we are in the process of rechartering SPICE and Radext.

[00:05:38] **Roman Danyliw**: Radext. To West public announcement.

[00:05:42] **Deb Cooley**: Oh, do you is Radext done?

[00:05:44] **Mike Ounsworth**: It is. Yeah.

[00:05:46] **Deb Cooley**: Radext is done. So it's OAuth and Radext are done. SPICE is still sort of in process. Yeah. No working group chairs changes. If you're interested in helping out, SAAG in in ways, one of the things you can do that we've added new to the list, I put it on the top, is as requests come in to dispatch, we would love to have reviews and comments on those things so that we have a better idea of ahead of time before it gets to a dispatch meeting of whether you think it's useful work or not. As always, we're interested in people that are interested in being working group chairs. Document shepherds are always a good thing. Errata processing. If you see an errata come through and you have an opinion on whether it should be verified or rejected or help for a document update, just reply to that, and we will take note. Obviously, it's a good idea to attend BOFs virtually or in person. And if somebody wants to volunteer to be a minute taker. Hank's scratching his head. Is that a yes? Are you raising your hands, Hank? No. Okay. Alright. So these are the working group summaries. If you have not if you were a chair and you've not sent the working group summary to the list and you wanna come to the mic and talk about what you've what you've accomplished this week, that would be lovely. Anybody else too, really?

[00:07:32] **Roman Danyliw**: Maybe at least say 10 people should come to the mic.

[00:07:36] **Deb Cooley**: I haven't looked.

[00:07:37] **Mike Ounsworth**: I have the list right here.

[00:07:39] **Deb Cooley**: That's who did. That's who added it. Who's missing? Oh, that's hard. Sean, TLS. OAuth. MLS. OAuth. Those are hands straight away.

[00:07:58] **Sean Turner**: I mean, I didn't send a summary. I would say that it's all sunshine and rainbows in TLS. You can read the mailing list and check out the the slides. MLS, I think, was also actually pretty good too. So I think we're kinda plugging along. We got, like, three or four working group documents in MLS that are gonna hopefully be popping out shortly. So that's all good.

[00:08:28] **Deb Cooley**: ACME.

[00:08:31] **Mike Ounsworth**: Can you tell us what's going on with PQIP?

[00:08:35] **Deb Cooley**: You wanna do that? Sure. PQIP.

[00:08:40] **Roman Danyliw**: So PQIP is winding down. So there's a couple of drafts just left to make their way through. The last draft is waiting for some final updates to have, done so that, it it progresses through to IESG review and publication, at which point the working group will be closed.

[00:09:09] **Deb Cooley**: Do you wanna do an acne update, or did he send it?

[00:09:13] **Roman Danyliw**: I didn't see one. You're going to send it?

[00:09:20] **Deb Cooley**: I mean, you can.

[00:09:25] **Mike Ounsworth**: There's at least ten minutes before the end of the meeting.

[00:09:31] **Stephen Farrell**: Okay.

[00:09:34] **Deb Cooley**: So this is our list of not related non sec area activities. If you see something you think should be listed and it's not, you can tell us. If you wanna give an update on any of these, we're happy to hear it.

[00:10:02] **Speaker 6**: Hey. So it's not in this list, but there is some security adjacent work going on in OPSAWG. So there's a draft that had some discussion there on Monday on security operations, fundamentals, guidance. So security operators here are people who prevent and respond to cyber incidents. The draft is very operationally focused, so there's interest in the group, but they were very aware that they wanted to engage with the security community as well. So if you have expertise in that area and you'd like to review the draft, please do. Thanks.

[00:10:40] **Deb Cooley**: Can we put a can we put a link to it in the chat? Yeah. Thank you.

[00:10:47] **Justin Richer**: Justin Richard, co chair of WIMSE. And we've got one doc that's going out to IESG wide review real shortly. It's out of working group last call and all that. And we've got two, three two two or three more. We're not sure. What do we know? We're chairs. We've got two or three more docs that are going out, and I'm bringing it up here because WIMSE is not sec area, but we are very security focused working group. So when those go out for IESG wide call, please pay attention. We need a lot of eyes on these docs to make sure that we get all of the, you know, sort of the wide security review that these things deserve. So thank you.

[00:11:32] **Deb Cooley**: Okey dokey.

[00:11:36] **Hank Birkholz**: There's things on the floor. Hi, this is Henk. I'm not speaking for, but speaking about the vCon working group. We have this tiny little thing that was just in time called the audit of preparation. This is basically about, yeah, auditing and and authority delegation. There's a discrepancy there, but also we have decided not to wait but to work. So the record, the verifiable agent conversation record will be going to vCon.

[00:12:08] **Deb Cooley**: Oh, cool.

[00:12:08] **Hank Birkholz**: And that is basically a way to avoid a delay.

[00:12:15] **Deb Cooley**: Nice. Thank you, Hank.

[00:12:18] **Mike Ounsworth**: Hi. It's John Gray from Entrust. You have external related there. So just wanted to mention, so Oasis is actually working on a bunch of PQC stuff. Right? Like, for p k c s 11, we're adding standards in there. So and I think they also probably have the XML encryption and stuff like that. Or there's other areas that do.

[00:12:37] **Deb Cooley**: Some of that's w three c. Correct?

[00:12:38] **Mike Ounsworth**: Yeah. That's right. That's w three c. But, anyway, just I don't see Oasis there. I'm just mentioning it, if that matters.

[00:12:44] **David Benjamin**: Just

[00:12:50] **Speaker 9**: real quickly, the NTP working group a few years ago published the network time security RFC. Can't remember the name number of it at the moment. But there's currently an effort looking at an experimental RFC that's looking at how would you build the equivalent of pool.ntp.org for network time security? So if it's NTS enabled NTP, is it possible to build the equivalent of pool.ntp.org? If anybody's interested in that experiment, there's a little bit of information in the hackathon and a little bit of information in the NTP slides.

[00:13:24] **Deb Cooley**: Okay. Thank you. And if there's a way for you to, like, add it to the chat, it would be even better. If you could add, like, the link to the NTP stuff to the chat, it would be great. Yeah.

[00:13:43] **Usama Yasmin**: Sama, do you have dressed in? So we had a couple of side meetings which were very security focused. It's not for the IETF, but it's for the IRTF. We are trying to create a couple of research groups because there has been a lot of work in the side meetings going on for several meetings. We are trying to focus these to some smaller problems so that they can be tackled in different working groups. So everyone in the community is welcome to contribute to those. Thanks.

[00:14:22] **Deb Cooley**: Okay. So we created three non working group mailing lists since the last meeting. KMFS PCS, which is the mailing list that actually goes with current. We have one called I'm gonna say mole because Martin Thompson slides had a mole on them and not a mole. That's you can well, you can read it. I don't need to read it for you. And then ZTCPP, which is zero trust type work. I believe two of the three of those probably had side meetings this week. So these are 80 sponsored drafts. So the the top one I've had for quite some time. I'm actually looking for a Shepard write up for this. And I have agreed that if I don't get somebody else to write a Shepard write up for this, I'll write the Shepard write up, which is making it slow because I don't know. The other one is Stefan made this proposal that I'm looking at and trying to decide whether I'm gonna take it as a as an AD sponsor. It doesn't really fit in a working group. It's not really LAMPS. It's not really anything else. So I'm contemplating. Oh, Simone. Simone, are you gonna send that to the list? Simone posted in the chat about w three c updates. And he's gonna send that to the list because that'll be better than me repeating it. So so we had this combined dispatch. This time we had five or six presentations. Two of them are possibly security. They're possibly art. So I'm putting them here just in the effort of transparency. One is email verification protocol. And the other one is confidentiality and authenticity protection for internet email. So they both were dispatched either to a mailing list or a BOF. There has not been a designation of whether they're art or sec. It could be either because they're both email. So if you have opinions on that, you can email us separately. So you can see what's going on in the security area by looking at the working group's data tracker pages. There's this fabulous little thing. And then underneath of that is the this is the data of how met what exactly the security area directors are working on. So you will see there are three fourteen documents, 11,000 pages, and 30 working groups. It's a lot. And these are just working group documents, not individual drafts. We we should spin. That's exactly right. That is exactly right. Yeah. So it's it's you you you you all are busy. And we are busy we are busy as a result of you being busy. But it's all it's all good. Right? I mean, it's what's supposed to happen. So this is the errata processing. We have we have possibly been slightly slackers. We've only closed two erratas in the last three months. But we will we will hop back on that. Again, I have a I keep a list of the ones that I I can do. And I go in every once in a while and, like, do a bunch of them at once. And I just I haven't had a chance to do it. What? Anyway. These are the pointers to where you can find out. So the middle two, like where is my document that's with the AD, like those two things will show you exactly where your draft is. When you push the publication requested button and it comes to us, this will show you what we're doing with it and where what state it's in. And the tele chat too, which is a whole other thing. So sector reviewers. We have a whole team of of people that do reviews of drafts before they go to the ISG telechat, And it helps us out a lot. Sort of raises the bar on the drafts before we get it, which is which is super helpful. What? Oh, no. No. You're oh, I'm sorry. You're right. The the junior manager is not listed there. So Paul is also helping to manage the sector directorate. But since he's the junior manager of the last two Yeah. Sorry. Sorry. We will we will add you next

[00:20:17] **Mike Ounsworth**: time when

[00:20:19] **Deb Cooley**: you have more experience. It's always good to be kept on your toes. So Tiro put together a bunch of statistics. We'll kinda roll through these pretty quickly. They're on they're on the sag agenda. You can go look at them later if you really want to. These are the number of completed reviews. Were they on time? Were they late? Were they whatever? The results of the reviews, whether things were, like, ready to go or had issues. Documents per month. Notice

[00:20:55] **Roman Danyliw**: Wait. There's nothing late.

[00:20:57] **Deb Cooley**: Nothing late in June. Write that down. Turn all the way through? Okay.

[00:21:05] **Nalini Elkins**: Alright. So there you go.

[00:21:07] **Deb Cooley**: Yeah. So I'll let you look at these. It's a lot. So we have a hall of fame. This is the hall of fame. Numbers of drafts that they've reviewed. This is the hall of fame for the number of pages. Yes. Exactly. Right? That's a lot of work. Thank you very much.

[00:21:33] **Stephen Farrell**: And there's gonna be, like, a

[00:21:36] **Deb Cooley**: I mean, Raffat's catching up. Right?

[00:21:39] **Stephen Farrell**: We need to do, like,

[00:21:40] **Roman Danyliw**: a free dinner or a free buff or something.

[00:21:42] **Deb Cooley**: We give them free lunch if they come.

[00:21:44] **Justin Richer**: Okay.

[00:21:48] **Deb Cooley**: So, David, we have the clicker all prepped for you.

[00:21:57] **David Benjamin**: Quite a lot

[00:21:57] **Hank Birkholz**: of these.

[00:21:58] **Deb Cooley**: So this is David Benjamin.

[00:22:00] **David Benjamin**: Hello. I guess if you all have been living under a rock, we've got this post quantum thing we kinda have to sort out. Also, for at least a lot of folks, the desired timelines have shifted a bit from low single digit decades to low single digit years, and now we gotta deal with that. So this talk is about how to deal with that, specifically for certificates. This is what we're gonna talk about. Yeah. So specifically, I wanted to talk a bit about how to get meaningful post quantum authentication. I work on a browser, so I'm gonna focus on https server auth. So where the client, it's probably like a web browser or maybe like command line curl or something, wants to talk to an h t p s server and uses the h t p s server certificate to authenticate that. There are lots of other applications that need post quantum certificates. It is impractical to talk about all of them at the same time. They overlap significantly, but they also differ slightly. For those of you who are interested in something that overlaps but differs, hopefully this is useful inspiration and context. But not everything will necessarily apply to everyone. This talk is not about key agreement. If you haven't deployed MLChem yet, please get on that and stop bothering the TLS working group list. Now I'm gonna talk about the different flavors of PQ certs. You know, we've got this Merkle tree certs thing in plants, there's pure versus hybrid, and all this other stuff. Pick some format, pick some PQ cert construction. This is about what you do after you have one. And this is also not going to be a concrete set of proposals because we're not in one working group. This talk is about why we need to do some of the things, not how to do them. We are at the very end of this, is going to be something where the why is fairly subtle and the how is extremely gross. And for the sake of all of our sanity, I wanted to split this into two parts. So this is part one, why. How will be later. So I said I'm gonna focus primarily on the web as a sort of cheat sheet for whether this applies to you or not. Things about the web that makes this challenging is that we often have these general purpose clients that talk to many, many servers. A web browser needs to talk to any website that's on the internet. Your command line curl tool also needs to handle basically anything that's out there. While there are some clients that are a bit more specialized, like your mobile app for this one service probably only talks to that one server, very many of them have to take fairly conservative policies because they can't break the web at large. Conversely, your servers need to serve a wide range of clients. There's the, you know, up to date web browsers and up to date command line tools. And then there's this TV set top box over in the corner that hasn't been updated for decades. I was just talking to someone who, just last year, was finally able to remove SSL three because they dropped support for Windows CE. Old clients do not go away. So this is where our life is hard. And as a result of this, since server operators need to deploy new post quantum certs, we have this problem that we have many, many, many server operators. And in aggregate, waiting for them all to do something is going to take a while. We do have a few tools we have. We have much fewer CA operators than server operators. So work that is order of CAs is way cheaper than work that is order of servers. And we have a relatively limited certificate lifetime, which means that the one part of a server that is regularly updated is they are going to go to their CA every now and then and get a new search. Also, we have an online protocol where parameter negotiation is the norm. If you are running a server and you need to support Windows CE up through modern browsers, okay, turn on SSL three and turn on TLS one one three, and then the server software will deal with it. There are security implications to supporting a wide range of things, but at least this tool is there and we can analyze it. This is as opposed to something like file encryption where you sort of found a cert lying on the street and you don't really have a chance to get one specialized for you. I don't know how to like, this talk is not about that. We're gonna see an online protocol for here. Hopefully folks mostly know what certs are, but to make sure we're on the same page, the main problem here is that the application semantics are I want to talk to iatf.org. But cryptography has given us I can make a secure connection to this key. And these are not the same thing. And we need to somehow bridge the two and have a table somewhere. That's iatf.org's key is 12345 and not 5678. 5678 is the attacker's key. Do not think that Do not miss or switch them up. And because we have lots of servers, we can't just ship a big list of them in the browser. So instead, we indirect it by shipping a smaller list of CAs that are trusted to build this table, and then they can sign statements about this table. IETF's key is 12345. It's not 5678. And as long as the client trusts the CA, it can trust its key pairing. As long as we somehow ultimately get to clients don't accept unauthorized keys for some service. If they do, then that holder of that key instead of the real service can go attack them, and we lose.

[00:26:57] **Deb Cooley**: So,

[00:26:57] **David Benjamin**: what does it mean to make this post quantum? If you if you I think a lot of folks sort of think about this problem, you're like, okay, we need to go pick a PQ search construction, we need to go add support for that to the clients, we need to spin up a CA, we need to go and put it in the servers, and then we go load the server up in your favorite browser, and you look in the corner, and it's got the PQ search. Cool. I'm done. Boss, I've done the PQ thing. Please pay me now. But this is not actually our goal. Our goal was not to make PQ search be used. It was a security property. And specifically, since we're talking about authentication, we are worried about an active quantum adversary, and we want to prevent them from intercepting connections between clients and servers that have both been updated to whatever this new world is going to be. And at the same time, there are going to be those unupdated clients. We need to still maintain compatibility between almost all clients and almost all servers, whatever that means for your application. And that is not the same thing as deploying a post quantum certificate. So first, why only updated endpoints? Any kind of transition like this, we're gonna have some new stuff and some old stuff. And the old stuff, kind of by definition, cannot do the new thing that you are talking about. So we cannot save them from a quantum computer no matter what we do, except by updating them. So the baseline here is we are only, for security purposes, looking at updated clients. And then we are looking at what it takes to bring the individual unupdated endpoints into whatever our new world is. But since we have a lot of them, we also have to account for the fact that the long tail updates slowly, and whatever population there still is of the old stuff, we need to account for that in making sure that the Internet also doesn't break. We get to decide what the updated behavior is. We can't change the legacy behavior. It's what's there. We're stuck with it. When we decide what it is, it's gotta, of course, be secure. We've got some timeline. It's gotta be achievable. And what that is achievable depends on what's going on with the old peers. And then we need to somehow design a transition plan that navigates through this mess and meets our single digit number of years target. So, okay. Well, if you like kind of try to figure out what kinds of behaviors you can have broadly, you can go from currently where everyone only has and accepts classical certs, alright, let's go add support for the PQ certs and add support and start installing them in servers. And then maybe one day we'll remove the classical one and stop supporting classical ones. And let's go fill out this table. Well, obviously these two corners can't talk to each other because they have no algorithms in common. If you look at which certificate is used, you're like, oh, once we get to the middle, everything's fine. Oh, okay. If you look at the the middle once you look at which certificate is used, oh, cool. It's green. We're fine. We're using the PQ cert. And that's good because we're probably gonna be stuck in the middle for a while. But, again, that's not our goal. Our goal is to be secure against a quantum attacker. And the problem is, any time you're dealing with these with certificates, it does not matter security wise which certificate the legitimate peer used. The only thing that matters is what the client accepts. Because when you're in an active attack, the active attacker picks the certificate. So even if example.com has gone and upgraded to a pq cert, if the client still accepts both due to compatibility reasons, the attacker will just break the classical CAs key instead because it's just sitting there, and then forge a cert, and the client goes, oh, I guess example.com was an unupdated server. That sounds good. Connection goes through. And now you've leaked your cookies or whatever else and you lose. So this is actually what our table looks like. It doesn't really matter whether the server drops the client the the classical cert. The only thing that matters is whether the client stops accepting the classical cert. And so when we think about where we're trying to get to, we need to figure out how fast we can get the clients to this bottom row. And unfortunately, that bottom row breaks stuff. So this is all to say we need to go start pinging we need to look at what what the client sees. So if you look at what a client sees, there's some population of servers, and over time, they're going to gradually deploy whatever thing we want. And usually this looks like some sort of s curve where, you know, the early adopters ramp up and then the long tail takes forever. And at some point, we need to make a choice to require post quantum. And usually, there is some sort of fraction of servers that you are allowed to break. Or by allowed to break, mean, if you break, you know, 10% of the web, then the people who are broken will go and yell at your CEO, and they'll be like, please revert this now. So there's some fraction where you can kind of get away with, this is not to scale. That line is really way up at the top, but otherwise you wouldn't be able to see it. So and the problem is, from what we saw in this picture, until the client enforces it, we don't have any PQC oh, label's the missing. Alright. Well, the gray means The it doesn't green means it's p q secure. And this giant massive red, the quantum attacker can break you. And the thing is, all that space under the curve that we thought had deployed the post quantum cert, they didn't get anything useful out of this, at least not until the client is able to flip the switch. And is this a problem? Well, if you only talk to like two servers, like your, you know, the mobile app for this one service, your s curve is really tight and it's probably fine. You're just waiting for five people to go and take an action. But if you talk to many, many servers, you are limited by the worst of the entire population, and this will probably take us decades. And we do not have decades, so this is a bit of a problem. So what can we do? Well, the root problem is that the client does not know, does not securely know whether some service was supposed to have a PQ search. We need some form of downgrade protection. So, alright, what if we just made a list of the ones that were supposed to be there? The web, we have this strict transport security thing that says require http require https over http. We could maybe do something similar here. Maybe we have a dynamic version where if you see a header, you remember it. Maybe we have a static version where we make a big list. Does that work? Well, oh. Oh, that's bad. That was unfortunate. Okay. Well, there was supposed to be a little gradient, so you didn't see what was on the right hand side until I moved to the next slide. But the problem is that HSTS kind of sucks. Like, it it is it is very attractive because it doesn't break anyone who doesn't opt in, but the dynamic version requires the application to maintain a state. That can't happen deep in your library. Also, there's some interesting privacy implications. It doesn't protect the first visit. The static version, at some point the static list is gonna hit a scaling limit. The whole reason we have a PKI was we couldn't make a list of all the websites, so of course we can't make a list of all the PQ websites. There's deployment risk for site operators. If you turn it on, you cannot roll it back because your website will stop breaking, and various other problems. And so, you know, we can expect that this will give us some green, but it's not going to get all the way up there. At some point, we'll hit a wall and then we're sort of in sadness for ten years for the remaining red. Oh, okay. Well, there's that picture.

[00:33:38] **Deb Cooley**: That one was right.

[00:33:39] **David Benjamin**: Another thought is maybe we could split the transition in two. So a certificate, we we were talking about a classical cert and a p q cert, but there's actually two keys involved. There's the issuing CA's key, and that signs over the server's TLS key. Switching the server TLS key unavoidably requires per server work. If the server does not have code to handle an MLDSA key, it cannot have an MLDSA TLS key. And it needs to actually maintain this secret in, you know, wherever it keeps its keys. But the CA key contributes just a signature to this certificate. And that's mostly opaque to the service. They're just sort of sending it all they're just sort of forwarding it along for the relying party to check. And maybe we could switch that one with only per CA work. The server's already renewed certs. Maybe we could automatically renew them into the transition state. There's a bit more to say about this, but you know, for something that wouldn't work, what if we just said, alright, the CAs are gonna flip a switch, and tomorrow when you go to them, if you ask them to sign this key, they will use their PQ infrastructure instead of their classical infrastructure. And now you wait forty five days or so, and then all the starts have been replaced with PQ CAs.

[00:34:44] **Hank Birkholz**: That's not

[00:34:45] **David Benjamin**: gonna work. So let's suppose we could do that. So here's our picture. I've now separated the labels out for the two halves of the certificate. And what if we try to move just the CA part? So because only the CAs have to do work, if we can manage to pull this off, we can expect this s curve to go way faster. And so now you have three categories of old of of server or I guess four cata. You have three categories of servers. The ones that are on purely classical, the ones that have gotten purely PQ, and the ones that are in this sort of transition state where the TLS key is broken but the CA signing them is secure. So because this will go faster, it will hit our threshold much sooner. And so there we go. And so the client can require PQCA sooner. What's this do? Well, obviously, everyone above that curve, they're now broken. It was within our budget, so we're okay. Draw the line so that, you know, you're happy with that amount. These guys are actually still broken. So although we've gone through all this work to go change their certs, they are just as vulnerable as before. The attacker just breaks their TLS key instead of their CA key. So why do we do this? Now this massive red is actually is actually green now because once the client no longer trusts the PQCA sorry, classical CA, that classical CA is no longer an attack vector for the servers that are PQ secure. And so we can finally have our cake and eat it too and get this green thing if we can pull off this faster s curve. So earlier, I put a big question mark over this bizarre middle certificate that, like, you know, on paper you would never want. What is it? This middle cert is a PQ secure signal that this service is not yet PQ secure. Because if we don't have this middle cert and the not yet PQ servers are the first one, when you see that, that you you have a suspicion that example.com is not ready. But you don't actually know because the only signal you have came from someone that the attacker could have forged. But in this middle case, the attacker cannot forge that one signature. The hop after it hops to something that is broken, but that hop has the SANs in it. It has, like, the DNS name in it, so it's scoped to one service. So maybe we have a plan now. Go deploy it. Servers gradually roll it out. We're still stuck in that red. Maybe we deploy this HSTS thing as a stop gap, but it's kind of a problem. And then we after the CAs flip a switch and start issuing from their PQCAs. And as a result, all your classical to classical becomes p q p q classical, and now the server clients can require classical PQCAs, and we get our happy thing. And then everyone else sort of like over time catches up. But I said this is not going to work. This is not going to work. This is gonna break some stuff. And the reason it's not going to work is now we have to look at what the server sees. So the servers have their own s curve problem. Now we're looking at clients over time, and over time the client deploys whatever the new thing it is. It's probably gonna be some sort of s curve again. And probably once again, if you talk to lots of clients, it will take you many decades before you reach the threshold that people are okay with you breaking it. But now we have this problem that if the server stays on the p q if the server switches to the p q c a, the old clients are broken. The old clients do not have code for m l d s a. They can't possibly verify those. But if you stay on the classical c a, then the new clients are held back and they can never get to the secure state. And if you want to wait for everyone, that's gonna take you ten years, and we don't have ten years. So and this means that if you're from the CA's perspective, you cannot flip a switch on your infrastructure if that will cause your customers to then go break their service. Even if it's only for like 5% of their users, they're gonna be upset about those 5% of users. And so without solving this problem, we cannot The CAs cannot go automatically switch things over, which means then the clients cannot protect themselves. So how do we beat this s curve? Well, this is where we have an online oh, what's going on over there? Oh, well. This is where we have an online protocol. Because we have an online protocol, we can do parameter negotiation. We can, instead of having one certificate that satisfies everyone, we can have one certificate for the legacy clients and one for the PQ clients. And really, we can generalize this to all kinds of PQ transition problems, but that's not this conversation. So if you imagine you have your server that's stuck on a classical TLS key, if it could suddenly automatically get two certs, one that's signed from the classical CA and one that's signed from the PQ CA, then now this picture looks very similar to what we had before. And then oh, that's what that text was. Okay. So the blue arrow was supposed to be labeled automatic transition and the purple label was supposed to be labeled manual transition. So they can automatically do this first step. And the second step, manually on a per server basis, they can then split into having these two keys. There's some work in TLS that gives us these tools. Yes. Okay. So then there's some tool work in TLS that gives us these tools. And so now this picture gives us similar security properties as before, but now without the compatibility costs. If you if you put a filter on and only look at what classical clients see

[00:39:29] **Mike Ounsworth**: Can you turn the mic prescript?

[00:39:31] **David Benjamin**: That's a good idea. Okay. Here. I'll just hold it. There we go. Okay. So if you put on a filter it's difficult problems. Okay. So if you put on a filter and you only look at what the classical client will accept, the PQ things disappear, and this is unmodified. So they don't actually notice anything's going on. And the server the c the clients that don't support the classical CAs, well, they can't see anything coming from the classical CAs because they're not gonna accept them. And now we have the other picture that we had where the secure servers have PQ to PQ, and the old ones have PQ to classical, and we have the same downgrade protection as before. But we still have a problem. I don't have a time machine. And if you remember, while we can define what happens on the updated side, we cannot change the legacy stuff. Whatever we found and already deployed, that's what we gotta work with. And right now, because we've never really done any kind of transition like this in the PKI before, most the pipeline from CAs to server software to their TLS stacks mostly only takes one certificate. And that means that while you could imagine, well, we'll go and upgrade all of these all the layer steps in this pipeline to get us to the new picture. The people on legacy side, they're stuck with what they've got because the whole reason we're in this mess is we cannot go and do order of servers work in ten years. So we have to somehow stick this fit in their one certificate box. And so we need a transitional hack for them. And this is where this is disgusting. And I will not do a slide I will not present the details here because I haven't written them yet. This is explaining why we need this. But when we have only one certificate slot, we sort of can work backwards from our constraints. We need something that is compatible with legacy clients, so that means the outer x five zero nine signature that the classical client knows to look for has to be classical. There's nothing we can do about that. But there's also nothing we can do about the fact that that signature is completely worthless in our new security model. So that one byte string needs to provide something from a PQCA that new clients can go look for. And since we get to define new behavior, it's okay if they have to do some work and extract something. And that means that all we've really got is to go smuggle in an extension or SCT. So somehow, we need to take the signal from the PQCA that this server needs to downgrade, jam it into an extension, and then still wrap the whole thing in something that looks like a classical cert to make the old clients happy. That's not going to be pretty, but if we can pull it off, then we can run the rest of the program. And then after the transition, all the new servers hopefully will be able to handle multiple certificates and we never have to do this horrible thing ever again. Details TBD. This talk is why, not how. So, now we have our updated plan. Go deploy the thing. It doesn't really work. And then we add this certificate jammed in another certificate. And then we have the CAs ship those by default instead. And now we can go run the rest of the program. The clients can start requiring PQCAs, and we get actual downgrade protection for what we're trying to do. Any questions?

[00:42:44] **Phillip Hallam-Baker**: So great talk. I agree with most of it, except when you say that we've not faced this before. We have. The SHA one to SHA two five six transition had essentially the same shape. And somebody suggested a transition strategy that looks exactly the same. It wasn't quite a certificate within a certificate, but was damn close. And the problem that I was trying to get around there was a situation where the browsers said, we're not going to support SHA two certificates in the browser until CAs are issuing them. And the CAs were saying, well, yeah, we have the ability to issue them largely because Rush Hausley came at me at IETF seventy two in Dublin and said that he wanted SHA two for whatever. And so, yeah, we had the ability to issue them, but we couldn't sell them because they wouldn't work in any browser. And so this deadlock persisted until one morning, somebody woke up at certain large browser provider and said, oh, we've got to move. And suddenly, the CAs were told, oh, you've got to revoke existing certificates, and transition in fifteen months. And so we have we have been through it all before. The warnings were given, and they were ignored. And I think that we need to remind the people who work for the companies that ignore did the ignoring what happened last time, and that this next time around, we're not gonna

[00:44:37] **David Benjamin**: let them forget. So that one so I was not around for the part where no one was paying attention. I cannot say anything useful about that. I wasn't there. For the tail end, so I think there's there's a couple differences with the SHA-one transition. One is that the SHA-one transition did not require changing the TLS keys, which means that it's actually only that faster curve that we had to work with. And you are right that in order to do that faster curve, we have the relying party problem. I don't know what happened before we all decided to actually pay attention to this. I can't say what happened there. But at the time I showed up on the scene, the relying parties all broadly had support for SHA two, which meant that we didn't have to do this horrible embed one certain inside the other thing. So I guess, in effect, we had more we we had the ten years rather than the, you know, two and a half or so in that transition. We don't now. I don't know.

[00:45:41] **Alicja Kwasniewska**: Alitzia, So I'm not exactly sure if the if we cannot put a downgrade flag into the traditional certificate that says this certificate also available as MLDSA version. And if you asked for that and you have received this, don't trust me. I think that this solving this as a policy for CAs that they should support this and that if you issue for the same SAN, same domain name, a certificate that is for MLDSA and RSA, then the RSA key needs to have this at some point. Like, we of course, we need to do a rollout, where at first, it's not necessary so that they can test it, then they need to commit. And at some point, we have a policy that any new certificate that is issued, with RSA keys must have this because the thing is that, like, you receive RSA, ECDSA key now, certificate now, and you trust it because, like, it this is secure at at the point where we actually have good reasons to believe that we that there is cryptographically secure quantum computer, then the policy changes overnight that nothing that is signed with RSA is ever secure. And you just don't trust it independent of anything else. So the solution then is stop trusting that, stop using that algorithm altogether.

[00:47:27] **David Benjamin**: So the problem with putting a flag in is if it's just a flag and no, like, PQ auth over the flag, is that the only reason you believe that flag is that there's a signature on the overall cert. But that signature is a classical signature

[00:47:40] **Dmitry Shikhmanter**: Yes.

[00:47:41] **David Benjamin**: And is completely worthless once you have a quantum computer. And so the the attacker like, our attacker

[00:47:45] **Alicja Kwasniewska**: assumes that the client doesn't know that there is a quantum computer.

[00:47:49] **David Benjamin**: Sure. Well

[00:47:50] **Alicja Kwasniewska**: And it will, learn very quickly that there is a quantum computer.

[00:47:54] **David Benjamin**: So if I got an email tomorrow morning that there's a quantum computer, I would have a hard time turning off all the classical CAs right now because it would break a large, large fraction in fact, a 100% of the web. Yes. There is a fraction of the web that you can, in practice, break without it spilling over and someone asking you to revert it, And it is very, very low. So it is like, I certainly hope that as there is more pressure to get rid of the insecure thing, that will move faster. But at the same time, there's

[00:48:28] **Alicja Kwasniewska**: the I think the situation with the SHAWAN is very, very apt comparison in that, like, there has there will be, signs before that that that the small, key sizes have been broken, then the larger key sizes will be broken, and then the actual the ones that are are are in use that will be broken. I'm not so sure that this will not be Even if

[00:48:52] **David Benjamin**: we suppose that we do get that kind of warning, the reason the SHA-one thing the SHA-one thing we got lucky. By the time I mean, okay. We got lucky slash, you know, maybe we should've I don't know. I cannot speak to what happened before, but at the time people started pushing on it, there were all the compatibility constraints here did not really exist, and we did not have the server assert problem here, so the server key problem. Like, for the SHA-one thing, you don't have to change your TLS key. In this one, you do. So I think the like, I would love to live in a world where as soon as there's

[00:49:25] **Alicja Kwasniewska**: a I I have second thing, so maybe, let's just, have this one. I very like the don't like the third dachon. And, the reason for that is once we implement something, it will stay. We will not be able to get rid of it. It will be deployed, and it will stay with us, till the end of time.

[00:49:45] **David Benjamin**: I'm This one, we can get rid of because by construction, it was only needed for the servers that did not have PQ TLS keys. So in your cert verifier, you should put code that says only if the SPKI is not classical, reject it. And then as soon as we get to the final place, we take it up. Because this is only a this this was a this was a workaround for the fact that our server software did not have the ability to do this picture here. Once you can do this picture, all this crap goes away. And what what it takes to get to that picture, upgrade stuff. That's what we're talking about in the first question.

[00:50:18] **Deb Cooley**: We have a queue in another briefing. So let's let's

[00:50:21] **Dennis Jackson**: Dennis Jackson, Mazzella, thank you for the great presentation. In terms of the trust model here, I wanna kinda pick apart some of the distinctions between these two approaches. So for the PQ HSTS, you know, you've got to rely on the server operator to opt into it, which many don't today for HSTS. And then that's pretty much it. You're dependent on the client vendor to ship it in preload if that's what they've engaged with. But it works, and it works kinda going forwards. With the Turducken approach, we're relying on transparency. So we're gonna need some chunky PQ signatures in the Turducken signature, and we're going to rely on website operators to monitor transparency logs to check that there's no

[00:51:03] **David Benjamin**: bad

[00:51:03] **Dennis Jackson**: downgrade certificates effectively published. Is that right?

[00:51:08] **David Benjamin**: Yes. Although, though, what's hiding between beneath there is that the PQ thing I mean, I work closely with the people who actually manage the HSTS list. I cannot tell you how often we get people who are like, please take me off this list now. I accidentally deployed it, and I can't deal with it. Right? Yeah. Absolutely. It's a mess. We also have to deal with the size of the list. If we own so it is true. Like, PQHSTS is something we can go deploy right now and move on with our lives. The problem is it will stop being it it will hit a wall. And so the proposal is not one or the other. It's we need both.

[00:51:41] **Dennis Jackson**: Yeah. Absolutely. And on different time scales. For that kind of long term model, like, when we, you know, come to make certificates much bigger because we're including the transparency SCTs effectively, do think you we'll run into issues with that, or do you think that's gonna be pretty much a no op?

[00:51:58] **David Benjamin**: So part of the this is disgusting, one of the things that's going to be disgusting is I actually can't jam it into an extension. It's gonna need to be jammed into an SCT, because the SCT gets stripped out into the pre certificate, and that's what's logged. This way, the CT logs don't have to see it. This is the most gross encoding hack in the world, and I hate it. Yeah. On the needing to look at transparency logs, that is something this system kind of relies on anyway, because what is the server operator actually doing? The server operator is actually saying, I wanna look for an unauthorized key. It happens that some of the unauthorized keys are classical, and some of them are post quantum. But an unauthorized post quantum key is just as bad to you as an unauthorized classical key. There's someone who has who can impersonate me, they're not me.

[00:52:39] **Dennis Jackson**: Yeah. Absolutely. And I think that is a challenge we'll need to work on as well, because, like, c r t dot s h is already struggling, and it will struggle a lot more with this kind of demand. Thanks.

[00:52:50] **Deb Cooley**: Nice job. I think Kyle's next.

[00:52:58] **Kyle Nekritz**: Thanks for the talk. I think it's a great summary. One thing I wanna mention, I think it's also important to keep in mind the different steps where either a server client starts to do something expensive and making sure that at every step of the way, there is a benefit to doing that expensive thing. Because, you know, even if with accelerating these these curves, if there isn't an incentive to be one of the first movers because you have to deploy some huge certificate that kills performance and you don't get any actual security benefit, then that may make things go very slower. But I I agree. I think we're gonna have to do some kind of nasty things in the short term like, this to, like, get progress.

[00:53:45] **David Benjamin**: Well, the benefit to getting onto that bigger curve is that you don't break when the first line hits you. But it's, on the one hand, sort of a disappointing answer, but it's also kind of the answer for all of this. Like, why do you wanna deploy a PQ certificate? It doesn't actually help you as a server except that you expect that these guys are gonna require it sooner or later. Because otherwise, it's like you're wasting you're using bandwidth. Like, if the server if a client comes to you and says, I accept EZDSA or PQ, it is rational for you to pick EZDSA because apparently they both work, and this one's way cheaper. But, you know, we have to do this transition somehow.

[00:54:22] **Daniel Kahn Gillmor**: So I I wanted to thank you, David, for the clear thinking and the and the planning work that you has gone into this. You this is a very a very, very useful frame. I'm curious what you think which parties you think need to be involved with policing the refusal to issue the, the dangerous certificate. So if I'm a server operator, and I'm, you know, updating various, endpoints, I need to be really sure that I'm not gonna get the classical and the post quantum, and entity certificates both issued. Right?

[00:55:01] **David Benjamin**: Yep. That's a

[00:55:03] **Daniel Kahn Gillmor**: And so are we putting the onus for that on the server operator? Or are we saying that CAs must not issue if they find an example of a valid cert for the same endpoint in the transparency logs? Like, whose job is to police the refusal to issue the the thing in that in that split case?

[00:55:23] **David Benjamin**: That's a good question. So just in case other people didn't get it, the what what what he's talking about is that in this picture here, if this certificate also exists, you didn't get anything useful because the attacker will, like, send you this one. And indeed, of the To make this step meaningful, you have to not issue the diagonal certificate once you get here. So the good news is that because, at least on the WebPKI, our sort of PKIs are Like, have this transparency property, someone can go look for it. The question is who is that someone? Ideally, the server operators will all go look for their own things because in the sort of more general, is there an unauthorized key at all case, I can't like, only the server operator knows. But in the long tail, they're not doing that. The the good news, though, is that and this is actually why so if you were following the plant stuff where we replace the key with a hash when we log it, the reason we made the change to put the public key algorithm back in was specifically this picture. If the public key algorithm is visible, then if you have this cross certificate unexpectedly, it will be visible in the ct logs and so anyone can go flag it. Now it is not necessarily wrong to have them both because when you're in the middle of doing that transition, you will have them both. But you should expect that once this guy exists, that guy will expire and not get renewed. And so hopefully we can anyone can see this data, so hopefully someone can go build tooling to go flag this. Maybe we should also have rules on the CAs. Like maybe there's some kind of CA record where we say like, don't generate this cross certificate. I'm ready. I don't know. I'm kinda spitballing. These are sort of details that we can go fill in once like, underneath this framework.

[00:57:09] **Russ Housley**: Hi. Russ Housley. Your turducken certificate looks a lot to me like an x five zero nine v four cert.

[00:57:17] **David Benjamin**: Unfortunately, the only reason it exists is to make the existing clients happy. And the existing clients do not know what an x five zero nine v four cert is.

[00:57:24] **Russ Housley**: And and we discussed them in lamps because they have the fields you're kinda shoving in there. Yeah. And the fact that every parser will puke is is really important. Yeah. So we decided not to go that way, which led to composite, which dot dot dot. Right? The other thing is please call it a diagonal cert. A cross cert is something else.

[00:57:50] **David Benjamin**: Oh, yes. Yes. Yes.

[00:57:54] **Russ Housley**: But but this is something we all need to work on, and I appreciate the thought that went into this presentation and and the the real analysis. And we all need to work on this together, but I really do think v four certs is not the answer.

[00:58:09] **David Benjamin**: I I agree. V four certs are not happening. This is if if we do the gross thing, it's gonna be jammed in an SCT, and the old clients will ignore it, and it's gonna be gross. But you know?

[00:58:23] **Dmitry Shikhmanter**: So if you should meet Google, I will disrespect David Benjamin's talk by responding to Alicia's thing instead. Unfortunately, we will not necessarily see, like, a slow increase in quantum computers breaking stuff. That was what I thought as well until a bunch of quantum physicists disabused me of that notion. Apparently, there's multiple multiple things that are happening in the in the quantum world. A, we are seeing less and less research being published. There's more, like, pressure to not publish things. I hate it. And if you hate it as well, please speak out about this. There should be some discussion at National Academia of Science where we hopefully can reach the physicists and tell them that no public disclosure is very important to us. That is the first thing that makes it very hard to to see these threats coming. The second thing is that a lot of these things that they're currently working on are what's essentially software updates for their quantum computer. So they don't need to do a whole new, like, whole new hardware generation. They need to improve how the quantum computer deals with its hardware that already exists. And that means that instead of having, like, a year or more between, like, iterations of how it gets better and better, you might have, like, a month or a week or, like, nobody being told at all. So I'm very, very scared of the dynamic that I'm already seeing happening of, like, less research is being published, which I think is extremely dangerous and irresponsible, but I'm not a physicist, and I know that I'm not talking to physicists for the most part. But it is a thing that I'm seeing. And the second thing is that it's not a hardware generation thing. It's a software generation thing, which makes it much, much quicker to go from a small example to a large example.

[01:00:33] **David Benjamin**: Yeah, that makes life hard.

[01:00:34] **Deb Cooley**: So just to note, I have locked the queue after Nalini because we have another talk.

[01:00:40] **Mike Ounsworth**: Mike Ellsworth. LAMPPS has had a sequence of various turducken shaped drafts, right, starting with draft Trotsky in 2018 and then draft chameleon that came out of the Japan. And then we now have cert discovery, which is actually an adopted draft, which I think actually matches at least the abstraction you have on the slides. If you we have an adopted draft that can probably do what you want. Come talk to us. Don't don't invent something new, please.

[01:01:05] **David Benjamin**: Yes. I I I'm aware of Chameleon, but I haven't looked too closely at the others. Alright. I will need to look at that one.

[01:01:12] **Deb Cooley**: In the queue.

[01:01:13] **David Benjamin**: Chameleon is unfortunately slightly different in that there's this is getting into detail. Okay. We can talk offline about how yeah.

[01:01:20] **Nalini Elkins**: Yeah. Hi. This is Nalini. Yeah. No. Really, really interesting problem. I'm not quite so sure about the the seven CA or, you know, there's a lot of CAs, And it I seem like it depend by region. I'm gonna look some more because I know I did a bunch of testing in India, and there is a a bunch of them. Yeah. So, anyway, yeah, just thought I'd throw that in.

[01:01:48] **David Benjamin**: Are indeed a bunch of CAs. There are way more servers. So there's still an s curve up there. It's just a faster one than the other one. So

[01:01:57] **Deb Cooley**: thank you very much for doing all of this work and practicing and and whatever, and we're we apologize for possibly screwing up your slides.

[01:02:05] **Justin Richer**: Oh, no. It's fine.

[01:02:06] **Deb Cooley**: But this is yeah. I don't know. You can probably leave it out. I bet Mike needs it. Here. You can so so this he's not this isn't like a done deal. Right? So if you have a good idea, now's the time. Thank you. So our next talk is by Mike Ounsworth on privacy in rats. And we're going to make him hold the mic too. It'll keep his hands busy. Thank you.

[01:02:49] **Mike Ounsworth**: But how do I hold my fidget spinner? Hello. Okay. That was fun. Thank you, David Benjamin. My brain is still in PQ. This is a rough transition. Okay. This talk, why is it here? Why are we doing a rats talk at SAG? Because there is a research problem slash public service announcement slash other working groups that are not rats or consuming rats, and we want to make sure that there's some broad awareness of a part of rats that rats doesn't specify that other working groups probably should be aware of that is not specified. There is a draft for this. I'm not really gonna touch the draft here. I'm mostly gonna focus on the the motivating research problem. And this is work done, with Hannes and one of Hannes's master's students who's doing a thesis on this. So RATS, remote attestation. Very, very, very briefly, it is a framework architecture for devices to attest themselves to a remote party, prove some or provide evidence for some property of themselves, and Rats defines all these roles that you need to make the ecosystem work properly. I'm gonna not touch this at all. The question that we're asking, our core research problem that's driving this work is what if the verifier is malicious? Either actively malicious, like, have your device in my hands and I'm poking at its attestation service as an attack vector, or passively malicious, like the verifier is some service and they're being really sloppy with logging or something. And this is the research question we're starting with, and we get down into what we're sort of talking about, like coercive use of rats. When could you coerce a device to do something it probably isn't in its best interest to do? And then we're asking how many of these attacks have sufficient mitigations already in the rats corpus of documents, and how many of these attacks you would need to add something in addition to rats, what's currently specified in order to close that attack vector. So this is this is our research problem we're starting with. And there's some already even though we're not very far in, there's already some interesting, we think, things that are worth bringing for public awareness here. So what our draft is or what it is not, we are not proposing a protocol. We are not proposing anything implementable directly. We're proposing a technology agnostic framework for adding a privacy layer because fundamentally, the thing that's missing is a privacy layer on top of RATS. So we're proposing a framework to to do a privacy layer. And this, of course, uses existing RATS components. There's nothing wrong with the RATS components, but they are not complete and sufficient to solve the full privacy problem, which may or may not exist depending on what your deployment architecture needs for its security model. Okay. Well, I'm bringing this to SAG because there's a long list of working groups that are starting to consume rats and carry rats and transport rats, and some of these may or may not be aware that privacy is not included.

[01:05:53] **Hank Birkholz**: That's it.

[01:05:56] **Mike Ounsworth**: Okay. So let's work through a couple of thought experiments here. So this is the attacker directly poking at at an attestation service. So let's let's assume the thing is an HSM that's holding super sensitive keys, and the attacker is able to poke at its attestation service. You can imagine ways in which maybe this attest the attested data, the attestation is helps the attacker to perform their attack. Thought experiment launched. So what you really want to happen in this case is for the attester to say, sorry. You don't get to know that. But doing this presupposes some building blocks that we don't have. This presupposes an authentication and authorization layer that allows the attester to know who is asking for this information, and that's the piece that's that's not well specified currently in the RATS corpus of of RFCs. Okay. So going from a fully unauthenticated, verifier, you can imagine maybe now let's step up a little bit. So you can imagine that the person asking for the attestation is a network admin, let's say. And in that case, maybe the HSM should produce evidence that's relevant to network inventory type situations. Here's what I think my IP address is. Here's my vendor. Here's my model number, serial number. Okay. So now we're producing evidence targeted to a specific role of verifier, the network admin role. And you can imagine going higher. Maybe maybe the HSM's manufacturer runs a verification service that will knows how to look for indicators of compromise or something, so they need more detailed information about the device. Maybe maybe for them, you'll release the current software version and the list of policies and configuration. You still, to the vendor, if this is like an HSM holding CA keys, you still don't wanna release operational data. You don't wanna release super detailed audit logs or details of the actual keys. The the manufacturer doesn't need to know that. So then you could imagine at the top level, maybe the HSM's security officer, the actual operator of this thing gets to see everything. And maybe you wanna tie audit logs to attestation. Maybe there's value there. Maybe the you know, you wanna puke out the full list of keys that are in this device. So the point of this thought experiment is to motivate that we shouldn't be thinking of of attestation as a binary, either attest yourself or not, but maybe we should be thinking of it in grades, of increasing levels of sensitivity of of the attested data, which is what motivates thinking of this whole problem as a privacy shaped problem that of quite obviously requires some sort of authentication and authorization layer. The verifier is not a yes, no property, but the verifier should be classified into roles. So is this concept defined in RATS? Well, sort of. Nine three three four uses this word trusted verifier. Nine three three four requires the verifier to be a trusted entity. Trusted okay. But that's not well defined within the current document. So what we're proposing is it's time RATS is sufficiently mature that it's time for us to go a layer deeper and maybe produce a set of documents that maybe maybe are protocol documents, maybe are just framework or best practices documents that start defining what we mean by trusted verifier and how an attester is supposed to establish that property. Usama, I see your question. I will take it at the end. Second example, thought experiment number two, what about confidentiality of evidence? So you can imagine this evidence might also be sensitive itself, and you might wanna protect it against accidental logging as it passes through various cloud pieces. You might want it to be object level, not transport level encrypted, but object level encrypted, all the way to the verifier. And this presupposes that the verifier has some sort of encryption key you can do bulk encryption for. And at the risk of blurring here from problem statement into proposed solution, as soon as you give the verifier an encryption key, they now have an identity, and you now have something that you can do authorization checks against. So this sort of implies a nice, trust store shaped solution that solves both both types of problems in one go. Is evidence encryption covered by rats? Again, sort of. Nine three three four and nine seven seven one do mention that you may do encrypted or encrypted CWT envelopes, but it's only really mentioned in passing. There's no implementation guidance or security considerations or privacy implications or anything. So we're, again, proposing that there's value in developing a framework or best practices document here. Which brings us to, yeah, the general shape of solution. So if and I'm going to stop here. I do have more slides, but what I wanna do just for this talk is to bring awareness to the problem, not necessarily the solution we're proposing. If I've got your interest so far, please read the document. But, yeah, I mean, if I've sort of convinced you so far that there is a privacy shaped problem that is under specified in the current set of RATS documents, I think it's probably fairly straightforward that the answer is just to go smack CIA in all the appropriate places and then define how you sort of trust, store, authenticate, how you you know, you need to be able to grade the claims that you're producing into various buckets that are appropriate for various levels of of authorization of verifiers. And we're proposing that the IETF is in a good position to produce a best practices document to guide this, to fill in this missing piece of specification. And that's it. I will stop there. Usama?

[01:12:05] **Deb Cooley**: But, Usama, I'm gonna set a timer for you, a two minute timer. That's all you get.

[01:12:10] **Usama Yasmin**: Okay. So the way we designed RATS was that privacy was kept out of scope. Intel has EPIC scheme, which it tried for several years. It it it was demonstrated in the real systems, and then it was discarded. So the so my concern here is that, number one, the RACS was not designed with the perspective of privacy. Number two, Intel has literally tried this. Epic scheme was there, and then it was discarded. Why are we going back to the history?

[01:12:39] **Deb Cooley**: Nope. Write that down.

[01:12:43] **Mike Ounsworth**: Because it still needs a solution.

[01:12:51] **Hank Birkholz**: Hi. This is Hank. I want to start with a general clarifying question. Is this about policy? Because you now have to disclose information about the verifier, what the verifier does, who the verifier is owned by, why it should be trustworthy. Maybe the verifier is itself in a tester and you build the rat's nest, and have to solve that problem. Sorry for the term. So that's my first question. I'm gonna start with that, and I have a follow-up question then.

[01:13:27] **Mike Ounsworth**: We are currently proposing a research question, not providing answers to said research question. So I think, yes. That's a very much in scope type question. Yep. Is there is there a back inverse privacy problem of providing too much detail with sure. Fine. Yeah.

[01:13:45] **Hank Birkholz**: That that's a good reason why we didn't delve into the PII items, and by extension, I guess, the superset confidential items, because we are not chartered for policy problems at the moment. So that is why we were have we have we were basically forced to dance around the topic a little bit. But I'm also highlighting that we are nevertheless aware of the problem. That is why the architecture states that in some scenarios, evidence might contain sensitive information, such as personally identifiable information or system identifiable information or confidential information. So that's obviously clear. And then it states, when evidence contains such sensitive information, a tester typically requires it to verify or to authenticate itself. So the requirement is actually in the architecture. We've written that down. Unfortunately, doing so requires us to talk about policy. To effectively create or answer that research question has a policy aspect to it that we are not chartered for at the moment. And then if you rechart all that, I think that's great. But also then we go into the policy domain, which is maybe not what everybody wants. So how do we deal with that?

[01:15:02] **Mike Ounsworth**: So part of why I'm doing this talk here in addition to rats is there's other working groups that if, you know, if you're carrying this stuff over EST, you need to know that you maybe need additional metadata. Hannes presented today at LAMP's his freshness draft. Yeah. Sorry? Yesterday. Yesterday. Yeah. The freshness draft for for how to carry, SSH over CMP. And one thing that came out yesterday was, but if you need to encrypt the evidence, don't you need to send down an encryption cert? Oh, wait. Maybe we're missing an extension for that. Like, the point is this is not a this problem is not contained to the rats working group. It does bleed out into other working groups who need to know to that they need to solve this problem explicitly.

[01:15:49] **Hank Birkholz**: Right? We definitely did not try to specify JWTs and CWTs. We were using them. So, yeah, reuse is a RATS tradition, I wanna say, or a classic way to deal with these things. So I I I still might a little bit confused. What's what's what's the call to action here?

[01:16:08] **Mike Ounsworth**: I'm sort of doing a dispatch talk, I suppose. We have a privacy framework document. Is this a useful thing? Would anyone like to read it and give us feedback? And I think this document probably and I've already received some feedback from people outside of rats who say, yes. This a privacy framework on how SCITT, for example, should consume rats correctly as a useful document. So this is a public service announcement that this document exists, and should we go forward with it? And does anyone wanna read it and give

[01:16:36] **Deb Cooley**: us Okay. Feedback, Raising awareness.

[01:16:39] **Mike Ounsworth**: Raising awareness, yep, of this work, which is from but not contained within the Rats working group.

[01:16:50] **Stephen Farrell**: Hi, Mike. Thanks for the talk for, this important topic. It it seems like Yes. Maybe I I'd like to try to hear break that problem down a little bit. And I think in the slide you didn't show, you're like, next slide, where you talk about a little bit of technology, is is is helpful here. Because it seems like there are two, you know, categories of of evidence you might need to worry about. Yeah. This one. One is things which the verifier needs to see, but are sensitive, And the other things which the verifier actually didn't need to see but needs to be persuaded of and are sensitive. Right? So, you know, a a classic example here is, you know, there are lots of systems, things like attestation for, you know, for FIDO keys or attestation for, TPM, where you actually don't need to know the identity of the of the endpoint. You should know that it's got that it's a valid FIDO key. Right? And so there's a bunch of a bunch of work done to, like, you know, avoid it and find which Fido key it is, but, like, demonstrate this a valid Fido key. Right? And, you know, and then and then there are things where actually, no. I need to see this entire long, like, thing, and that's where you end up with encryption. That's why and I guess how you end up with, like, both zero knowledge proofs and encrypted in the verifier as things you used to do. So, I mean, does that taxonomy ring true to you, and does that suggest that maybe there's actually two pieces of technical work that have to happen here?

[01:18:13] **Mike Ounsworth**: I understood 25% of the words there. I I think Yeah.

[01:18:19] **Stephen Farrell**: Sorry. That audio is terrible.

[01:18:21] **Mike Ounsworth**: I and I'm standing in a bad place with respect to the speaker. But I think, yeah, I think we're on the same page. I think what we're trying to raise awareness of is there's a privacy problem here that if you want to give the end device or more specifically the user, the human user of the attester more control over their data and what's being attested to whom, there's a privacy problem here that's not been very well addressed. That's that's it. That's really all I'm up here saying.

[01:18:48] **Stephen Farrell**: Okay. I mean, think I agree with that. But I guess I'm just trying to distinguish between cases where you actually wanna conceal the information from the verifier versus cases where you wanna conceal the information from everybody but the verifier. And those are different things. Right? Am I wrong with that?

[01:19:09] **Mike Ounsworth**: I can't hear him at all. I can't hear you, but the front row is nodding yes.

[01:19:14] **Stephen Farrell**: Okay. This is so problematic.

[01:19:17] **Deb Cooley**: So Hannah says yes.

[01:19:18] **Stephen Farrell**: Okay. Thank you.

[01:19:20] **Roman Danyliw**: Yeah. Eric, the the the speaker points away from from Mike. So

[01:19:24] **Stephen Farrell**: Yeah. I know. It's a train wreck, but I can't really think about it. I can't I can't move it.

[01:19:27] **Mike Ounsworth**: Yeah. No. I get it.

[01:19:29] **Deb Cooley**: Can you not? So I have locked the queue after Hank too.

[01:19:36] **Hank Birkholz**: Yeah. That's fine.

[01:19:39] **Sean Turner**: I'm sorry.

[01:19:40] **Deb Cooley**: I can lock the queue in front of you. Do you want

[01:19:42] **Mike Ounsworth**: That sounded like a threat. If

[01:19:44] **Hank Birkholz**: I if I lower my hand, I'm out. I I hear that. Okay. So this is Hank. I'm not trying to prolong this. So selective disclosure and zero knowledge proofs are, obviously, solution parts that can go somewhere that's no of no discussion. Yes. Transparency servers always help to some extent, but also a little bit privacy concerning. So the delicate topic. My question is two part question. What which party does the architecture actually cater? Who who which party is helped here? Which party is in need by the Rett's architecture and is catered?

[01:20:23] **Mike Ounsworth**: This feels like a trap. Why don't you answer your own question for me?

[01:20:27] **Hank Birkholz**: Exactly. It is the relying party. The relying party has no idea if it should trust its remote peer that is the attestor. And that is why all these RADSDANs exist. Right? So the attestor's goal is to appear appear believable, of course, because that's why we're doing RADS, trustworthy to the relying party. If the attester is doing something pretty stupid, like exposing PII or vulnerability about itself to appear trustworthy to the relying party, it is doing a really bad job at it. And I want to highlight that that it is against the goal of the whole architecture.

[01:21:11] **Mike Ounsworth**: So if your argument is premised on the attester doing something really stupid and that thing that is really stupid is not well specified, then I think the specs are not sufficient.

[01:21:23] **Hank Birkholz**: Yeah. Well, it's in the abstract. Right? So so very beginning of the text. But, yeah, it's all in the text. I think your problem is valid, but I don't think it's a negligence of the RL architecture. I think it's where it was six years ago when we wrote it with the scope of the charter. And and I think the scope of those data can can

[01:21:43] **Stephen Farrell**: be changed. To then be

[01:21:44] **Mike Ounsworth**: be perfectly fair, like, yeah, RATS is this vast pool of things, and you have to start somewhere and make progress, and I'm arguing that now is a good time to tackle the next layer of the onion. That's it. There's no criticism against rats. And it's good.

[01:21:55] **Roman Danyliw**: It's all good. Technology's good. I

[01:21:58] **Mike Ounsworth**: think it's time to add some Lego blocks.

[01:22:03] **Deb Cooley**: Okay. So thank you very much. I wanted to leave a little bit of time for AOB just in case somebody had something else they wanted to say. We have, like, I don't know, five or six minutes. If anybody else has anything they wanna come to the mic to say.

[01:22:20] **Speaker 19**: Yes. You may or may not know, there was a discussion in Thales about random number generation. If you missed it, you're lucky because that was not very nice or constructive. But reading that made me read forty eighty six. I think it's quite outdated. Thales says you should use your operating system library r and d. That's good. But then he also say, if you don't like that, you can implement your own four from 4086. I don't think we should say that in the future. So could we retire 4086? Maybe maybe we should have some other document. I don't think it needs to be like 4086. I don't think we need here's how you do your own RNG.

[01:23:09] **Deb Cooley**: Have you read the CFRG?

[01:23:11] **David Benjamin**: Let's see.

[01:23:12] **Deb Cooley**: 87 something something something?

[01:23:15] **Speaker 19**: That's Oh,

[01:23:16] **Deb Cooley**: that's after accuracy. Yeah. RFC numbers don't roll off my tongue. I'm sorry.

[01:23:20] **Speaker 19**: That's a bit different scope, think, and a bit narrow. But yeah. But I think 4086 should be made historic, and then we can discuss what Well,

[01:23:32] **Deb Cooley**: we do that. That that that we can do. Replacing forty eighty six, I think, is a little bit of a rabbit hole, unfortunately. Yeah.

[01:23:41] **Speaker 19**: I think we should make it historic even if we don't publish anything new.

[01:23:45] **Deb Cooley**: Okay.

[01:23:45] **Speaker 19**: Make it historic, and let's discuss in some fora, which is not TLS, how to do something.

[01:23:53] **Deb Cooley**: Oh, yeah. 100%. If we should do something. So I would like to know how far off track the CFRG draft or c f r it's an RFC. The CFRG RFC is.

[01:24:04] **Speaker 19**: I think that says you should have a you should have a secret key and then you include that in your I think that's good advice, but I don't think it's the solution to all the

[01:24:17] **Deb Cooley**: Okay.

[01:24:17] **Speaker 19**: Problems. I think the general I think TLS the new TLS document gets it right. Use the library and the operating system RNG.

[01:24:27] **Deb Cooley**: Right. So we I don't okay. Yes. I mean, making $40.86 historic is pretty easy. Yep. So we can we can totally do that. Thank you. 8937. Chris says.

[01:24:44] **Roman Danyliw**: Mike put it in the chat.

[01:24:47] **Deb Cooley**: Oh, there you go.

[01:24:48] **Mike Ounsworth**: I don't that'll roll off my tongue either.

[01:24:52] **Deb Cooley**: Shocking. I mean,

[01:25:00] **Roman Danyliw**: Anything else? Take the wind out of you with presentations.

[01:25:05] **Deb Cooley**: We can give you back six minutes. Thank you very much.

[01:25:10] **Mike Ounsworth**: Thank you.

[01:25:10] **Deb Cooley**: Good travel. Safe travels.

[01:25:12] **Roman Danyliw**: Yeah. Safe travels home, considering that,

[01:25:14] **Mike Ounsworth**: you know, maybe this is the end of your day.

[01:25:20] **Roman Danyliw**: What? There's only two more sec.

[01:25:25] **Mike Ounsworth**: No. I got one too.

[01:25:28] **Deb Cooley**: Yeah. What? The end. Right? There's no more session.

[01:25:30] **Roman Danyliw**: Yeah. But we're doing two.

[01:25:33] **Deb Cooley**: We saw this. Yeah.

[01:25:34] **Hank Birkholz**: Was gonna

[01:25:34] **Deb Cooley**: see if

[01:25:35] **Justin Richer**: we saw the Yes. Somebody mentioned that. I was just like,