Session Date/Time: 23 Jul 2026 07:00
[00:00:09] Sean Turner: Excellent. Thank you. Okay.
[00:00:36] Deirdre Connolly: Hello. This is the TLS working group. We're gonna get started here. If you're looking for the agent to agent bot that's next door, it's the last time I'm gonna say that.
[00:00:49] Sean Turner: Okay.
[00:00:52] Deirdre Connolly: So, you all have seen the note well, which discusses your obligations in attending an IETf meeting and participating in the IETf in general, and how we should treat each other. I'll I'll remind folks that it's not just in the mic line and at the mailing list, but also in the chat for the meeting. That also is part of the meeting record and needs to be conducted with professionalism as well. If you're here at the meeting, please log in to the data tracker using the or the using the on-site tool so you can join the queue and so that we have a record of your participation so that we can get credit and have a nice big room next time too. Alright. So that's we'll open up. We've done most of our administrivia, and we'll go into some status of the working group items. What was that on the next do we wanna go into that now? Or No. No. Okay. So we'll we'll be covering these drafts, and then we have some nonworking group items that that we'll cover today. We have shifted a couple things around based on requests and people's availability because our next meeting session is on Friday, last session. Alright. So just as a pre do we have the? Here's a preview of what the Friday agenda is as well. Are there any agenda bashing that needs to happen today? If you're looking for the AIA proto buff is next door. Yeah. Okay. Yeah.
[00:02:52] Sean Turner: Alright.
[00:02:54] Deirdre Connolly: So any anybody have any agenda bashing items? This is what we're be talking about today. Alright. Perfect. Then I will switch the slides here.
[00:03:07] Chairperson: Which one is it?
[00:03:08] Sean Turner: Yes. And I will readily I have Sean Turner. I will readily admit that when putting together this agenda, we asked for a whole lot of time on the I ITF agenda, and we may have over asked. So there may we may end ending early today. I don't know about Friday, but we may end up early.
[00:03:23] Deirdre Connolly: Which set of slides are
[00:03:24] Presenter: your slides?
[00:03:25] Sean Turner: Chair slide. Working group. It might be the last one. No. Maybe you have to reload. Sorry. Sorry. I only updated them like thirty minutes ago. I apologize. Yeah. It's my fault. Yeah. I
[00:03:51] Deirdre Connolly: don't see him.
[00:03:56] Sean Turner: Reloaded. This one feels working to update. Oh, god. How did we get there? Sorry. Luckily, we just have a lot of time. What do I gotta do to do I have to log out and log back in?
[00:04:17] Deirdre Connolly: Let's see.
[00:04:33] Sean Turner: Why does it do this? You got him? You got him? No.
[00:04:39] Yaroslav Rosomakho: No. Hold on.
[00:04:40] Sean Turner: Alright. Sorry. Apologies. Share slides. Come on. Hold on.
[00:04:49] Chairperson: Hold on.
[00:04:49] Deirdre Connolly: On. Let me just spin I yeah. You can do it now. I was just had the thing. I know. Yeah.
[00:04:55] Sean Turner: Why is it not updating?
[00:05:06] Deirdre Connolly: Apologies.
[00:05:18] Sean Turner: Can just do it off. You can do it off. Yeah. I'll just Take a question, please. Share slides. No. There we go. It's there now. Okay. Let me
[00:05:34] Deirdre Connolly: you wanna do it? I can just run
[00:05:35] Lars Eggert: it off.
[00:05:35] Deirdre Connolly: Oh, you're just running off of that.
[00:05:37] Sean Turner: Think I just kinda keep that on the pole.
[00:05:39] Deirdre Connolly: Did you get yourself well,
[00:05:40] Sean Turner: I I did not. Can you just make sure he has
[00:05:42] Eric Rescorla: the full
[00:05:43] Sean Turner: clients and he can change the tone? Sorry. Alright. Hey, TLS working group update. So we scheduled a lot of time for this. So there's it's gonna be a little bit of a roller coaster. Some things you might like and some things you might not like. There's gonna be a lot of me talking and a lot of you hopefully talking back, and we'll see what that happens. And we're gonna time bound some of it just because, you know, there's only so much we wanna get yelled at. Alright. So let's go on. Not to some stuff that's happened. We had some complaints and appeals related to the MLChem and MLDSA drafts. It took us a while to find it, but it buried in one of the emails from 06/27. We had a complaint to the chairs that, included two particular points, and we denied those. I will note that there are other appeals ongoing, but they are not directed at us. And if you went to the player last night, you saw some of them, and they were directed elsewhere. So we're not really gonna talk about them here. I know what's gonna happen with the other complaints, but I'm sure they're gonna happen. Good news. Published RFCs. Oh, look at them all. So we had a bunch pop out. TLS 1.3 is probably the big one. Right? There was a big backlog behind that. So TLS 1.3 is now nine eight four six. So everybody needs to update all their references. With the SSL key log file, which is ninety eight fifty, tls 1.2 is frozen, which basically means no new feature requests. It's kind of a big flare gun to everyone else on the planet. Like, we're not gonna do anything to tls 1.2, including the weekly calls I get for adding PQ to TLS 1.2. We're not doing that. Hybrid design is a BCP document nine nine four nine nine five four, which is going to explains how we're gonna do hybrid going for the MLChem stuff. So that's or the chem stuff. So that's great. We got legacy RSA, SSA, PKCS 1.5. I would argue this was an RFC that we all held our nose and just got it through to kind of, like, go with reality. So thanks for working on that. Nine nine seven three is an update for eight eight seven three, I believe. It's a certificates plus PSK. And then a bunch Nimron did a bunch of work to, like, deprecate a bunch of old crappy Cypher suites, they're out the door and gone. So that's really great. I believe that that RFC just kind of lines up with what the web guys were recommending anyway. So little late to the game, but that's life. In the RFC editor's queue, we have EC, DHE, and ML-KEM draft. So that's how you kind of, like, put the two of them together to do the hybrids. We'll talk a little bit more about that later. And we have MLDSA in the RFC editor's queue, and there's an asterisk there because there's an appeal against that document. So we have to kinda wait for that to all play through. Alright. More stuff that's good. So extended key update. Basically, it's ready for working group call or working group last call and fat review. So the deal here is is that the authors believe it's ready for working group last call. We have no discuss no no issues or or PRs against the draft, but we're kind of waiting for the fat review. The initial fat sniff test was like, hey, we think it needs some analysis. Again, thank you, Tom. And so we're kind of waiting for that. This is one of those deals where we figured it's better to just wait till we actually get the fat review because it takes sometimes take a while it takes a it takes a while to get the formal analysis done. So I think we're just gonna kinda hold it and wait. I know a lot of people want it, and they're very interested in getting the working group last call done. But in talking with the authors, they're like, they kind of understand that if we said we started working group last call, and the first comment I'm gonna get back from Ecker is, dude, where's your formal analysis? So we figured we'd just wait till we actually get it. We recently Chris Woods sent a message to the mailing list that basically saying the FAT the the input for the FAT for the Pake document, this password authenticated authenticated key exchange document is is at least started and going on and have some initial findings. So we're gonna go ahead and send that a request to the FAT to assign a point person. And then when we get hear back from them, we'll make sure to update the the the wiki that we have that tracks that. And I'll include Chris' message on that too because he's actually got some analysis already linked in that draft. I don't know if you've you haven't seen it. It's on the list. You might have to go look for it. Alright. Yeah? Ecker's in the queue.
[00:09:44] Eric Rescorla: Ecker. Well, you're you're certainly right about my question. But, actually, I know we're certainly considering this working group, the supplemental certificates draft. And I know this is many of the same authors, and I think there's obviously some interconnection between supplemental certificates and and a and, you know, a new key exchange. And so I think if we're we should if we do decide to proceed with that draft, we should probably have those pieces of analysis done jointly rather than simply having them be treated as independent things, because it may, in fact, be the case that there are significant implications for, new key exchange for supplemental, certificates or vice versa. And so it'd be very unfortunate if we were to say standardize, the new key exchange and then discover that didn't work properly with health plus certificates, but we can't change it now. So, I know and that sounds annoying, but, like, they're just kinda interconnected in some way. So now if we decide we don't want some certificates, no problem. But you see what mean?
[00:10:44] Sean Turner: The audio is up here. That's why we're trying to read
[00:10:46] Eric Rescorla: the Yeah. I know. I can tell that. This is, like, really unfortunate we can't basically
[00:10:50] Sean Turner: saying it's unfortunate that we have another draft that's dependent on one of these, and we have to maybe wait a little bit.
[00:10:55] Eric Rescorla: Well, no. I I'm trying to say that. I I guess it's really unfortunate that the audio is so bad. What I'm saying is is that if we decide to proceed with supplemental certificates, then we really should have a joint analysis of stuff more certificates and new a aesthetic key update because they occupy they they do they do related things, and it already very sorry if it turns out that e k u doesn't work right self most certificates. So we should so on the basis of whether we decide to con continue with self loan certificates, then we should decide whether or not, whether or not, we we need joint analysis.
[00:11:35] Usama Yasir: Okay.
[00:11:37] Sean Turner: Who's next? Sama?
[00:11:40] Usama Yasir: Sama, to you, Tristan. So I want to ask about the big draft. Like, in the last meeting, they said that they are ready for the working group last call. What is really blocking the FAT analysis to be started? Because now, last week or this week sometime, they have already done all the formal analysis. They have sent it out in the public. And what is really blocking the like, the Fed process is really blocking them from
[00:12:08] Sean Turner: We'll talk about we'll talk about this a little bit later when we get to the Fed discussion.
[00:12:12] Usama Yasir: Okay. Thanks.
[00:12:13] Sean Turner: I mean, this general issue,
[00:12:15] Presenter: not this particular one. Hannes?
[00:12:20] Hannes Tschofenig: Yes. In response to Eka, I think he's referring to the presentation that will come later from Yaron. So maybe we can talk about that specific part there. But for the formal analysis of the extended key update, we have Nik in the in the room to talk to well, he has started and he's progressing the formal met formal review, the formal analysis, and there, he's also considering the work with the existing key update. So we obviously have to see, like, what the working group wants on the presentation that will follow afterwards, and we'll have to include that support potentially. But there's already an analysis ongoing on the key update with the existing authentication, post handshake authentication. And since it's up there that's unrelated to this, the super Chumba record limit, I was working on two implementations on on this. And just recently, John I I don't see him in the in the room. He oh, over there. Hey, John. He was or he's reaching out to his colleagues to work on another implementation, so we we might be just fine with that in in the near future.
[00:13:43] Sean Turner: Man, you're stealing my thunder. Alright, Tom. Go ahead.
[00:13:51] Tomcsanyi: Hello. Hello. Obvious, first thing to say is that the does not do analysis. The FAT looks at other people's analysis and tries to help the working group make sense of of all of that. To Eckhart's point, it is very annoying that we have in in extendable protocols like TLS in general that you can look at the main thing, the main thing plus a, the main thing plus b, and that doesn't really say anything about a plus b. And the reality is that that is probably too much work to do in all cases for all combinations. But in this particular combination, I think it's probably a call on the authors of drafts, etcetera, as well as the things that are likely to be used together or intended to be used together that they spend energy on defining those interactions in their security considerations and trying to spell out what they expect to happen because that will really help the people that do analysis try to get to the bottom of things. Thanks.
[00:15:08] Sean Turner: Jonathan?
[00:15:09] Jonathan Hoyland: Jonathan Hodden-forty eight. Was wondering so I I wrote a draft, I don't know, six, seven years ago about how to extend the key schedule in ways that it would be composable with other proposals. Is that something we want to be able to give feedback to authors to do such that your analysis is composable with other analyses? Like yeah. Is it worth making your like, is it worth having people adjust their proposed extensions such that they can be composed in terms of analysis?
[00:15:54] Sean Turner: I mean, maybe. Yeah. Alright. Let me get So the column on the right there is implementation experience. As as Hannes noted, the superjumbo record is basically done. It's ready to go, but we're waiting for because he's got two implementations. We're waiting for another independent implementation. Keyshare prediction and trust anchor IDs are kind of in the same boat. Tls-flags has kind of been in this waiting for implementation state as well for a while. And the well known ECH one, and we're also we know we have one implementation, we're waiting for a second. And Stephen and I, I check-in with him like once a month or something. He's like, yep, it'll be here eventually, you know, blah blah blah. So good to go on that. Next. Alright. Some good stuff, some bad stuff coming up. Alright. So this is the chairs have determined that there was consensus. We had this whole document stream where we did the hybrid thing, and then with the EC, DHE, ML-KEM draft, and it was, you know, informational no for a while, and then it went standard strike because we were downgrading the the the temporary code point. And then during another call, we just it turned out that there was consensus to actually move the X25519 MLKEM to recommended y. So we went through the process of updating it through the working group, and that went through IATF last call. So now that's kind of sitting in the r c h r's queue waiting for the process to happen as it kind of goes through and gets the copy edit stuff. So again, it is I don't want people to forget this standards track. There is one Cypher suite in there that is marked as recommended y. Then we have the other one which causes lots of controversy, which is we did determine very recently that there was consensus to progress the the ML-KEM draft. And again, remember, this draft is informational track and all the values in that document are recommended equal no. Alright. Okay. So this behavior. This list has is unbelievably toxic. It's been bad, really, really bad, seriously bad. We don't love it. I know you don't love it. I get lots of complaints about, like, what's going on and how do we stop all this stuff. So we're trying to figure out how to do that. We've been sending monthly reminders. I don't think you read them. There's been a typo in it for a year. I think it's like a little bit of a fish thing there where nobody, like, caught it, so I'm gonna fix that and we're gonna update it. It's it's really not been great. So and again, some of this is probably because the chairs are not as quick as to moderate as we should, and we're going to try to change that. Some part of that is we've learned some some new tools. Some of my, you know, people that are that are chairs that I kinda, like, look up to were like, you know, you can do this. Was like, oh, that's very exciting. So you may have seen that I squelched a thread. We are gonna start doing that going forward. When we determine something is off charter or, you know, out of charter, we're gonna squelch it. And if you don't like it, you can appeal to the eighties. And then a reminder that the IETF system wide, the whole thing, right, has a moderator's queue. And it's formed, they're working on the process. And I believe that we're probably at the top of the list to get looked at. Alright. So we're gonna do a show of hands. Joe, do you mind? So now we're gonna do a show of hands. We're not trying to fit with a show of hands. We're not really trying to, like, get consensus. I just kinda got a good sense of the, you know, 100 people in the room or whatever. The list has been a little crazy, and so we're kinda trying to get a sense of, do we think we should do something more to make it kinda more functional. Right? So I think, hopefully, the answer is yes here, because if not, we should close the working group and go away. And and by the way, that's not the first time I've threatened to close the tls working group.
[00:19:56] Felix Linker: Alright. I
[00:20:00] Sean Turner: I'm gonna ask them to get to the microphone. Alright. Looks like it's it looks like it's pretty well. And I know, Eric, I'm I'm taking a lot of liberty here. This is like a monologue. So go ahead.
[00:20:18] Eric Rescorla: I'm not the person who would know. That's for sure. But, I guess, I just wanted to, like, to actually try to, say something specific here, which is that I think the chair should feel empowered to be, not sure draconian is the word, but, yeah, much more aggressive here. You know, the chair the chairs are not just, there to, like, make sure the the to make sure that, like, the drafts get processed. They're they're exercised tactical judgment, as I was saying last night at the plenary, and that judgment includes where the behaviors are appropriate. And so I, naturally, feel much more empowered to steer the conversation, not only if we're out of I guess, of charter, but also for, again, out of unproductive directions or or to sequence the discussions. And so it's perfectly fine to say this discussion is off topic now or and maybe on topic later. That's exactly the chairs are being asked to do in in in in 2014. So I think the chairs should be feel much more empowered to do those things at this moment, and I I I wanted to voice my support for that.
[00:21:13] Sean Turner: Yeah. I mean, I I tend to agree. It's the point you made last night at the plenary for other things, and I think that, again, I'm just trying to be like, if anybody doesn't get that, they need to get to the microphone and tell me why. Alright? Paul?
[00:21:24] Paul Wouters: So this will have to include messages that some people sent that say that for transparency, I'm cc'ing the tls list. You need to stop those. Right? Because otherwise, you're just adding a meta layer and the same messages will keep appearing.
[00:21:37] Sean Turner: I mean, yeah. I mean, feel people when they we'll get to this later. But when you, like, wanna start talking about process, like, you should let the chairs know. You we don't need to have a a deliration with a thousand of your closest friends on the mailing list because it's not about it's about the technical work of the working group and trying to get the documents pumped out the door, not to endlessly debate the process.
[00:21:59] Usama Yasir: Yeah. So may I request that the appeals and the other process related stuff, could it happen outside of the TLS? Is that possible?
[00:22:14] Sean Turner: Yes. That's basically the point. We're basically saying like, people can send appeals, they can send it like it started, and then we squelched it. Right? So or we call petitions or whatever the heck is going on, we try to stop it. So we're slow, but let me tell you, when my phone blows up on a Friday afternoon and my wife is like, why is your phone blowing up? And I'm like, hey, look, my closest friends in the IATF are calling me to stop a mailing list. I step out and we try to do it to to do to do some moderation. But we're gonna get much more, as the next one, we're gonna figure out more draconian, which means harder. And we're gonna, like, be more willing to deal with, I I would guess, complaints to the AD for us being harder about stopping discussion on the list. So without further ado oh,
[00:23:00] Eric Rescorla: hold on.
[00:23:00] Usama Yasir: So so I have one one one more request. So I don't think everyone in the room is a native English speaker. So when I see like words like doling, I have to first search out what that exactly means, and so on in the process emails and so on. So I think you need some words which which can be more understandable for non native speakers.
[00:23:19] Sean Turner: Oh, yeah. Like, so draconian means harsher. Right? So you're gonna be tougher about that. So I apologize. Of course, I was doing these slides early this morning, and that was the first word that came to mind. Think of, like, I guess, draconian really derives from Vlad the Impaler and taking people's heads off, and so that's probably a little too aggressive. So but alright. So, Tanya.
[00:23:48] Tanya: Yeah. Okay. There it is. I think one problem with the discussions I mean, you said you should stop discussions. I think sometimes the problem is there are no discussions. I mean, the last call, you said no discussions, people should just say yes or no. And so then discussions happened, then other people after you said, please don't discuss, then people were asking other people to justify their opinions. So it would be helpful to do something. So I'm very much in line with, yes, something should happen to make it more functional. But I also think that if there's a change where the change hasn't been discussed, it would be helpful to permit discussion and also enforce discussion, like, I'm saying something, I'm expecting the editor to answer. There have not been any answers from editors and such things, I think, make it a monologue or a dialogue among other people, which could be annoying to people listening from the outside.
[00:24:45] Sean Turner: Fair enough. So I think that as we do this, we'll it'll be a learning experience, and we may step over the line and have to come back and do other things. So we'll learn with you. So I think it's gonna be interesting to see how this goes forward, but we're gonna definitely try to make the list a little bit more functional. Next.
[00:25:02] Deirdre Connolly: Alright. Do you wanna do the
[00:25:03] Sean Turner: Oh, we should do the show of hands. Yeah. Oh,
[00:25:09] Eric Rescorla: sorry.
[00:25:10] Sean Turner: Apologies. All I get
[00:25:11] Felix Linker: is a whole different thing.
[00:25:14] Sean Turner: Oh, don't. Don't say root certificate in Australia. Alright. That seems to be pretty clear. Does anybody in the know wanna get to the microphone? You don't have to. Thought we'd throw it out there. Alright, Christian.
[00:25:46] Christian Huitema: Well, I I have a mixed feeling about that. I understand that we don't want too much noise on the mailing list, etcetera, etcetera. At the same time, we should also not suppress descent.
[00:26:00] Sean Turner: Agreed. So I mean, that's that's I'm like I think people people can actually easily state their, you know, no opinion, but there's some ways to do it that is better and on point than others.
[00:26:15] Christian Huitema: No. I get that. We we we are the master class in what not to do. But, Steve, I mean, I am always concerned that exceptional condition creates exceptional regulation, and those regulation then come back to bite us. So I'd like some motivation for the dragon eggs, please.
[00:26:43] Sean Turner: No. I again, I I think you're right. And, I I I actually share your concern. And, hopefully, if we overstep the bounds, then people are like, no. Don't do that. And we can go from there. Daniel?
[00:26:54] Daniel Migault: Yeah. I I I do share Christian's opinion. I I did not answer because it took me time to find the the poll. But, yeah, it's I would be cautious in being too too too much in another way or for the future. But Lars?
[00:27:13] Lars Eggert: Lars Eckert, Mozilla. So I don't think what you're asking is, you know, should you be more draconian and and moderating the list under normal circumstances? And I think everybody would say no normal circumstances of moderation or non moderation that's been happening has been fine, and the and the list has been useful to, you know, work on TLS. But in an exceptional circumstances, which we've been under for the last couple of weeks or months, where, at least in my personal view, right, that the the list is purposely being destroyed as a venue for for advancing TLS, you should absolutely feel, you know, that you should take be able to take stronger actions. And I think you have at least my personal blessing to do so. Right? Because, you know, I I really think that people are trying to destroy the TLS working group. I don't wanna open that can of worms, but, you know, need to keep the list useful as a venue. And and under exceptional circumstances, you need exceptional measures at your disposal.
[00:28:13] Sean Turner: I mean, more than a few people have approached me at this meeting and been like, I'd love to bring this work, but this list is so toxic. We don't even wanna talk about that. We don't wanna progress our document. We don't wanna be on the agenda. So I'm very sympathetic to that. And I think at the end of the day, like, we run off implementers or some set of people, that's kinda we don't need a working group then. We can, you know, go to a free for all, that's kinda not the point. It's actually to bring the smart people here to, you know, work on documents that we agree to and then get them done and go through the process. So alright. So we got the message. We'll we'll do better because I think some of it's definitely on us, and we'll do a better job. And if we go too far over, feel free to let us know. Yeah. Alright. Cool. Next. What's off topic? Again, this is the reminder. This is off topic. These are all the things that you see once a month. Again, I'll fix the typo. Buy a beverage if you find it. And I don't care how many people are here. I'll buy them all beverages. A lot of this stuff is based on RC 3,683. One of the things is about derivative work notices, which we've had in there for a while, and it's based on an ISG statement. Wanted to add this one about excessive process deliberations, which I think somebody mentioned earlier. Again, when we do something, and if you don't like it, that's great. You should talk to us first. And then if you don't like what we did, you can talk to Deb. A thousand people debating the IATF process on the TLS mailing list is not productive. If there's something that you want changed or you wanna tilt at a windmill about how the process should be this way or that way, it's typically not on the TLS mailing list because the charter of this this working group is to talk about the actual TLS protocol and the documents that have been or at least that are in scope or close to being in scope. So we're probably gonna add this to the monthly reminder. I thought it was obvious, but, you know, maybe not. All right, the fat. Alright. So it's been a bumpy road. Again, we slapped some little p process onto an existing stream of documents, and we were not uniform in doing that. We got, Osama kinda called us out on that, and so we we had a an update to our GitHub repo pages that basically kind of list like who's the fat point person, when the message was sent, the documents that went through, the documents that didn't. And so that's all kind of good. But with that said, I do have to say that there's definitely more than a few people that came to me and like, hey, that's awesome. I love this fat analysis, but all this process debate is killing us and like we're losing interest. So you're kinda killing us, like take this off list. So I've got some stuff up here. We're not gonna really discuss it more. There's another slide with some some show of hands, but we're gonna see how it goes. With all that said, the bumpy road and the process and the stuff we've had, we still think that this this the the reason for the fat still stands. When we did TLS 1.3, we went to the security research and we're like, hey, guys. How do we make you famous before the protocol gets published? Right? I hated getting these cute little logos and, like, some blog posts, and I was getting phone calls like, I have to pull my security team back from vacation. Can you guys maybe fix this a couple of times? And the fourth time, it was not great. So we we we figured out how to do this. So we still think it's useful. Again, it's a little p process. We've got a we've got a a wiki entry there that's for and the TLS repo on GitHub that kinda talks about it. And so, you know, review it, make sure you understand what's going on in the whole process. And to smooth out some of the bumps, we've we've we added a PR. It's about collaboration because I wanna make sure that the authors are the ones who are because, again, the documents are the thing that's most important in progressing through the working group, and that's really where to get to Usama's question about I have this analysis. It's really the author's role and job to kind of coordinate all of that. The chairs were trying not to get involved, so I did drop a PR that you guys can review and see what you think. I had much more process involved, but the little bit about getting the fat analysis was actually almost as long as the rest of the fat thing. And I stopped myself because I thought, like, that was kind of enough. So please take please take a chance to review that PR there. There's a couple of others in the repo, so feel free to jump in there. And now my monologue is over. Victor.
[00:32:32] Victor Dukhovni: Just a comment about fat. I'm all for it, but concerned that sometimes the the tail is wagging the dog in that in order to make the protocol easier to analyze, we sometimes make it harder to implement. And the balance there can be off by a bunch. I've been spending a lot of time lately trying to make sense of PSKs and TLS 1.3 in an implementation, and many of the rough edges are due to too many things being simplified and consolidated onto one mechanism that then turned out to be vastly more complicated than it might have been. If the protocol were firstly designed for implementation and usability and then secondly analyzed rather than designed for analysis and usability comes second.
[00:33:23] Sean Turner: Victor, you're not the only person to tell me that.
[00:33:28] Alessandro Ghedini: Sama?
[00:33:31] Usama Yasir: Sama, to you, Tristan. I think there is like so there was, like, transparency issue. We all agreed that there was a transparency issue. Some things were done, and even though you call it little p process, but it needed to be declared that due to some reason you are not doing the formal analysis for certain drafts. And I think here, what we need to take into account is the not only the feedback that or the kind of, somehow the process that the chairs have come up with, but also the people who are actually doing the formal analysis of, or have done in the past, or have been doing the formal analysis for that specific draft. Like, I mean, if somebody's already doing the formal analysis of a specific draft, and the chairs come up with the decision that, hey, formal analysis is actually not required, he or she is going to be really shocked by that decision, so as to know that what happened, that why this was not required. Because if somebody's already investing time without having the fact or the chair has given a decision that a formal analysis is required, it means that he or she has gone through some process, or his or her history or experience of the formal analysis that some property might break, or it is complicated enough that according to his or her understanding that this might break some property, I think the kind of the input from those members who are actually doing the formal analysis needs to be taken into account. And the the the process could say that the chairs in collaboration with or somehow in discussion with the people who are actually doing the formal analysis, they come up with this. But I don't think it's fair to say that the chairs make a decision on their own. They do not consult the working group at all.
[00:35:25] Sean Turner: Number two.
[00:35:26] Usama Yasir: Make a decision and say that this is the final
[00:35:28] Sean Turner: Number two.
[00:35:28] Shumon Huque: Yeah.
[00:35:29] Sean Turner: So we're gonna we we we the message is received loud and clear. I will note let's go. Alright. So I guess the first question I just oh, sorry. There's more people in queue. Tom. Tom?
[00:35:45] Tomcsanyi: Hello. Yes. I do think that these procedural discussions are a distraction. It is up to the chairs to invoke, quote, unquote, the formal analysis triage team process. I think that if this is not done, I mean, there should be either something about what was asked to do facts and what they concluded in the working group last call, or there should be a sentence. We didn't do this because and then people can fight about, I am not satisfied because this is much scarier than I think it is that you justified for not doing a fact Right. Call. So, that, I think, is my comment on the first question here. And speaking for myself, not on the, formal analysis, triage team's behalf because that has no leader, no gods, no masters, etcetera.
[00:36:45] Sean Turner: Thanks. Felix?
[00:36:46] Felix Linker: Yeah. Hi, Felix Linker. I agree that the discussions are a distraction, and as someone who I I don't personally work on formal analysis in the TLS, but I work on formal analysis sometimes. To me, I I view the Fed as a head for the working group and not for the people conducting formal analysis, because I think we typically know what to do in the in the ideal case, yeah, and I see the the FAD as a tool for people who don't know much about formal analysis to get an informed opinion on it. So I I don't see how procedural changes can benefit formal analysis. And on I want I wanted to make one comment on what Usama said, that someone conducting formal analysis would be sad if it were not required. I I don't care whether the analysis I may or may not conduct in the future is required by the Fed. Right? I care about do I think it brings value? Is it interesting work? Am I excited to do it? And I think it will be valued also if it was not required. Right?
[00:37:54] Sean Turner: Well, it's not required to be clear. Right? So some people are under the mistaken impression that it is and it's not. Right? The the authors can basically be like, no, but then we will take that into account as we go forward because if 20 people are like, you need to have this analysis due because you're messing with the key schedule, then we're like, okay. Well, maybe we don't progress this document.
[00:38:12] Felix Linker: Yeah. Yeah. But even I just wanted to say formal analysis can provide great value even if it's not required. Right? So Yeah. You still analyze the thing and you enhance the confidence that it's secure. That's great.
[00:38:22] Sean Turner: Alright. Cool. So let's get through these pretty quick. Again, these are I'm not trying to get consensus on these. I'm just trying to get a sense of the 80 or 90 people in this room and go from there. So the first one is do you think the the FAT procedural discussions are a bit of a distraction? 150 people in the room. Alright. We're over time. That's pretty good. Nobody said no. So I think that's, you know, close enough. And there's a lot of no opinions. Alright. So the next was, do you think chairs should be the ones that determine where the draft goes for the initial sniff test? If you're remember that the process, basically, a draft shows up, and if we're gonna do a working group adoption call, the chairs have, to this point, basically said whether we're gonna send it or not. And there are some people that think that's really bad and that it shouldn't be us and that we should either make a part of the process or the whole nine yards. So we're kinda trying to get a sense of the room whether they think we should be in charge of that or whether if there's some other process that we should try to come up with. Alright. Again, we're over time. So let's go. Usama, do you wanna say anything at the microphone? Whoever whoever said no, would anybody wanna say anything at the microphone? No? Alright. Cool. So the last one is the third one is really kind of in line with the collaboration point PR that I have. So this is kind of really not a very fair question because you probably haven't read the PR that I landed like an hour ago. But the idea is the general process is that that the authors are kind of in charge of getting what they need done and from there. I thought this was pretty it's pretty self evident question, but apparently, there's some people that don't think they should be. And it's, again, it's fine to have independent review. But at the end of the day, the people that are trying to get the document done, we think are the ones that really kind of need to help manage this process. And, again, it's fine to have multiple people do the do the analysis, etcetera. Alright. Cool. That's probably good enough. Does anybody that said no wanna get to the mic? Yep. Go ahead, Usama.
[00:40:41] Usama Yasir: Usama, so the question itself, again, is not clear to me, which is saying, do you think chairs should be the ones that determine whether a draft goes to the initial sniff test? Like, does it include the authors? Does it include the people who have done the formal analysis before, or does it include only the chairs maker
[00:40:58] Eric Rescorla: The chairs. On their own chairs. Without
[00:41:00] Usama Yasir: Just the chairs Just the without informing anyone justifying
[00:41:03] Sean Turner: Well, no. I'm not not not informing, but being like, you know, we're gonna we're gonna send this forward or not. We are going to try to remember to do this in part of the process when we take a document in. If we're not gonna send it, or if we're gonna send it, we're gonna send an email that says, we're we are or we are not. We did that for some, but we didn't do for others. We're gonna try to make sure that becomes part of our process so that everyone knows what we did and why we did it. Alright. Next. Again, we're a little over time. So go ahead, Edgar.
[00:41:31] Eric Rescorla: Yeah. So I don't think this last point needs a special rule. From one analysis, there's another there's another kind of another kind of working group review. And so we should all work collaboratively, etcetera, etcetera, etcetera. But I don't think this needs any kind of special rule. And if it does, we go off the rails somewhere. Yep. So, I mean, like, if someone sends me feedback on my, like you know, someone sends me feedback on my draft, like, I have an obligation to respond to that feedback at least, up to, like, the off to the point of, like, not becoming unproductive. And, you know, and that's how that's how we're working at collaboration works. So I don't think that needs needs special rule of some kind.
[00:42:07] Sean Turner: Alright. Cool. We're gonna lock the queue and let Tom get the last word in here. Mike?
[00:42:12] Mike: Mike Ehls- wirth. I voted no. And the reason I voted no is the authors is a well defined set. We know who they are. They're on the document. Those performing the formal analysis, there's lots of excellent groups in academia who do not participate in IATF. We don't necessarily know who's part of that set. Mhmm. I don't think we should prioritize participate IETF participating formal analysts over academics in the community who might be producing better work. We just don't know that they're working on it. So I'm opposed to anything that that gives a higher, like, multiclass status to to academic space or whether they show up here or whether they publish in a journal.
[00:42:48] Felix Linker: I
[00:42:48] Sean Turner: mean I mean, yeah. But, like so the question for number two presupposes that, like, we are, like, in a vacuum and didn't talk to anybody. That's not the case. Right? When a document comes to the working group, we're talking with everybody. We're asking specific questions, like, who else are you talking with and the whole nine yards. So it's not like we're doing it
[00:43:02] Presenter: in a vacuum. So go ahead, Russ.
[00:43:03] Sean Turner: Russ. Russ. You're in the queue. Do you wanna be in the queue?
[00:43:09] Martin Thomson: Sorry.
[00:43:10] Russ Housley: Okay. Alright.
[00:43:14] Sean Turner: Chris?
[00:43:20] Chris Wood: Yeah. Chris Wood. I just wanted to sort of plus one to Ecker. I think as editors of the draft, you should just feel empowered to work with the people conducting analysis even if or or even not work with them. Like, if you find someone who's published work and hasn't contacted you at all, if it benefits what you're doing, incorporate it. Like, we don't really need to make a tremendous amount of process or rules around how editors should or should not engage with people who are doing formal analysis. It's like it's far too much. Just enact good judgment and try to make sure that, like, whatever comes out of this working group is the best possible thing. Yeah. It's really this is very quite simple, and I'm not sure why it's being over complicate overly complicated. K.
[00:44:03] Sean Turner: Thanks. Next and last, Tom?
[00:44:09] Tomcsanyi: This is me again saying that the FAT does not do formal analysis. The FAT helps judge if a document is well supported by the arguments that are presented in that document. I think that the main function of the FAT is not so much to evaluate formal analysis or third party analysis something. It's to evaluate if the claims of a document are reasonable and supported by anything approaching a convincing argument. So for extended key update, for example, they are claiming to do get post compromised security, and we looked at, okay, what does that mean? Are there a bunch of edge cases maybe? And then we decided, okay. This is kind of a big claim to add to the new protocol, so maybe it is good, in our opinion, to look at that further. Yep. Then it goes back to the authors and and the the whole working group to either decide, okay. These academics are overzealous. We are fine with the argument, or we want to see more work. But that is not up to the fact. Working with the authors and whomever is doing the analysis seems wise. I also think that the people in the fact will be open to questions about, okay. We phrased it like this, but that didn't seem to work for you. What is missing? Those kinds of questions, we're very happy to answer. Yeah.
[00:45:40] Sean Turner: I mean, I'll say that everybody on the FAT that I know and have met is extremely personable actually and and very willing to help. That's kinda why they're doing it. And one of the things that I've started to do with people that want to present here, I ask them specifically, hey, if you think you need formal analysis, have you thought about trying to figure out how to get a relationship with somebody to get that going? So that you should see people when new things come up that they are saying whether or not they are working with somebody already at the beginning. So we can stop some
[00:46:10] Presenter: of the the bumps we've had in the past.
[00:46:12] Sean Turner: Ecker, up to you. Thank you very much for the long monologue. Time. Slide control. Alright. We have passed slide control to you, Ecker.
[00:46:41] Eric Rescorla: And, also, I was talking to a muted mic, so it was very was very exciting. It's it's some good stuff. So this is actually gonna be quite short. Honest and enormous amount of work in going through the issues and generating a bunch of PRs, and I've gone through and landed a bunch of them. So we're actually quite close to having, like, most of most of the issues that have been raised addressed. So, hopefully, we can get there sooner. So changes to this o one. I'm gonna go through these very briefly. You can, of course, look at the GitHub, repository for yourself. So we did a bunch of clarification on key update in the post handshake. We require checking for, future epochs and acts, and that's forbidden. It turns out that you actually can't get to epoch two to 48 because, you can't do two to 48 handshakes, for for technical reasons about the message sequence number. You can get it turns out you can sort of get the two to 16. So, we had some new text about that, especially with David Benjamin that kind of indicates how you can do things. We did a bunch of clarification, the act handling, and, we clean cleaned and and thanks to Martin Thompson, we have some new text about how to handle, invalid records, that really just just help you to clarify the situation, and and about how TLS and, detail and details behave differently. So, again, people can go back and look at this for themselves. There are two outstanding PRs. One is about requiring replay protection, and one is about, clarifying how, how, handling epoch closure works. I'm gonna go into these in a little bit of detail here. So, the story of three seventeen, is replay protection is currently optional in DTLS. We see these proposals to make it mandatory, especially for post handshake messages. This would make analyzing the situation quite a bit simpler for post handshake. And reasoning about it. We discussed this in Montreal. There are two sets of concerns. One's from SCTP, from Michael Tuchsin, and one's that performance from Paul Wooters. The SCTP case is now OBE. A Hannes went and talked to Michael, and they came to conclusion that the situation's FCCP has changed some, and, we no longer have to worry about this. So it's fine to require it. I'm I recall, Paul was saying these were at performance. I'm quite skeptical. This is actually a big deal. Quick requires reprojection essentially as a practical matter, and I haven't heard anybody complain this is a performance problem for quick. So, I would like to revisit this. I think I just like to require replay protection. So I think now is the time to object to that if you don't like it, or say you do like it. And and in any case, like the the the chairs to, you know, kinda close this help us close this out for us, we'll talk about it again. I see David's in the queue. And Martin?
[00:49:28] David Benjamin: David Benjamin, this sounds good to me. I'm actually a little confused, though, why it is specifically important for post handshake messages because those already have a sequence number. So even if you manage to replay the fragment, we will immediately notice that either it's that, like, you know, it's not in sequence.
[00:49:43] Eric Rescorla: Maybe I have just lost the plot. I wrote these slides quite late. I wrote these slides quite late, and and when I first wrote them, I thought it was important, but I could be wrong. So but let's well, just remove that poll if you want.
[00:50:00] Martin Thomson: Martin Thompson, the replay protection that we have in QUIC has never appeared in our performance profiles at all, as in it has never been a problem, it is super cheap to implement. Please require it. Especially for post handshake, I mean, David's point is fine, but I will observe that you might as well just have it and avoid all of the problems that come from not knowing.
[00:50:32] Hannes Tschofenig: Hi, this is Hannes. Paul and I did the performance analysis on IPsec regarding the sequence number issues. And there is a performance benefit if in a data center based communication when you have multiple concurrent ongoing communications, and that's, for example, what Google also does with some of their protocols in the data center. They turn off repair protection for that purpose. So there is something there, but we hadn't done yet what we wanted to do for the hackathon, But then we, like everything takes always longer than expected. We will do a performance analysis also of this part and then provide you a definite answer on what the story there is. But at least now the case looks weaker than it did before because of the SCTP story that we initially were very much focused on. So that's why the current proposal is to require replay protection. On this post hand check authentication, I think that was a little bit of a clarification understanding issue there. Because previously, when we said application traffic and it there's an optional replay protection, You have to sort of apply this to 1.3, but the application traffic, as traffic secrets are also applied to the to the handshake messages, to the post handshake messages. So it gave people the impression that now those messages are also optionally repro protected, which of course is not true. So there's a little bit of a confusion in the wording there, but if we go with the current proposal, this is all a non issue.
[00:52:14] Sean Turner: Is there anyone that does not wanna require this? Is there anyone opposed? And if so, would they like to get to the microphone to say why?
[00:52:24] Eric Rescorla: Okay. I'm not hearing anybody, so I'm gonna merge this PR, pronto. Next slide. Okay. I'm doing the next slide. That's me. Well, I'm trying to do the next slide. Okay. This this is really laggy. So there are four more slides, I promise. K. Four.
[00:52:48] Sean Turner: There we go.
[00:52:50] Eric Rescorla: Did it change? I can't see anything. I still see I still see reproduction on my on my on my my screen. Is that not what it says to anybody else? Can somebody tell me what they see?
[00:53:00] Sean Turner: So it's PR326 on the screen now.
[00:53:03] Eric Rescorla: Okay. Meet. Echo people. Can somebody make Meet. Echo work properly? Let me just pull up my own copy of the slides so I can see what's happening here. Because I see I see reproduction on my slides.
[00:53:15] David Benjamin: Let's do this. Share
[00:53:20] Sean Turner: screen.
[00:53:20] Eric Rescorla: I'm I'm good. I'm good. I've got it. I can see I I just pulled up my own slides. Okay. So, David Benjamin pointed out in his extensive review, when when to close the epoch, it's kind of unclear in details, 1.3. This PR has quite a bit more detail. And in particular, it says when it's safe to close the epoch and then when you must close the epoch. I've gone I went over this last night, and modulo the the fact that apparently my IQ was somewhat lower than what was hoping on the previous slide. It seemed basically okay to me. But I think it needs more review, so I'd like to see, you know, if if get some people to stand up and say they're gonna read this and then send comments, that would be really helpful. So, I I don't think now in the room, but, like, you know, David Ben Martin Thompson on a wine, I'm looking at you. So, I know Anna's actually been reading it. So so my ask would be if people could review this in the next, you know, month or so, that'd be really super helpful. And I guess I I hope to get their names in the nest. If you would, like, sort of raise their heads, there you go.
[00:54:20] Sean Turner: Yeah. So, basically, we're asking for review. The audio here is horrible, so I'm just double
[00:54:25] Eric Rescorla: checking. I'm sorry. I'm trying.
[00:54:27] Sean Turner: Yeah. No. No. It's not I don't think it's you. So, yeah, we have this PR, and we have a bunch of comments that go back and forth between the two of you and Hannes. So I think basically, get in there and kinda think what you say what you guys think.
[00:54:39] Victor Dukhovni: Right.
[00:54:41] Eric Rescorla: Okay. Can I have the next slide, or should I bring them back on myself? There really is only one more slide. Actually, I could just talk to it. That's fine too. Okay. Six is what I want. Right. So David had raised a, as I said, David raised her a set of issues about, actually, that puck transition. This is an overall this is actually the only last remaining issue. It was sort of rate he raised a whole bunch of points. As I said, Hana said a really good job of going through and trying to trying to, turn them into PRs. I plan to go through this to make sure that we didn't miss anything. I'd appreciate it if, David would as well. But after this, we're actually quite done or. So, this is both a call this is this is a a a pre last call for any other issues you'd like raised because once I get through these, I'm planning to ask for a cross call. So, this is just a heads up for people.
[00:55:37] Sean Turner: Alright.
[00:55:40] Eric Rescorla: Plea please moderate me off the
[00:55:41] Sean Turner: screen. Oh,
[00:55:45] Eric Rescorla: Hannes. Alright.
[00:55:49] Hannes Tschofenig: Yeah. I just want to say, like, we had this issue where we collected implementations, and there are more implementations now than, obviously, back then when when we did the published the the first iteration. So there's also an implementation in progress. Even people in here implemented this version and, for example, your own for Mbed TLS. And so I've created an interoperability sort of matrix as some other groups did as well to just check between those implementations. So will make that shiny as some of you did as well for the hackathons. If you are aware of some other implementations, please add that to the issue. The other other part is the formal analysis. I have a student, different person with the extended key update, to look into the formal analysis of the DTLS-one 0.3, which is, at least from a on some of the transport mechanism, a little different than the DLS protocol, as you're all aware of. And I've started myself taking some of that work that we did for the extended key update, which was SPIN/Promela, and apply that to the base handshake that we are doing here just to double check that we, this time, get all the corner cases and the synchronization issues covered. So yes, so that will be finished hopefully in time as we are wrapping up these PRs and issues that we have with the document.
[00:57:38] Sean Turner: So our friend Chris Wood has this tlsworkinggroup.org mailing list, and they list the implementations for TLS 1.3. Okay. I'm pretty sure that if you were to submit a pull request to add the details implementations there, that would be awesome.
[00:57:51] Eric Rescorla: Okay. Yeah.
[00:57:53] Sean Turner: Right. Yeah. So that'd be great.
[00:57:55] Eric Rescorla: Thank thank you very much, Hannes, and thank you for taking taking point on this. This was super super helpful. Have the PRs to review.
[00:58:01] Sean Turner: Yeah. Well, yeah, while everyone was arguing about something else, my inbox was filling up with the DTLS related pull requests and comments. So good stuff. Alright. Thank you very much. Three minutes back of our time. Alright. I'll stop. Stop sharing. I do not remember who's next.
[00:58:19] Deirdre Connolly: Is authenticated ECH.
[00:58:23] Sean Turner: Alright. So Alessandro. You got it? Alright. Cool. And then we'll give the clicker the power. Yeah. There's the clicker. Alright. Cool. It should work.
[00:58:39] Alessandro Ghedini: Hello. I'm Alessandro. I'm gonna present the signed ECH updates on behalf of my co authors, Nick and Dennis. We've presented this a couple times already, but just to give a quick recap. When a TLS server rejects an ECH attempt from a client, for example, because the client is using an outdated ECH config, the server can provide a fresh configuration to the client so that the the it can retry connecting immediately. In the current ECH RFC, the the updated ECH config is authenticated through the outer TLS handshake. So the server will present a TLS certificate covering the public name that it previously published in its ECH config in DNS so that the client can know can validate where the the new ECH configs come from. The the downside of this is that the the requirement for a TLS certificate sort of limits how the the TLS server operator can choose and manage its public names. So every time it wants to to rotate the public name, needs to register a new domain, get the TLS certificate. And the other downside is that, basically, all of the TLS servers that can terminate ECH for a particular public name need to have access to the the private key for the TLS certificates. So that's basically what we're trying to to address with this draft, which defines a new authentication mechanism for ECH configs based on RPKs where a server publishes list of trusted keys in its ECH config in DNS using this new ECH config extension. And during the the TLS handshake when rejecting an ECH attempt, the server can provide new ECH config signed by one of these keys so that the the client can verify the signature for that rather than requiring a valid TLS certificate from from the server. So, of course, this decouples the the the retry mechanism of ECH from TLS certificates. So it allows the server to more freely choose how to to to deal with the public name. It can choose to not have a public name. It can choose to, I don't know, rotate the public name for every client, but it's not limited by the the TLS certificate requirement anymore. And it also allows server operator to sort of sign ECH configs offline and then distribute them to TLS servers so the the actual servers don't need to have access to the signing key anymore. But, of course, the downside of this is there is a potential for replay of signed DCH configs that the the the drafts the draft tries to to address by defining a sort of expiration time out that the server sends to the client.
[01:02:15] Eric Rescorla: Stop.
[01:02:16] Victor Dukhovni: Yep.
[01:02:17] Eric Rescorla: Oh, do you stop, I guess, actually? Don't go forward. So I sent email at this last night. This you're you're skipping over this a little quickly, this replay thing. There are two kinds of replays. One kind of replay is is is that a signed config that has a key in it, and that is a relatively modest risk as long as the key hasn't been compromised. The other is a is a is replay of a disablement signed config. And that is a very serious situation because, basically, it allows the attacker to simply turn off ECH for the entire period of the, of the validity window. So I guess that may in fact be the right trade off, but I think it really needs to be, like, more clear to people that's the consequence of this design.
[01:03:01] Alessandro Ghedini: Yeah. I guess, I mean, we can think about if there's, like, ways to improve the mechanism a bit more, but we can certainly clarify and and be more, I don't know, verbose in the draft to explain this risk more.
[01:03:15] Eric Rescorla: I mean, mean, I guess I guess I wonder if I wonder if we should in fact permit sign disable configs.
[01:03:25] Alessandro Ghedini: I mean, we don't have to, but I guess we can discuss this further. I guess Dennis might have a comment.
[01:03:33] Dennis Jackson: Dennis Jackson, Yeah. So I think the message on the mailing list was, like, accurate echo that you sort of saying that there's there's risks around having a affordable signed disabled signal. You can we could bind it into the connection at the cost of then having to have the signing key be resident in the the tls server. So it is it is a discussion point. You can do the the design either way.
[01:04:00] Eric Rescorla: Yeah. So so I think I think we should I think I think if we choose to adopt this, we should keep this as an open issue because I think it's a it's a I think I think it's a pretty concerning property that we'd like to be very very conscious of.
[01:04:09] Sean Turner: Yeah.
[01:04:10] Dennis Jackson: Yeah. But the rest of the draft works the same pretty much.
[01:04:12] Eric Rescorla: I agree. Just I agree.
[01:04:19] Alessandro Ghedini: So since the last time this was presented, there's been a few big updates. First of all, we've simplified the draft significantly. There's only one authentication mechanism now, which is the the RPKs RPK based one I just described. And there is this new flag to to for the server to explicitly signal disabling ECH, which I guess we might need to to discuss further. And there there's been some updates throughout the the ECH config extensions are defined to make sort of improved backwards compatibility as well as clarify how they're supposed to be used. And then in terms of implementations, we have this sort of interrupt harness on GitHub as well as two work in progress implementations, one based on boring SSL and one based on NSS, but they're not quite ready for interrupt yet. So there seem to be some interest in the past about this work. So I guess the question now is whether the working group is interested in this. And if this draft is a good starting point for this work, whether, you know, we should adopt this. I guess, comments, thoughts, discuss.
[01:05:50] Sean Turner: Yeah. Let's do a show of hands tool first off. Let's do with who's read this draft? Who has There's someone who read this draft. Okay. Alicia.
[01:06:05] Alica: Alethia, I have a question about clock drift. Because, like, if we have a situation where the keys are valid only for twenty four hours, I think that may be a problem for a non insignificant amount of clients. Like, in my experience, I think we can expect that, like, at least 1% of TLS clients will have time that is over, an hour off from reality. So explicitly addressing it in the draft, I think, is very very important.
[01:06:41] Alessandro Ghedini: Yeah. I guess we have the the sort of the the guidance to have, you know, twenty four hours or whatever. But I guess at the end of the day, it's up to whoever is deploying.
[01:06:57] Alica: Yes. But that's why I'm saying that the draft should say that this is a common problem, and you basically need to have a situation where using key from twenty four hours ago will still work.
[01:07:12] Alessandro Ghedini: Yeah. So and part of the flexibility here is also you can have overlapping keys. But I guess we can maybe try to be more explicit in the draft.
[01:07:28] Sean Turner: Alright. I'll do this. Start. Alright. Show us hands tool. Off we go. Get to vote your conscience. Alright. So 10 people
[01:07:57] Presenter: ish. Alright. Cool.
[01:08:00] Sean Turner: I just kinda we're not, again, taking this to list. We're just trying to see well, 12. Alright. Cool. So now we're actually gonna do it because enough people have read it that if we get a couple, then we can go from there. And obviously this part we will confirm on the list. Give it another couple minutes. We're a little early, so it's okay if we take thirty more seconds. Wow. That's an interesting number of people. Alright. Fifteen more seconds. Alright. Kinda neck and neck here. Alright. I'm gonna stop it. There were 12 yeses and nine noes. Does anybody wanna get to the microphone that said no and say why? You don't have to. Okay. Alright. We are gonna take this to the list, because, basically, it look like we got enough people that would be willing to contribute. So go from there. Alright. Thank you very much. Thanks for giving back us back some time. Next. Search. Whimsy search. Oh, you got it. I'll I'll stop pressing buttons. You got it? No. You didn't. You got it. Give the clicker the power. I did that. There you go. Alright. You got ten minutes
[01:09:42] Deirdre Connolly: for this one. Do you want
[01:09:44] Sean Turner: me to, like, put all your two the two amount of time together so you can manage both because you're one after the other? You want the full thirty minutes? Don't care. I think I think Ten's fine. Okay. Alright.
[01:09:53] Yaroslav Rosomakho: Hello, everyone. I'm Yaroslav, and on behalf of Jonathan and myself presenting workload identifier scope hint draft. Wait. There we go. K. The basic idea is mutually mTLS or TLS with both client and server authentication is great, have really nice security properties, resolves many issues, many attacks that other authentication mechanisms are architecturally vulnerable to. But there are some deployability limitations of MTLS, especially on the client side. So it works for bots, for workloads, for certain proxies, OTs, IOTs. It really doesn't work well with web browsers for various reasons. There are also deployability limitations, of course, on server side, such as load balancers and other things can can have can pose a challenge for MTLS. And as of today, if you are in an environment where you want to do MTLS, for example, you're providing a publicly facing API and you want to offer MTLS as one of methods how clients could authenticate themselves, you effectively have to create a separate endpoint. You have to have a separate SNI so that based on SNI, you would know if you provide certificate request or not. Because if you provide certificate request to people who do not expect that, they might freak out and go away, behave in some unexpected challenge in unexpected ways. TLS specification allows clients to provide just empty certificate message in response to a switch request that they don't like. But, some clients in practice, especially web browsers, can get confused about what certificate request is and would things break if we do empty certificate message. Now taking kind of step aside, this is really applicable to workloads. We have a number of applications of that in WIMSE working group. We have m t l s as one of three mainstream authentication mechanisms there, And WIMSE is now we are getting closer to working group last call of a workload identifier draft. Hopefully, in few weeks, we will start a working group last call on that. Long story short, it's simply an URI. URI that consists of three parts. There is scheme that tells what the URI is. There is one mainstream scheme that exists today, which is SPIFI. Authority trust domains. Authority portion identifies trust domains trust domain that provides that correlates to set of issuers that issued that workload identifier and associated credentials. Work trust domain doesn't have anything to do with DNS. It's DNS like. It's a host name like, but it doesn't have to be resolvable. It could be completely private local thing. And then there is scheme and deployment specific path. It could be something opaque like UUID, or it could be something very, very granular telling where and what workload is. So the first three components, scheme and authority trust domain, they form what we call in the draft a workload identifier origin. So that is you know what kind of workload identifier can workload present. So the proposal is to introduce TLS client hello extension that could contain a list of workload identifier scopes. It could be empty. So if you if you are not using Wimsie workload identifiers or if you have some kind of privacy considerations, you're not ready to express what kind of workload and the first you you you have, but you promise that you will not freak out when server produces you a certificate request. You can just do an empty list, or you could include one or more workload identifier scopes. So server can use that hint in various implementation specific ways. Again, it can look at it and say, oh, it's present, so I'll give you a certificate request, and we'll see what happens after that. Or it could say, didn't really like any of our workload identifier scopes that you've presented, so I'll just drop the connection because I don't want to talk to you. Or, yeah, I'll be but I don't like those, so I will not give you a certificate request. We will use some kind of application specific mechanism for authentication. So that is presence of this extension doesn't require server to produce certificate request. It it's again a hint. It could be so why including workload identifier scopes? So one of the challenges that we're facing, especially when it comes to communication between workloads between trust domains, is you don't necessarily know upfront which workload identifier to present. You could be provisioned with multiple, which is not uncommon, especially in various multi tenant or federated environments. So you have an agentic AI, let's let's stay trendy. So workload that is agentic AI, it is communicating with some form of external API. It could have two, for example, workload identifiers, and it doesn't know which one to give to the server. And in TLS, it can only give one. So if it shares with the server those two are trust domains and schemes that I belong to, server could produce a ticket request accordingly or not produce a ticket request at all. And the server itself is likely to have a very long list of trust domains and CAs that it could potentially trust. It it could it it it it is likely serving many, many, many different customers, so it's not feasible for the server to include all of those in certificate request to be disclose completely customer list, for example, or just have extraordinary large client request. So what if workload and if our scopes are very sensitive? Client Hello is sent in clear text. What if my workloads require privacy? Well, you can always send an empty list, and you can combine it with ECH. So one of the patterns that I think is perfectly viable is sent an empty empty list in outer client hello, and in the inner client hello include a concrete list of workload identifier scopes that you're hinting that you you can you have certificates for. So that's the proposal. Presented it a few times already. Is there any questions, suggestions, any appetite for an adoption call
[01:16:56] Eric Rescorla: maybe? Victor?
[01:17:00] Victor Dukhovni: Just wanted to note an overlap in part with a document that's nearing completion in the dance working group, which is DANE specific signaling of an essentially identical nature where the client can signal a domain which publishes its Dane TLSA records and solicits a server request for a client certificate. The client solicitation can be empty, likewise, like mentioned here, and then the server is merely prompted to prompt for client certificate without any particular context. It's obviously not about your workload identifiers, and the client can only send one. But I'm just wondering whether a conversation with Shuman about maybe consolidating these to one extension makes sense, or maybe it doesn't. Maybe it's good to have two similar but slightly differently purposed extensions.
[01:17:51] Yaroslav Rosomakho: Indeed, it would be interesting to explore potential synergy with DANS. I have not seen any deployments of DANS yet, particularly with SPIFI space. If you're aware of some, that would be very interesting to explore. But right now, again, in in SPIFI or whimsy space, DANC is virtually unknown.
[01:18:16] Victor Dukhovni: Yeah. The DANC is still, you know, early document stage. I've heard that maybe Microsoft is interested in the DANC for email, and then I might even be tempted to implement in postfix. I don't know of specific interest outside of email. Schumann may know other spaces. You should probably talk to, Schumann about whether he knows about other deployments. But in any case, the the spec is out there, and it specifies a very similar looking extension. You know, encourage the server to ask for a client cert, give it some context is basically what it boils down to.
[01:18:55] Sean Turner: Schumann is there? Yeah. Okay. Alright. Schumann. Right. That's worth giving a call, but let's we do have a little bit of a we have a little extra time, a little slap extra time. So go ahead, Akar.
[01:19:07] Eric Rescorla: Yeah. I mean, I guess, I don't really care about dance very much, but I wanna generalize this question, which is this is the second at least the second, draft I've seen in TLS for suggesting that you can do, MTLS. There's also the MTLS flags draft. Does this supersede that draft, or are these, are these somehow, both live concepts?
[01:19:28] Sean Turner: Does this does this supersede the m l MTLS flags extension draft, which we were talking about? Like, you're gonna have Jonathan's draft?
[01:19:36] Yaroslav Rosomakho: I think that's Jonathan says yes, Jonathan.
[01:19:40] Sean Turner: So the other one will go away.
[01:19:41] Eric Rescorla: Okay.
[01:19:42] Sean Turner: It was never part of the working group,
[01:19:43] Eric Rescorla: but Agreed.
[01:19:44] Sean Turner: I think it's gracefully expired.
[01:19:46] Eric Rescorla: Yeah. I mean, I I guess I I do there I just wanna take Victor's point, which is that, like, it probably isn't amazing to have multiple extensions that all say that all say I'd be willing to, like, do some kind of, you know, client certificate, especially if it's not clear what the joint semantics of those are because, like, you can't accept them both simultaneously. So I think it probably if if we wanna move forward with this, I think probably rather than hauling it Wednesday, this should be, like, a accept client certificate, thing or generic client certificate thing with a a list of things you're able to offer and clear semantics about how that won't pick one, rather than rather than, something like the the way it's currently structured. So I think this probably needs some I think I think probably if we're gonna do this, it needs some rework. I'm not sure if we need to do it, but I think if we do do it, it kinda needs some, like, a higher level generality rather than just offering eight different extensions that have kind of some more some more semantics.
[01:20:42] Sean Turner: Okay. So what I think we're gonna do is start off with a oh, so there's more people in the queue. Should look up. Daniel.
[01:20:50] Daniel Migault: So Daniel, amigo. I like I like that presentation, and I think it can I mean, a 3GPP can leverage from that, so I'd like to make sure
[01:21:00] Yaroslav Rosomakho: Thank you?
[01:21:00] Daniel Migault: It get aligned.
[01:21:05] Kyle: Kyle, could I wish it wasn't necessary to have some method of, you know, requesting a client's or offering a client certificate, but I think it is. I kind of echo the concerns that, we should have some kind of general mechanism. I am worried about, the offering of additional information as opposed to just offering to respond to a client certificate, you know, defined manner. And I'm not sure the ECH is a real practical mechanism to protect the the data in there because if you can do ECH and you already have some information about the server that would be helpful. Thanks.
[01:21:54] Sean Turner: Kyle? Oh, sorry. Nir just got sat down. Shumon is oh, look. He's even he's not even just here this week. He's here in the room.
[01:22:06] Shumon Huque: So can you hear me? Yeah. Sorry. I was sitting in the back. So I just wanted to comment on, Victor's comment. There are some dance implementations in the IoT space, specifically AFNIC, the French registry, has done some implementations for LoRaWAN. So that's the other one. I'm aware of other communities that are interested, but have don't have any implementations yet. And on the question of whether there's an opportunity to merge the extensions, I don't have any strong opinion yet. I have to go back. I have to read your draft
[01:22:39] Sean Turner: first. Thank
[01:22:43] Hannes Tschofenig: you. Sean, did did I hear you say that you want to ditch the flex draft?
[01:22:48] Sean Turner: I I think their premise is the MTLS flags draft, not the flags extensions thing, but just the flags extension draft is going to gracefully retire. That's true. The flags Okay. Draft. Yeah. Yeah. Yeah. Alright. So just for giggles, I think we heard there's gonna be some collaboration, but let's just for giggles, who's actually read this draft?
[01:23:10] Yaroslav Rosomakho: It's a short one.
[01:23:11] Hannes Tschofenig: It's a short one.
[01:23:12] Yaroslav Rosomakho: You can read it while the poll is running. Very short.
[01:23:14] Sean Turner: It's very short. Okay. So we're getting there. So I think I think with that many people, we can there's enough people to be able to make an informed decision after you and Shimon talk a little bit, and then maybe we can swing before we get back to San Francisco. We can see what we're gonna do. Alright? Okey dokey. Thank you very much. We will now switch over to the next one.
[01:23:39] Presenter: One? The supplemental authentications.
[01:23:47] Sean Turner: Yep. Yeah. Yeah. It's like ding ding ding ding. Supplemental Authentication. Cool. Alright. And we're even vaguely on time now. I'll give give you a couple of minutes extra.
[01:24:01] Yaroslav Rosomakho: Alright. Okay. And now for something completely different. Hello again. So on behalf of group of authors, I would like to present an idea of supplemental authentication in TLS one two three. This was born after many, many discussions around PQ ideas. It kind of somewhat somewhat evolution of some of ideas were discussed previously, but the key use case that we are trying to address here is completely different. So there are situations where you where you want to pass multiple identities associated with TLS client and server. And one of those use cases is particularly dear to my heart, something that I had to deal with for pretty much the whole duration of my career that is associated with VPNs and ZTNA. So very common scenario in enterprise VPNs and ZTNA where you need to pass both user and device certificate as a part of your handshake. So with the user certificate, you authenticate the user. You say, I'm I'm Yaroslav. I'm employee of a certain company, so please let me in. And the device certificate says, I am corporate device. I'm Yaroslav's laptop, so please let me in because I'm the correct device. There are all sorts of interesting policy decisions that VPNs can do around device and the user in terms of authentication, authorization, posture control, and so on and so forth. One other data point that might be useful is when it comes to managed enterprise managed devices that are managed with UEMs, MDMs, other things that do all sorts of enforcements and controls, restrict certain things, The way how they signal to the software that runs on the device that the device is managed, that the device is compliant is a certificate. So they produce a certain certificate in the device trust store that other software can pick up as an evidence that it is indeed managed device. It's a super common pattern in enterprise space. And one thing that makes me very sad is pretty much all well, frankly, all VPN clients that I'm aware of implement this really badly because there is no good easy protocol way for them to implement. So they might be passing user certificate as a part of m tls, but where what what to do with device or how to pass that? Very common, approach is just to send the certificate as a as a as an inbound message without any kind of proof that you actually have private key of the certificate. Kind of laughable for most people in this room, I hope, but it's it's actually quite common. Slightly better technique is sending a nonce. So server can send a nonce and client would sign that nonce. It's a little bit better, but obviously also subject to relay attacks, for example, timing attacks and things like that. So it would be really nice to have an ability on the TLS layer for those, again, non browser VPN clients to pass multiple identities associated with a user and device. Secondary use case, there are certain situations where you have multiple identities associated with TLS server. Again, workloads. So when you are doing mutual authenticated TLS between client and server in Wimsey space, you typically have two different certificates on the server side. You have the good old host name certificate, which you many clients expect you to present, and it's typically WebPKI valid certificate. And you also have this Wimsey specific certificate thing with its identifier. Obviously, no WebPKI is going to sign that. So it is a separate certificate, and you have to make a very unpleasant deployment decision which one do you want to use and make sure all the parties that you communicate with agree with your decision. So it would be really beneficial to have a deployment option of passing both. There are potential use cases with a multiple host name. So be, for example, proxy communicating with the CDN could be one of the ways how proxy would be asking, hey, I know that you're serving multiple host names, so why don't you give me multiple certificates? And then we would be able to use the same, let's say, HTTP/2 or HTTP/3 channel for multiple origins. But again, from my perspective, it's it's secondary.
[01:28:40] Sean Turner: Before you go on, Jonathan, you're in the queue. Did you mean to be in the queue? Oh, yeah. Okay. Sorry. Sorry. Sorry. Jonathan Hoyland for Tejas. What
[01:28:56] Jonathan Hoyland: how is this different from exported authenticators?
[01:29:00] Yaroslav Rosomakho: We'll come to that in a bit. Okay. So those are the motivating use cases. Yes. There are other ways how those use cases could be addressed on application layer on others, but I'll come to to TLS, and maybe that will clarify your question.
[01:29:16] Jonathan Hoyland: Export of authenticators is TLS layer. It's bound
[01:29:19] Yaroslav Rosomakho: to the Again, we'll we'll we'll I'll I'll cover that in few slides.
[01:29:24] Sean Turner: Okay. Cool.
[01:29:26] Yaroslav Rosomakho: Is there a burning question?
[01:29:27] Daniel Migault: Alicia, do you wanna?
[01:29:32] Alica: Well, Alicia, from your red hat. I have a question if why not post handshake authentication? Just do it twice.
[01:29:41] Yaroslav Rosomakho: Sorry. Why not?
[01:29:42] Alica: Why not post handshake authentication?
[01:29:44] Yaroslav Rosomakho: Again, something that I will cover in just a moment.
[01:29:47] Sean Turner: Again, apologies for only uploading the slides, like, an hour ago.
[01:29:50] Yaroslav Rosomakho: Sorry. Okay. And then there are use cases with PQT and maybe potentially even PQPQ where you have certificates for the same identity, but different digit different signature schemes. But chairs told me that they do not want to talk today about it. This is Friday conversation, so we're not going to talk about it. Okay. So without going too deep into the details, how that's supposed to work and what are the key differences between that post hand check authentication, exported authenticators, why proponents of this solution believe that this is this is a good option. So you have a client. Client is sending client hello as usual, and we're proposing a new extension, a supplemental certificate requests. It's just a regular extension. Client hello doesn't really modify anything, and it indicates that client supports multiple certificates from the server side. So server could send multiple certificates if it chooses to. It also contains list of extensions that are associated with supplemental certificates. So, for example, could be additional server names or could be other extensions that normally apply in a certificate request message. Then the server sends its sends its regular server hello encrypted extension certificate message. And then if server would like to provide supplemental certificate, at least one, then on the certificate message, it sets a flag supplemental certificates that hints to the client that informs the client that there will be additional at least at least one additional certificate. We're not modifying TLS handshake. So that's sacred. That's well studied, analyzed. So we are only adding few extensions here that don't modify key schedule or anything. So the handshake the server part of the handshake completes with certificate verified and finished message. And then if server included a flag supplemental certificate in the certificate message, immediate well, right after finished message before any application data, server sends an additional certificate that corresponds to request in supplemental certificate request in the client hello. supplement it can include yet another supplemental certificate flag if it will produce more supplemental certificates. So it could be more than two. It could potentially be be be be more more than that. Certificate verified and finished message. Now those messages, additional messages that are in the green on this slide, they are treated as post handshake messages. That is they are encrypted with application secrets with server so so with regular server keys. And they for the certificate to verify and finish, they continue original transcript that's beginning with tls client hello and ends with servers finished message. Now one other key property here is those messages are sent before any application data or before any other post handshake messages. So that is if server included cert supplemental certificate flag in the certificate, then after finished, additional certificate must come, not any other message that would be a catastrophic mistake. So that's how it works from the client side from the server side. From the client side, it's very, very similar, except the supplemental certificate request extension is included in certificate request on the server. So that is client certificate client certificate authentication is mandatory for supplemental certificates to be provided. You cannot do supplemental certificates without main certificate. And then additional additional the flag and additional flags are exactly the same from the client side. Now key features of that proposed design. Why is it designed the way it is designed? It does not modify main TLS one dot three handshake, so we are adding extension in client hello or a certificate request. We're adding flag to certificate. We're not modifying TLS key schedule. It does not modify application protocols unlike exported authenticators, so you don't need to figure out a way how to how to have this additional connection with your TLS library, how to free how to include exported authenticators in the framing, how to do exported authenticator request from the server side so you would be able to get it from the client side. Export authenticators, sadly, don't allow unsolicited client certificates, so it resolves some of those limitations. All the messages, all the supplemental authentication messages are sent before any application data. Means that when application kicks in, it already has all the context. The authentication context doesn't change after application data started, which I believe is the main challenge for HTTP two and QUIC in terms of using post handshake authentication. So it said once you started doing some streams, there's been multiplex protocols, and all of a sudden you get an additional client certificate, that that is a challenge. So this is resolving this challenge. You complete all your messages before you get to application data. Can apply to both sites unlike tls one zero three post hand check authentication. Post hand check authentication is client only. This works both client and server side, and it also doesn't introduce an additional round trip types. So that these client messages are sent right after client finished, server messages sent right after service finished, so we're not introducing any any kind of round round trips here unnecessarily. And, yeah, hopefully, it is applicable to not just VPN clients wishing to provide more than one client certificate, but to broader range of use cases where you may want, for different reasons, to provide multiple certificates for from client or from servers. Again, those use cases that co authors have in mind have nothing to do with web browsers. We know that web browsers UI verics were very complex, and APIs that drive those UIs are very complex. So those, again, use cases for workloads, VPN clients, and other things that don't touch browser UIs. So we have already quite a queue.
[01:36:49] Sean Turner: You do. You haven't seen the chat log. It's getting pretty long. So I guess yes. Sorry. I don't so let's start this. We got about ten minutes left, and we got about 10 people in the queue. So be synced in your comments. Thank you.
[01:37:06] Usama Yasir: Sama, if you go back one slide, please. So you're you're basically talking about the post handshake authentication, and I would like to understand why exactly the RFC nine two six one, RFC nine two six six, like the solutions that we have
[01:37:21] Yaroslav Rosomakho: Can you speak closer to the mic? It's very hard to understand.
[01:37:23] Usama Yasir: Okay. So RFC nine two six one, RFC nine RFC nine two six six, both of them provide the solutions which are possible for multiple server certificates. And the reason I understand you are saying that the application needs to change, you could have a shim layer in between the application and the TLS protocol. So I don't understand really why that kind of solution would be insufficient for this and why we need to change the TLS protocol itself.
[01:37:47] Yaroslav Rosomakho: So, again, this solution doesn't change TLS handshake. It's introducing essentially a shim layer that hopefully will be driven by TLS libraries, and it does not introduce any unlike exported authenticators. It doesn't require modifications to application protocols.
[01:38:06] Sean Turner: Okay.
[01:38:10] Jonathan Hoyland: Hi. Jonathan Holden for Tejas. So, I mean, I was looking in the chat and Mike was saying that the reason you can't use explicit authenticators is that it might not happen at the beginning of the flow. So could you, you know, just as a as an understanding mechanism, as a straw man, could you have a pause extension that just sets a single bit saying, when the connection starts, wait until you've got some more certificates. Because I I really like, this is changing the handshake design such that you're gonna need a bunch of formal analysis, and exported authenticators already has that, is already an RFC, is already so just like saying, oh, we can just add a TLS flag that says pause, and you've simulated this with exported authenticators.
[01:39:05] Yaroslav Rosomakho: So you're saying that from the and I'm not expert on formal analysis. So do I understand it correctly that you're you're saying if we replace those additional flags with exported authenticator sent on without before application layer, that would make formalizes people more happy?
[01:39:21] Jonathan Hoyland: Well, as in someone's already done the formal analysis, you know, feel free to go read chapter four of my thesis. So, like, yeah, this would require formal analysis for sure. So going with something that already has it seems much more sensible to me.
[01:39:37] Yaroslav Rosomakho: Okay. Thank you.
[01:39:39] Jonathan Hoyland: And already in
[01:39:39] Yaroslav Rosomakho: our Yeah. I I I don't have I don't have a response, but, yeah, let's let's let's check offline.
[01:39:45] Sean Turner: Andre?
[01:39:46] Presenter: Andre Popov of Microsoft. So I think if you are saying that these messages must follow the handshake messages, that kinda makes them part of the handshake to to an extent. You cannot send any application data until you are done with this thing. So it becomes part of the handshake. So that argument is invalid to me. With regard to the mechanism, I agree that, you know, exported authenticators solve the same problem. I also think that if we had to, we could generalize post and shake off for for the server side as well. It's not not that difficult to do. Like, if we if we can make Thank you.
[01:40:18] Yaroslav Rosomakho: Again, the key point is that it doesn't modify TLS key schedule. Would you agree with that? Okay. So not everyone agrees clearly.
[01:40:28] Kyle: Just a clarified question on the goals. Do you have a goal to be able to use the same connection simultaneously with different identities for different parts of the connection.
[01:40:40] Yaroslav Rosomakho: So the goal here is not then somehow somehow demultiplex this and associate different streams with different identities. The goal here is carry multiple, again, identity informations like user and device. You're not really separating and saying that these requests within that connection is associated with user and that one with the device.
[01:41:06] Alica: Alica, so first of all, the server side of it, it scares me. This is something that you absolutely should not do. Like, if you need multiple identities, just put them into a single certificate, deploy that to the server, and use that, and make the user application verify that it has both of those identities. Like, deploying that stuff on the server is, like, that's what you should be able to do as an enterprise because, like, you are talking about enterprise use cases, so you need to be able to do that. For the client side, okay, yes, you need to have two two separate identities. You have the hardware identity. You have the user identity. So, yes, I understand, like, having need for two certificates there. But, again, the I don't I'm not buying the argument that this is not changing the the handshake because, like, it is part of the handshake. We are thinking of it as part of the handshake. You cannot send the application data until you are finished with this. This is handshake. You can for with post handshake authentication, like, this is the protocol, you can say that the server will not accept any data from the client until it receives the post handshake authentication. So this is a policy decision that the application, can do and the server can enforce. Like, they need to talk the same protocol on the application layer. So they can enforce that and say that they will not do, that stuff until the the additional handshake is, post handshake authentication is finished. So I, again, do not see a reason to, mess with the core part of the identity, like, protocol verification, formal verification of TLS to do that. Thank you. Yes.
[01:43:07] Russ Housley: I just wonder how you envision to forward this extra information back to the application server. If you terminate it as a TLS proxy, like load balancer or stuff like that, how do you forward this information back to the application server?
[01:43:24] Yaroslav Rosomakho: Of course, it depends on the API between TLS library and application that would require an additional API or modification of existing API to pass not a single but multiple certificates that were received from another party.
[01:43:37] Russ Housley: Yeah. So that also sort of needs to be supported by a lot of back end infrastructure?
[01:43:45] Yaroslav Rosomakho: Of course. There is no way around it.
[01:43:48] Sean Turner: Alright. Victor?
[01:43:50] Victor Dukhovni: Just very quick. It should be clear, I hope, in the document whether any of this applies to raw public keys, which are after all a form of certificate, quote, unquote, in TLS. Could one mix the two, have raw public keys in one certificate and x five zero nine in the other? You know, these kind of issues should be spelled out. We thought of that.
[01:44:10] Yaroslav Rosomakho: If I understood the statement correctly, it's right now designed to run certificates only. So it doesn't look into other into into raw public keys.
[01:44:27] Victor Dukhovni: Maybe in theory, a device could have just a raw public key and be authenticated that way. I don't know whether that's a use case or not, but just think about it.
[01:44:36] Guilin Wang: Okay. Okay. Yeah. So here's Guilin Wang, yeah, from Huawei International Singapore. So I noticed that you proposed a number of use cases. It's good. Yeah. Inspired me. But also, I noticed probably there is another application scenario, something like alternative for post the control of migration. Not not just to you. Yeah. Of course, use a composite signature, composite certificate is good. Yeah. But also possible, yeah, for your scheme. Yeah. Supplementary authentication just for yeah. Post the content migration. Like, okay. I would like it to authenticate myself, but use double certificate. Yeah. So I see this is also possible use case. Okay. Yeah. And then by the way, actually, we also have a similar draft in IPsec working group. It is called the multi authentication. It's gonna be the same. By the way, do the negotiation how many different way you authenticate to yourself. Right. It could be traditional signature. Yeah.
[01:45:44] Yaroslav Rosomakho: Yeah. Indeed in IPOSEC, you can you can send multiple authenticators.
[01:45:48] Guilin Wang: Yes. I would like to read the draft later. Yeah. Thanks.
[01:45:52] Dennis Jackson: Alright. Dennis? Dennis Jackson, Mozilla. I really, really don't like this for post quantum stuff. I'd like I don't think this is a good direction to go in. I understand that there's like a you know, there is a key use case here that people want to see addressed, but I think this is really, like, the wrong mechanism and the wrong layer at which to do it. And I think maybe the TLS working group should take on something in this area to provide a more compelling answer, which I think would probably be based around exported authenticators. And that could address both this use case and things like the post quantum peak situation, where people want to do a lot of additional round trips to provide additional authentication to a key. And this could be done post handshake based on an exported authenticator without needing to come back to TLS each time.
[01:46:44] Alica: Thank you.
[01:46:45] Sean Turner: Alright. Hannes, go. You've got like
[01:46:47] Hannes Tschofenig: Too fast.
[01:46:48] Felix Linker: Two minutes. Okay.
[01:46:49] Hannes Tschofenig: There are two things, and I think this lines up nicely because Dennis said, there's a use case question. Do you have that use case too? And I don't know. I think that's the bifurcation I would really like to see. The other one is the solution direction. And and this is obviously a straw man, so I heard a number of different ideas there. I'm not sure the exported authenticator was really done at the right layer. In my opinion, it's not. The application layer was not the right choice for this. And we see this actually also playing out right now because the HTTP people don't use it either. So it's not that, oh, it's it works for the browser fantastically. That's why we should use the environment. It actually fails there to wrong layer, in my opinion.
[01:47:42] Yaroslav Rosomakho: Thank you.
[01:47:43] Sean Turner: Okay. So I think your job is to talk with the people that has set got up the microphones that they hate it and figure out if there's someone we can get it so they're not hating it. Alright. Your own. You're up.
[01:48:01] Yaron Sheffer: I'll leave the slides to you. Yep.
[01:48:03] Deirdre Connolly: Yep. There are
[01:48:03] Yaron Sheffer: v03.
[01:48:04] Sean Turner: Give them the clicker.
[01:48:06] Jonathan Hoyland: So Oh, we can just
[01:48:07] Sean Turner: do it. It's the did not make slides. Next one. Yeah. Yep. You get the rest of the time.
[01:48:13] Yaron Sheffer: Yep. Good morning. I'm Johan Schafer, joint work with Thiru here. To recap what PQC continuity is about, This is for the migration period from classic certificates to whatever we end up doing for post quantum. For a long time, will have mixed policies. So, we will have clients that are willing to work with either one with servers that present classic certificates as well as post quantum ready servers. And this creates an opportunity for rollback attacks. One possible solution for this problem is the one we're presenting here, which is based on client side caching for a particular server. Server commits to present post quantum certificates. Again, dual composite whatever you have for some duration, say for the next year, client cashes this commitment and rejects a server that doesn't do what it has committed to. This is essentially trust on first use in with and in that sense, this is a mitigation. This is not a complete fix for the problem. Next slide.
[01:50:14] Chairperson: Could I actually just ask a quick clarifying question on the use case here?
[01:50:20] Yaron Sheffer: Yes. Please go ahead.
[01:50:22] Chairperson: Yeah. Yeah. If you could flip to the previous slide. It seems like this attack presumes that while the transition is still going on, an adversary will not only have a cryptographically relevant quantum computer, but will have it online and executing fast enough to, be part of an active attack. Does that sound right?
[01:50:52] Yaron Sheffer: So, no. I can, in the privacy of my own home, create a certificate. So once I'm able to offline break ECDSA, I can create a certificate pretend to be whatever and so this does not need to be online. Okay,
[01:51:21] Eric Rescorla: thank you.
[01:51:23] Yaron Sheffer: Next slide. What happened since v01 is we implemented a proof of concept in OpenSSL. And we came up with quite a few learnings that went into v02. Foremost is we tried or we we thought we had a design to do it symmetric symmetrically for clients as well. We decided that although in principle this could be done, it's it would complicate the protocol and would not be worth it from various say use case perspectives. So we dropped that and and the the protocol now is only for server commitment. We defined the cache indexing. This is all based on a cache so it's really important to define the semantics of the cache and the cache key of the cache index is an RFC and 9,525 identity, the port number and whether this is TLS or DTLS. Previous version of the draft had the algorithm, we're not doing that anymore. So you commit to a period of time in which you would present any kind of post quantum certificate and you can switch between certificates and switch between algorithms as you wish. And of course, this is expected if the algorithms are not mature yet. And lastly, and quite important, it's not only about the identity certificate, it's about the entire chain. So, there's no value if you present a post quantum identity certificate while the rest of your chain is classic and therefore can can be toyed with. One important open issue remaining is the v01 that Larry made on the list and that's the LAMPS work Merkel tree certificates. We believe this can be addressed but we haven't fully formalized it and it would involve basically extending the notion of PQCNESS to not just a particular certificate chain, but also to the alternative that's that's being done by by the LAMPS working group. That's it from me. Any questions?
[01:54:57] Sean Turner: Alright. Before we get there, let's do a show of hands tool for who has read this draft. Got about five minutes left in the session. Alright. Well, it's actually not a bad number. And we got six people in the queue already. So exciting. Alright. Seven. Okay. So we got, like, 14 or so that have read it. So that's a pretty good number. Alright. Becker.
[01:55:26] Eric Rescorla: Hi. So I I asked this question on the list, but I wanna repeat it for the room. When we discussed this in IETF 119, the the resolution was this is gonna be discussed in a list and see whether see whether there's actually any real interest in deploying this. That seems not to have happened. So, who's interested in deploying this?
[01:55:42] Sean Turner: So the question was, you know, at IATf-119, when we talked about this, that kind of takeaway was to try to gauge the list to see who would be interested in deploying this, and that didn't happen. So has anything changed since then? Do we know of anyone that's interested in deploying this?
[01:55:57] Yaron Sheffer: So I'm not aware of any implementations other than our own POC.
[01:56:03] Eric Rescorla: That seems to answer the question of whether we should do this work quite handily.
[01:56:09] Yaron Sheffer: My personal opinion is, like, from an industry point of view, this is just early.
[01:56:16] Sean Turner: Okay. David Benjamin? Deb, are you getting up to interrupts?
[01:56:21] Lars Eggert: No. Okay. I'm just
[01:56:26] David Benjamin: David Benjamin. So I think some flavor of this makes some sense in that like you are right that there is this downgrade protection problem. And I think some like, this is basically some variant of HSTS. And I think we'll probably need some something like this to start with, although it's gonna quick I have a whole presentation later in SAG about how HSTS will fall over. Oh, sorry. There's more to talk about about how HSTS will fall over. But I think one issue is that for this particular design of the thing, TLS is a little bit too, like, too low level to do this. So for example, you mentioned the cache key. But that cache key is not going to work for anything that looks like http because in http although scheme and host is scheme host part is largely our origin, we have some state like cookies that actually span origins. And so anything like this for h t p is gonna want probably an include subdomains bit, which brings in this whole new can of worms. And then we also probably want to partition the state a little bit further because if you have state, you've got correlation between contexts. And so now we have to worry about like whether this context and this context can correlate each other. And I suspect this is true not just of like http land, but that in general, once you have state and you're worrying about what is the size of the context in your app, that's an application layer question. And so I think this probably wants to be lifted up a bit, which unfortunately does mean we have to do it separately for http and email and whatever else. But it also means that we can take their needs into account. Also, kind of gives an easy answer for the Merkle Tree thing because I mean, there's not going to be classical Merkle Tree like chains in the first chase. So that's easy. But the answer for is the PQ chain, is this in your PQ land? Is does your application believe it is in the PQ bucket or the not PQ bucket? And I certainly hope the application knows which bucket is which.
[01:58:23] Yaron Sheffer: So I would love to see an HSTS based proposal so we can have a more concrete discussion. I suspect that HSTS comes with its own bag of problems. It's essentially a layer violation where the hs where the HTTP level needs to be aware of stuff happening underneath it. Not ideally either. So
[01:58:50] David Benjamin: Right. I guess my comment is that this gives a different layering violation and so I think from from the perspective of someone who does work on an http client, I think we are much much more likely to get an http based one to work because then the information then like, you know, the the context is known and we just need to get like one little bit down one layer where as opposed to this one where the sort of general thing doesn't fit our ship.
[01:59:17] Dennis Jackson: Dennis? Dennis from Mozilla? Yeah. I I sort of agree with a lot of David's concerns that this is probably the wrong layer to do this at, and I would generally, like, favor a HTTP level mechanism for, you know, the vast majority of applications. That said, if you're in a world without that and you need something like this, something like this draft doesn't seem, you know, completely insane.
[01:59:39] Yaron Sheffer: Is it just me? I can barely hear you.
[01:59:41] Sean Turner: I think he agreed with I I'm I'm it's hard to hear up here, so I think he basically agreed with David. Yeah. Okay.
[01:59:48] Yaroslav Rosomakho: Thanks. Sama?
[01:59:50] Usama Yasir: Sama, so I submitted my feedback already a couple of times, and the last one was on the June 9. And I haven't seen that addressed yet in the slides, which was to say that what is so special in the post quantum thing. So all of these things are being anchored in the post quantum, and I don't really see why this is so specific to the post quantum itself as compared to the other things that the TLS working group has done in the past. Like, we have been transitioning from different things in the past, and why is it why is, like, post quantum so specific in this specific case? And that remains a question to me yet.
[02:00:28] Yaron Sheffer: The reason why post quantum is so so the last time we did this kind of migration was from no TLS to TLS and that's HSTS. When we migrated from 1.2 to 1.3, there was never a question of, I can break 1.2, so I can break whatever you have. And now we have this problem again in the migration to post quantum.
[02:01:05] Guilin Wang: Okay. Yeah. Good. Hauwke International. So I just have a little detailed question. Yeah. Technical thing. So what that means? So you get that you would like to store some information called the PQC commitment from server, right, to to indicate the server actually support PQC algorithm or PQC certificate. So I'm just wondering how you'll store such information. Just one bit information or some field of in the certificate or some other data structure.
[02:01:39] Yaron Sheffer: So you're asking what is the indication that this to which the server is committing? It's base so with today's draft, and this is before Merkle three certs, this is basically the signature algorithm coming from a specific list of post quantum signatures.
[02:02:04] Alica: Okay. Thank you.
[02:02:05] Sean Turner: Alright. Thank you very much. We'll meet again Friday. I will upload the slides at lunch, which is gonna do all the p q plus t signature stuff. We're gonna have some framing slides. We're gonna have some hums in there, some questions for hums. Feel free to go ahead and read them. So we'll be ready for Friday. Thanks. My stomach is on fire. Okay.
[02:02:33] Lars Eggert: So that's fine.
Session Date/Time: 24 Jul 2026 14:00
[00:00:07] Chairperson: Alright. Welcome to the final session of IETF one twenty six. We are thrilled that you came here to close out your IETf week here at the Tls working group meeting. Okay. So what do we have? We have NoteWell. I'm sure you've seen this probably, I don't know, fifteen, sixteen times this week, but it is important. So please take a look. Anything you might have missed, you know, you can read it now. I do wanna emphasize that in any of our communication channels, we wanna be professional and treat each other well. It includes chat, email, and at the mic. Everybody should log in to your on-site tool if you're on-site. If you're on not on-site, then you'll be on the full Meetecho client. Okay. Thursday agenda is in the past. And so oh, what what one thing, if somebody would take some notes, just kind of action items and maybe critical decisions, if somebody could write those down. If not, we'll okay. Thank you. Thank you, Mike. Alright. And so today, we have some discussion of PAKE from Chris, and then we'll talk about signatures, and we have a couple other topics after that. Is there any agenda additions, subtractions, modifications? Alright. Then Chris Wood, you are up.
[00:02:16] Sean Turner: There is the last one.
[00:02:18] Rich Salz: Last one?
[00:02:18] John Gray: Of course. Alright. Alright.
[00:02:27] Chris Wood: Hey, folks. Just gonna give you a quick update on the PAKE extension draft as well as the sort of analysis that we did on the side. K. For those of you who perhaps don't remember or forgot, whatever, PAKE is a very simple extension that we added recently to the be able to support and negotiate a PAKE inbound within the handshake alongside the normal TLS key exchange as an a way to authenticate client server throughout the course of a connection. The way it works is fairly simple. Client and its client hello basically offers up a PAKE identity pair, client server, as well as potential potentially one or more PAKE messages, as we call them, which are specific to the PAKE algorithm. The server will select an algorithm based on its supported set of protocols as well as make sure the identities check out and it actually has a client corresponding to the the identity that the the client requests. Supply a response back to the client in its flight. The server or the client will then finalize the pay protocol, drive a shared secret, and jam that into the key schedule alongside the existing Diffie Hellman or ephemeral key exchange that the TLS handshake does. And that's really it. Pretty straightforward, I would say. Yeah. Pig is combined with the TLS shared secret. In some prior version of this draft, we had a PAKE authentication sort of not compatible with certificate based authentication, but that was needlessly rigid. So now it supports the ability to authenticate with a certificate alongside the PIC if you so choose to do so, But PSK is explicitly not allowed alongside PAKE because that's just weird. Another interesting feature for some deployments, not all, is the ability for servers to optionally simulate a response in the event that a client record is not present or can't be found for a bit offered client identity. And this is done so, you know, attackers can't enumerate the list of valid clients that are registered with a particular server, which, again, is not applicable to all use cases and all deployments, only some. Okay. As an extension, there's a couple of interesting limitations. The first of which we heard very loud and clearly that if you have a PAKE with multiple rounds, definitely can't easily jam that into the existing shape of TLS, and we don't intend to do so. Another interesting property is that augmented pakes typically have, like, a key confirmation step in the flow where the client, like, proves possession, basically, the password that the server doesn't have. Sorry. In an augmented PAKE setting, the client and server have different views of what the password is. Client has the password. Server has a verifier of the password. Client needs to prove that it actually knows the correct password, and this is typically done through key confirmation. But there's no slot in the existing t l s one three handshake where you could, like, add a PAKE specific key confirmation message. The the the the instantiations of pakes that are in the document basically drop the PAKE generated key confirmation message and rely on the TLS finished message as a confirmation instead. And that's a little weird, but seems intuitively to to to check out. You know, asterisk formal analysis for that particular piece has not yet been done, but you can reason about it fairly clean, I would argue. Okay. So we there's some use case yeah. Sorry. Ecker, go ahead.
[00:06:06] Eric Rescorla: Yeah. Could you just go back?
[00:06:08] Victor Dukhovni: Yep. Yep.
[00:06:10] Eric Rescorla: So what I thought I heard you say was that the TLS finished message is priority key confirmation. Is that correct?
[00:06:20] Chris Wood: Yes.
[00:06:21] Eric Rescorla: Yes. So just concretely, if I I would imagine that the record layer completely broken, nevertheless, you would still have confidence in the out possession key of the you would still have you would still have confirmation from the finished message. Right?
[00:06:35] Scott Fluhrer: Yes. Yes.
[00:06:36] Eric Rescorla: Okay. Thanks.
[00:06:39] Chris Wood: Okay. So for reasons, some of us, we still really care about this hybrid pay stuff. So in order to accommodate that, the draft introduces sort of I'll call it guidance, more or less, because it's not actually protocol mechanics, but guidance for integrating PAKEs that are negotiated externally to the TLS handshake. So you don't have to do them inside the handshake. They happen externally, much like you would have an external PSK derived by some, you know, generation distribution mechanism that's then jammed into TLS, and that's exactly what it is. So you have a PAKE that could be one round, two rounds, 10 rounds, whatever, runs out of band, generates a pre share key, and then we rely on the existing PSK importer draft to and import that PSK to authenticate client server. And then TLS just runs as per normal. Details up to, you know, for example, how the the the importing step actually works, like what you use for the context, how you encode the identities, and whatever. I think it took, like, a reasonable approach with this in the current version of the draft. Of course, they can subject to change after we look at it, but hopefully, this is not too, like, surprising or controversial or whatever. Like, imagine you have external PSKs, and now we have just external PAKEs, and that's sort of the that's the thinking. There are other designs as well where you can imagine not doing the PAKE before the TLS handshake, but doing it after the TLS handshake and then binding it to the TLS handshake. It's probably also fine as well. But this just seemed like a very, like, natural and intuitive way to do it. It does have certain caveats that come with it. For example, if, like, you're in your particular application where you do this, you you you need to it's like a server, for example, you need to run, like, you know, potentially one port for receiving these PAKE connections and another port for the TLS connection or have some other way of distinguishing and disambiguating these two types of handshakes. But that's, like, a not insurmountable challenge, especially for applications like peer to peer scenarios where you're, having two devices drive these things out of band and you have complete control over, like, what the networking looks like. So it's not too big of a task. Okay. So I think the biggest thing aside from that sort of guidance is we've put together some analysis for this. Unsurprisingly, we took or perhaps unsurprisingly, we took the existing provera based analysis that was done for ECH, and we basically forked it to add in support for this extension. We aim to prove or demonstrate that these properties like mutual authentication, key secrecy, for secrecy, etcetera, and and lack of regressions are all satisfied. And I can say that, like, with the limitations of the analysis, which are not zero that we have achieved, I think we have I think we've demonstrated this. So some of the limitations are, for example, that, like, you know, these symbolic analysis tools don't have good support for modeling, like, low entropy secrets. They just kind of assume that either a secret is known or not known by the attacker. In our particular case, we just assume, like, all passwords are, like, high entropy, normal secrets. That means it doesn't account for things like dictionary attacks that would actually be realistic and, you know, something you have to consider in And kinda just as the the way this is constructed sort of assumes that the PAKE is a functionally correct black box that has been analyzed elsewhere. So if you slot in, like, SPAKE2+ or CPASE or whatever, the goal is to sort of establish that that working correct black box, when jammed into TLS as the extension specifies, achieves the desired security goals. Beyond that limitation, you know, we didn't model all of the different interactions between, you different know, features like certificate based authentication, ECH, all that stuff. All stuff we could do, of course, we just didn't do it yet. And then there's some details about how we modeled asymmetric or augmented pics, in particular, like how the information that the client has is different from what the server has. And we took some liberties in simplifying this in the analysis. So, anyways, regarding moving forward, I think there's a number of things that are that could be done. For example, we should do these feature combinations. I think the key confirmation dropping change that we made specifically for the augmented pakes is something we should confirm is correct by a computation analysis. I don't think symbolic analysis is the correct tool for this. But, you know, assuming that happens, then I think the draft will be in a pretty good place. And I would I would argue that at this point, it's ready for fat assessment. So, like, ask the chairs to shoot this over to the fat and then see what they have to say with regards to the analysis that we produce as well as what could be done, and then someone could do that work. Scott.
[00:11:31] Jonas: I mean, just to jump
[00:11:33] Sean Turner: in there while you're getting to the microphone, I got your message, and I'm working on a message to send over to the fat people to get them started.
[00:11:38] Chris Wood: Thank you.
[00:11:45] Scott Fluhrer: Scott Fluhrer of Cisco Systems. About the augmented pegs, at least opaque works very differently than what you have modeled. I think it might actually be a decent fit into TLS. However, it is so different. This this framework doesn't work for it.
[00:12:02] Chris Wood: Can you say more? Because I'm pretty
[00:12:03] Eric Rescorla: sure that's
[00:12:03] Scott Fluhrer: Because they don't actually come up with same key that you just go to both side. What it actually downloads is essentially if the if the client's password is what he registered with, he gets basically his private public key pair.
[00:12:22] Chris Wood: Yep. That that's right. I should probably know that given the names of the RFC,
[00:12:26] Scott Fluhrer: but Yeah. Now I think that is not I was I think that's completely out of scope of this work and should be taken, if it's necessary, taken up by some other draft. Say sorry.
[00:12:37] Chris Wood: Say it by say that one more time.
[00:12:38] Scott Fluhrer: K. I in my opinion, that is sufficiently different that it should not be part of this work, but but if needed we feel it's needed, be be a completely independent work.
[00:12:48] Chris Wood: Yeah. I mean, the we currently have no opaque integration in the draft. If people wanna do that, then certainly they can do that and do the corresponding work to demonstrate that it's it's correct. Thanks for pointing that out. Oops. Okay. Any other questions, concerns?
[00:13:11] Scott Fluhrer: Victor?
[00:13:13] Victor Dukhovni: Does anything special happen on resumption after initially negotiating with a PAKE? Any concerns?
[00:13:20] Chris Wood: Do you mean for internal or external? Presumably internal.
[00:13:28] Victor Dukhovni: I negotiate a fresh session with a PAKE. I obtain a resumption ticket. I resume. Any problem with that? Should I not offer resumption tickets or any concerns about security implications of starting with a PAKE?
[00:13:43] Chris Wood: None that would be different from, like, resuming with an external PSK or something like that, I don't think.
[00:13:48] Victor Dukhovni: Okay. Because with external PSKs, we have this business of, you know, whether post handshake authentication is okay or not okay, and it has to do with whether PSKK happened. There are all kinds of little complications in theory that could happen if you resume after an external PSK. Here, we still do a Diffie Hellman, right, even though there's a PAKE, but the the key agreement still happens normally?
[00:14:15] Dennis Jackson: That's correct.
[00:14:17] Victor Dukhovni: Okay. So probably none of that is a problem. Okay.
[00:14:22] Chris Wood: I mean, the key exchange mechanism the the primary key exchange mechanism can be negotiated orthogonally to the the PAKE itself.
[00:14:28] Jonas: So you could have a
[00:14:30] Chris Wood: case where the main TL Sandshak does not use Diffie Hellman and the PAKE key exchange is is effectively a Diffie Hellman or or injecting, like, a fresh secret into the key schedule. But that's an orthogonal thing.
[00:14:43] Victor Dukhovni: To negotiate a group from the supported groups with these space.
[00:14:48] Chris Wood: Sorry. What can you repeat that?
[00:14:50] Victor Dukhovni: We don't always negotiate a supported group and do that part as well.
[00:14:58] Chris Wood: Sorry. So we're talking exactly what you're talking. One more time.
[00:15:03] Victor Dukhovni: The regular key agreement that we get in a certificate workflow, you're saying doesn't always happen with a pay.
[00:15:09] Chris Wood: Yes. I think it yes.
[00:15:11] Jonathan Hoyland: Okay.
[00:15:19] Sean Turner: Okay. Alright then.
[00:15:21] Victor Dukhovni: Application paper may be in scope here and may need to be understood as to how it applied.
[00:15:32] Mohit Sahni: Right. So so much you addressed in. From your perspective, do you think it's is there something left over that you want to do further, or is there something that you need help in, or do you think that's should be fat not assessment, fat artifacts that you have currently? Do you think there is something left or something that you need help in specifically, or do you think that's over?
[00:15:58] Chris Wood: The the things on your side.
[00:16:00] Mohit Sahni: Oh, okay. So you need an an computational analysis you need help in. Okay. That I can't. Okay. And what do you mean by feature combinations? Can you give an example of what exactly you are thinking about?
[00:16:11] Chris Wood: Like, making sure there are no regressions on running the PAKE with certificate based authentication with x PSKs or not PSKs support, rather, with ECH support, etcetera, etcetera.
[00:16:19] Eric Rescorla: Okay.
[00:16:20] Chris Wood: I'm just saying these are things that have left to be done.
[00:16:23] Rich Salz: Okay. Thanks.
[00:16:28] John Gray: Alright.
[00:16:29] Chairperson: Okay. Thanks, Chris.
[00:16:48] Sean Turner: Hello. This is either a bottle of water or a bottle of your favorite colorless liquor. Alright. So here, we're gonna do a little framing here for, the p q plus t signatures for TLS. I guess you probably could set a timer for fifty five minutes. We got a lot we got a lot to go on. So I'm gonna do a little intro, then we're gonna have the the the document authors do a little bit, and then we'll do a bunch of hums. I put these slides up yesterday. I shared them with the authors. I guess the preamble here is these authors are actually talking to each other. This is not an adversarial situation. Some of them are actually on both drafts, and so we're just trying to figure out which way to go. So from there alright. So the purpose, Ecker had this idea, like, let's up level this whole conversation. Let's just try to figure out what which way to go and try to frame it and then figure out which one to do or which ones to do. So the idea I'm gonna ask I'm actually gonna ask the silly question later whether we wanna do this work at all. But assuming the answer is yes, then we have to figure out what it is that we're gonna do. Alright. So the first thing is this is not about picking an algorithm and or a curve. Just that's not the point. This is an approach, and we're gonna go forward, and we can have that discussion later. Remember that. I'm gonna squelch that thread. Alright? So one more thing. Still a reminder, it's still not about algorithms. Alright? So the plan basically here is to have author presentations for both. They're both this one's up there and so are the two other presentations and go from there now. Couple of months ago, we actually had a a side meeting with a bunch of people, and there were even more options. But drafts didn't come forward, and what it comes down to is this is contributor driven organization. So when you got a draft, you put it forward, we talk about it. So this is what we got, and so this is what we're gonna talk about. Then we're gonna do a show of hands, which is a little bit more like a show your, do your own adventure because I write the questions, then you nitpick them. So my hope is that you actually had a chance and you don't think it's horrible. And I'm gonna go actually go through the questions really quickly, and then we'll do this the presentation so you'll have them in your head while you're watching these presentations go. Again, the general idea is, like, you know, none, you know, only one, one or the other, both, and then maybe in what order. So we'll jump to the authors' presentations in a second. The first one, it's still another reminder. We're still not talking about algorithms. Show of hands. So the first one is, you know, this is it's kinda giving you a hint if you forget, like, what we're talking about here. So this is like, do you wanna get it done, or are we just rage quitting and leaving? Right? So it's do you wanna work on this at all? And the next one is if we're gonna do if we're gonna do the work, you know, should we only do one? Now implicit in that is if you wanna do more than one, you vote no or not vote. Sorry. Express your opinion in the show of hands tool. So if you if you say yes, then we're gonna try to pick out which one. And if it's no, then we're gonna we're gonna jump into questions that figure out which order to do them in or if you wanna do them both at once. So then if we say if you say yes, I would only wanna do one, then we pick which one. If you'd say you wanna do more, then we have to figure out doing both at the same time in one order and then the other order. Now the other thing to remember if we do them both at once, some of the complaints for Feathertimes is we have to hold one of them till the other one gets done. So think of that also whether you think they all need to be done at once because one might get done a whole lot quicker than the other because one involves picking lots of things. So we'll see. Alright. So, Joe, I think we can jump to the the the dual certs one. Okay. And the for the presenters, if the if you people that are remote speaking, if you stand forward a little bit, it's a little better, but it is better than
[00:20:28] Rifaat Shekh-Yusef: Okay. Thank you all. Okay. We're gonna talk about dual certificates. Let's get going. So why hybrid? Jurisdictions or corporations are asking for this. So it's not a choice anymore. Like, it's a requirements that coming from different governments and different organizations. So that this proposal, in this case, we're talking about dual certificate. It's not a replacement for composite. We think both have merit and have value and has use cases that could could benefit from from these ideas. So we wanna be clear that, obviously, that TLS has many use cases, and, their PTI is different. And, obviously, the web is a major part of that story, but it's not the only story. So the goal of this draft is address use cases that are specifically enterprise or IoT use cases. So this is, an example of a use case, that could benefit from from TLS. In this in in in this example, I work for a company, Sienna. It's an optical system, company that connects data centers, where you you take all that route routing data, multiplex it, and then encrypt that data and ship it into the other, the other side, and then you decrypt that data. So we have, a TLS channel that is established, a mutual TLS channel that established between those two entities. And then you mint keys from those, from that TLS channel and then use that, ship it to that hardware dedicated hardware to encrypt all that data. So remember that in this case, it's, an enterprise use case where the corporation is in control of both sides, and they can set whatever policies they want on both sides. K? So let's look at the implication of a hybrid composite and compare it to a hybrid, dual. So in hybrid composites, the bigger picture is that you need a traditional PKI, and you need a p k a composite PKI and a PQC PKI in the future. Right? And in this case, in this case, you get one certificate per one of those PKIs. Now if if you also start mix and match between, for example, a CA that is PQC and, you you issue a certificate, a position certificate, this this can be become even more complicated than this. K? Versus dual, in this case, you have, one traditional, one PQC. In in the case, you need a hybrid. You just provide two certificates that must be, authenticated at the TLS level. So that's the the difference and the impact of the PKI. So and and we talking about here about specifically about PKI with clear separation. We're not talking about mixing and matching PKIs. You don't use a PQCA to issue a traditional set of kits. And, typically, we you you keep them separate in this case. Okay.
[00:24:19] Scott Fluhrer: Thanks,
[00:24:20] Hannes Tschofenig: So now I'm going to talk about algorithms. Just kidding. Some of you have seen the document, of course, discussed on the mailing list, so there was a lot of feedback. We incorporated that feedback. And so if you haven't been following any of this discussion, I very briefly walk you through the current, the latest status of the document to with the purpose of showing you, like, what does that literally mean, what Rifa just said, if you have two separate PTI hierarchies and then use the two certificates and then link them together at the or bind them together at the DLS layer because we are, to a certain extent, also talking about, like, who is going to bear the costs. That's unfortunately part of that whole game. I start with the certificate payload. And if you look at it and compare that with the DLS specification, you will realize this time we are not making any changes to that payload. The the values that the entries that go into that certificate message contain both of the chains, so the traditional and also the PQC version. And they to separate them to separate the two, we put a sort of a separator in there, which is an empty certificate entry. Somehow, you need to you you don't want to sort of combine them randomly. That would be confusing. Certificate verifies. You obviously need to demonstrate possession of the private key, and that's what the certificate verify message does. And feedback from earlier presentation was like, oh, don't touch that thing. And we initially did. We constructed a completely new message, and that wasn't well received. So we went back and followed a different approach, namely one where we define combinations of algorithms. So here you see two examples from the document. And depending on the choice of the algorithm, the signature field is the concatenation of the two. You will see that on the next slide. It's a little bit conceptually similar to what is done in other documents with the chem. You may recall that approach. So how is the signature combined in this? So, obviously, we need to we now have two private keys. This is where the binding actually happens. In the first part, the signing input, it is it entire certificate message is covered, which includes, as you recall, the two chains. And then you need to combine you compute two signatures. The first one, obviously, with the traditional or the private key of the traditional algorithm and then with the post quantum crypto algorithm. And then you concatenate the two with a field in in front of it. That's that's the sort of the the whole magic, if you will. The benefits that we believe it provides is the simplicity in the sense of you have two separate PKI. You have one, your existing PKI infrastructure. And now you as you do your transition as an enterprise, Reiffat was showing a very simplified scenario. Of course, there are more than two parties. It would be bad if Sienna only has two customers. So you have, of course, this is a mesh with many parties. Each party has its own upgrade speed, and so you can gradually update these different systems. And that's what I also referred to the backwards compatibility. You need to start somewhere. And in case you have been to the SAG meeting, you've seen the excellent presentation from David Benjamin. He was laying out some of those aspects in transition. And so, as we all know, we don't know when quantum computers will really be here with us. And probably the companies won't tell us either exactly when for certain reasons. And so, this would be a very gradual deployment. Different software and different hardware and different customers will have very different ideas. So, it's a longer process, and we need to step by step enable things, test them in an enterprise to be finally there where we ultimately want to be. And some want to be in a pure PQC world, and others will take much longer to that path. And we don't say exactly, obviously, how this is or what the timeframe is in that sense. Good. And I think that's
[00:29:25] Sean Turner: Yeah. Yep. That's good. So I guess, clarifying questions at this point. So go ahead, David.
[00:29:35] Nick Sullivan: Well, that's right. I'm not
[00:29:37] David Benjamin: that tall. David Benjamin, just as a quick comment, the sag this does not help with the sag problem because this I mean, among other things, this would require TLS server update, and the sag problem was trying to solve something where the servers were not being updated. So unrelated.
[00:29:53] Hannes Tschofenig: Yeah. Yeah. Of course. So the differences in in your presentation where you obviously focus very much on the web and you have plans and all sorts of other infrastructure, you have different a larger much larger ecosystem. But I think the way you approached it was was quite good. And so I think that I think even a document describing sort of these different strategies for the different ecosystems would probably be useful, but that's beside the point. And you didn't talk about solutions. You didn't dig into the solution space either. So that's fine.
[00:30:31] Jonathan Hoyland: Jonathan Hoyland, Fatejius. I'm just looking at your two signatures, and you don't include the output of the first signature as part of the signing input of the second signature. Why? Or why not? I can't hear you. Yeah.
[00:31:06] Rifaat Shekh-Yusef: I think we we did consider that. Like, at the end, we are decided to concatenate those directly, but, like, you you could do that. Like, it is something that
[00:31:21] Tiru Reddy: Hey, Thanks for the question. So there are various approaches being discussed with regard to nested signatures, concatenating signatures. For instance, if you look at composite signatures, right, it basically concatenates both the signatures. But the property this one gives is weak non separability, which we were looking for. Right? And nested signature was not giving any better property because the important aspect was that when the signature is being generated for traditional, it includes the entire transcript including the PQ and entity certificate and the intermediate certs, and the same goes for the second signature as well. So if you look at the analysis that was done in PQ working group with regard to the concatenating of signatures or nested signatures which achieved the same properties? Thank you.
[00:32:10] Jonathan Hoyland: Okay. I'll have to go look that up because it's not obvious to me why that would be true.
[00:32:17] Hannes Tschofenig: Thank you. Yeah. Good input. It's probably like, I think, in terms of sort of the roadmap, I think we are probably still at a much earlier point in time before we sort of like fine tune and do a formal analysis on all of this, I think. But point taken.
[00:32:45] Andrei Popov: Microsoft. I have a question about the last slide where it says something about backwards compatibility. In what sense does this provide backwards compatibility when it requires a server update? Right? Like, it says the server is dealing with multiple chains, server is building a new type of signature, And the client obviously needs to be able to verify that signature and maybe even report those two search chains to the caller. Who knows?
[00:33:08] Sean Turner: Yeah. Right?
[00:33:09] Nick Sullivan: So how
[00:33:09] Hannes Tschofenig: Good good question. So the in the intended meaning of this was that we have a deployment that uses the traditional algorithms at this point in time. And we want to gradually move infrastructure over to PQC and to sort of like go step by step, sort of like you you update, let's say, a server or some part of the infrastructure. You add the software. You issue certificates now with the new PQC algorithms, and you try them out. And then you add more, and thereby you gradually move the existing installed base over till you then finally end to wherever you want to be. That's what I meant. It's obviously doesn't mean like some implementation that hasn't been updated, neither TLS nor algorithms nor crypto support can obviously support the new one. That would be magic. Alright. Okay. Thank you.
[00:34:13] Mohit Sahni: Somewhat you addressed, and I have the same question or somehow related to Jonathan's question. How are the two keys related to each other? Because they could come from, like, the if you go to certificate verify exactly. So is there is there a relationship between the two keys so that I know that exactly the same server is having these two keys rather than coming from some other one? Yep. One point. And the second point, I agree with Jonathan. It could be that first signature is now done. You could have taken for the second input that output which was generated by the first one as one binding relationship between the two. So it's not clear to me, and Tiru mentioned some I was taking notes. Sorry if I missed something. So has done some analysis, if I understood correctly. So maybe afterwards, you can send a link. That would be nice.
[00:35:02] Hannes Tschofenig: Yeah. So so as as was mentioning, so that the design rationale for this compared to what we had previously was specifically to include in since the certificate message now includes the two chains, it also includes, like, the fact that you have traditional algorithm and PQC algorithms in that transcript, because you compute a transcript over the whole exchange. So, thereby, in that sense, the two signatures are indirectly related because they're computed over these two transcripts.
[00:35:39] Eric Rescorla: Hi. I just wanted to observe that the the semantics of some of the extension some of the behaviors in here are a little odd. So for instance, like, your the signature algorithms, you're you're you're you're advertising these signature algorithms that have two hours in the algorithms in them, you know, easy DSA plus ML DSA, but those can't be used. Yes. Right. This is great. So, like, those can't be used to sign things sign certificates. They can only be used to sign certificate verify. And so it's like, oh, oh, it's a little bit confusing in term in this case, like, exactly what it is what it what the semantics are, are in terms of, like, what you're saying. I think it's probably workoutable, but, like, when you read it, we we like, you know, this is not the ordinary meetings as extensions, I guess, what we're trying to say.
[00:36:30] Chairperson: K. Victor?
[00:36:32] Victor Dukhovni: I think if if I look at this squarely, this looks like hybrids with CAs that don't do hybrids. Right? We're solving a problem in which you're essentially doing a hybrid signature scheme, but you're uncomfortable or unable to get a hybrid certificate, so instead you present two. It doesn't solve any of the downgrade or migration issues. Really, the main thing is we get the CAs out of the loop. It's a little bit easier to provision the two parts separately. Is that a fair assessment, or am I missing something?
[00:37:05] Hannes Tschofenig: Yep. If I understood it correctly, the downgrade downgrading aspects when it comes to, like, the two endpoints today? No. Like, are they using traditional or post quantum or whatever? Mhmm. That is a separate there's actually a separate document on this topic, which happened to be co authored by Tiro. It's it's a separable problem. Should those could be combined into one document? I don't know. But maybe you have an opinion on that one. Sure.
[00:37:39] Tiru Reddy: In this case, since there is an unique algorithm that's being negotiated, so if if an attacker basically tries to downgrade that to traditional, then it's all up to the policy. Right? I mean, if the client or server don't want to take anything beyond dual, they would reject the connection, but it won't be possible that unless the client or server decide to pick either traditional or dual, right, in that case, downgrade is not downgrade is still possible.
[00:38:07] Victor Dukhovni: Have a traditional certificate that they're able to attack. Right, then they'll present just that and appear to not support post quantum, and the client will be presumably happy. Right? So David's standard designs for that problem continue to apply here. This doesn't solve down rates in any sense.
[00:38:29] Tiru Reddy: Yeah. So David's problem is quite different that he's talking about a scenario where the clients and servers are managed by different entities. Here, this is an enterprise network where both the servers and clients are managed by the same entity. So this is this is about, like, hey, I decide to upgrade my server and I decide to upgrade my clients in few sites. I see how it works and then decide to migrate in other places. Right? So that's how it works, basically.
[00:38:58] Victor Dukhovni: Right. So the client then refuses traditional only. Right? The client turns off.
[00:39:03] Tiru Reddy: Yeah. In some places, stick to traditional. In other places, you stick. You start with dual and see how it works. And then if it works successfully, you start migrating in other places.
[00:39:15] Rich Salz: Okay.
[00:39:19] Sean Turner: We're gonna have more time.
[00:39:22] Bob Beck: I'll bet TLS client stack, all of them fun. You keep me alluding that you could, you know, upgrade one of your servers to do this and maybe a few of your clients. But if the server's gonna do this and your client doesn't understand this stuff, how are you gonna continue to serve your clients you haven't upgraded?
[00:39:45] Tiru Reddy: So what I meant was when you upgrade the servers, you will offer the clients both the traditional and dual certs, basically. So for unaided clients, you'll still work with using the traditional on both the sides. But for the upgraded clients, it will be dual.
[00:40:05] Eric Rescorla: Alright.
[00:40:06] Hannes Tschofenig: Well, the the not upgraded clients, they don't need to understand the format because they are not using it. It's obviously the server needs to support in for that transition period needs to be able to support both.
[00:40:21] Bob Beck: Yes. Yep. Right.
[00:40:30] Victor Dukhovni: Yep. Okay.
[00:40:31] Tiru Reddy: Yep. Thanks, Scott, for that. I mean, the client is the one which initially offers it. The client just says I'm only support traditional. The server is forced to just provide traditional certificate. Thanks.
[00:40:42] Chairperson: Okay. Let's move to the next one for time. Here's the clicker should be working for you, I think.
[00:40:52] Tiru Reddy: Hey. Thanks for further, and Hannes, for the initial understanding helping the working group understand the entire hybrid schemes, basically. Composite is another scheme. Right? The best part is composite has been worked for almost few years now in the lamps working group. It's already in the RFC editor queue. Yeah. Seven years. Composite signatures takes both the PQC and traditional signatures and public keys in atomic operation. So you are not supposed to look at them as two different objects or entities. It's supposed to be seen as one entity. And and and the algorithms that that have been defined in the LAMP's document clearly say, if verification succeeds only if both signatures verify, otherwise, the signature validation fails. Like my predecessors have just mentioned, composite signatures provides difference in-depth, provides resilience even if one of the algorithm fails. This is for regulatory reasons that you want defense in-depth for certain duration till you migrate to PQC signature algorithms. The composite signatures have been designed in a way that you don't need many changes or very minimalistic changes to TLS unlike dual certificates. It basically uses the existing TLS one dot three extensions. We do don't define any new handshake messages or extensions or any changes with regard to adding delimiters or anything like that. The so the signing input is signed using the negotiated composite MLDSA signature algorithm, and the peer verifies the signature using the same signature scheme. They're very similar to other algorithms. Composite MLDSA has an additional parameter which is the context string in which case we have used it as an empty one because TLS already has a protocol specific context string. So I think we got this question several time in the working group that, hey, would it add more complexity to TLS but composite MLDSA is treated as an opaque signature algorithm? TLS does not even have to select a hash algorithm for composite MLDSA. Hashing is internal to the composite MLDSA algorithm. We have added RSA, PKCS-fifteen combinations which because they existed in the LAMPS document, but they are allowed only in the signature algorithm cert only and not used in the certificate to verify. So how did we pick the algorithms? I'm not going gonna go into the algorithms that we picked, but the rationale that we used and we are open to further reduction. We basically picked an intersection of the composite algorithms that were defined in the LAMPS document and the traditional signature algorithms that are recommended in TLS one dot three. And that's a subset, basically, which excludes all the brain pool ones that are there in the apps document. Yeah. Further to add, composite keys, signature generation are all opaque at the t l s layer. No added complexity to TLS. TLS just handles the code points, calls the crypto engine. The crypto library takes care of generation of the signature and validation. It's just a shared library. Composite signatures are being used in various other working groups, IPSec, Josie, SSH. So it's gonna be used by various other security protocols as well. Right. So one of the security properties, I think it's quite important. And if you look at the PQ document, it talks about that as well. Composite gives you UFCMA. Right? Forging needs breaking both the components. So service is a break of one of the algorithms. So peer identity can be spoofed even if one of the algorithms breaks. So even if CRQC comes and you decide not to migrate, you're still protected because only part of the signature will be broken and still your composite MLDS signature validation would fail. It doesn't provide SUFCMA. It only it the SUFCMA only prevents a different valid signature on an already signed message, but that's not a problem for TLS or IPSec because if you have to impersonate a valid signature on a new TLS transcript, which is not possible because every TLS handshake transcript is unique. Yeah. So there there are several advantages. Right? One certificate, one chain on the wire instead of two certificates and two chains, and one certificate chain to validate that request minimal changes, and one chain to obtain, renew, and debug from a single CA. Right? And and the authors of both the documents had done a lot of analysis on the pros and cons of both the approaches. Right? And we had a document in the peak working group as well. And and if you have a look at it, right, I mean, both the approaches have several pros and cons. And what we figured out is it's all up to your deployment, right, depending on how you want to leverage these hybrid schemes. You have to weigh in the pros and cons and pick one of the approaches. We clearly could not find a winner among the two.
[00:46:10] Kyle Nekritz: Yeah. I think that's it.
[00:46:12] Chris Wood: Alright.
[00:46:12] Sean Turner: So clarifying questions. We had another twenty one minutes scheduled for this. I wanna reserve at least seven minutes of that for question time. But if it's a clarifying question, please get to the mic. Nicolas?
[00:46:44] Nicolas: University. I don't really have a question, but it was, like, corroborating all the advantages that were presented now, I can bring the experience that we have accumulated in the past year and a half of deploying both on server side and client side, both in a web scenario and in a mutual TLS with constrained devices, the use of, composite MLDSA signatures in TLS. And these like, I can only bring positive feedback on the fact that indeed it is by the fact of being opaque, it really simplifies the deployment and doesn't require really any other update other than the library supporting the the encodings that are now basically crystallized because it's at the end of the RFCQ and having TLS code points. So for our deployment, we use some retired code points that were assigned. And at this point, I think another advantage of this, if we had to pick one over the other, is that this is basically done. So this could be done very quickly. So I just wanted to bring this experience.
[00:48:02] Tiru Reddy: Thanks, Nicolas.
[00:48:05] Sean Turner: Alright. Go ahead. Sorry.
[00:48:07] Kyle Nekritz: Oh, I
[00:48:07] Nick Sullivan: was just
[00:48:07] John Gray: gonna say thanks, Nicolas, for the work that you're doing with that as well.
[00:48:11] Sean Turner: Alright. So we're gonna go back to open mic, and I guess we can keep asking questions. I definitely get the impression that the dual certs people should maybe wanna make sure they get up off the mic. But, yeah, you're I think you're good. Do we need any more discussion? I I do note Dennis' question in the chat, which is like, do we have enough for for information? So we're actually gonna add that to our list of questions that we're gonna ask beforehand. But is there any does anybody wanna say anything else?
[00:48:41] Dennis Jackson: That that was more just like we could have done it hypothetically differently, not that we should. I think this is a a good venue as any.
[00:48:47] Sean Turner: Okay. Alright. Becker?
[00:48:52] Eric Rescorla: Well, may maybe maybe I'm premature. Are you planning to have, like, an open mic here, or you're planning to just start getting hums?
[00:48:58] Sean Turner: No. I'm I'm it's at this point, this is more discussion. So I I wanted to reserve, like, seven minutes up to the time to do the hums, but, I mean, unless you think you could do it now. But, yeah, go ahead.
[00:49:06] Eric Rescorla: No. No. No. So I think the preparatory question, which we've which I haven't heard much discussion of, when do we need to do this at all? Right. Yeah. And and and I I'm and I think, you know, I know there are people who may think we don't have to or do have to, so I think I like to maybe make sure we have the table open for that. I sort of am like, for my my part, I'm sort of grudgingly willing to do something, though I prefer not to, and I think it's a pretty limited use case, because, at least in many environments I care about, you like, you know, if you do if we discover MLDS MLDS DSA is broken, we'll then update to turn it off anyway. So, so so I'm sort of, like, only gradually wanting to do this at all. So I think maybe people could speak to that a little bit for you anyhow.
[00:49:58] Participant: I came up to agree with, Dennis' point, I think. So hybrid authentication is inherently complex.
[00:50:07] Quynh Dang: The
[00:50:07] Participant: composites was was simpler in terms of handling artifacts,
[00:50:13] Quynh Dang: but I think we've got
[00:50:14] Participant: to be careful that that might not get rid of complexity. That might just move it to someone else. We need to think about that for the consequences of that for all PKI deployments. So yeah, I think I agree with Dennis' let's make sure we have discussion of what properties we're aiming for if we decide, and that's a big if, if we decide to go forward with this. Thanks.
[00:50:40] Dennis Jackson: Dennis, so just procedurally, where are we at? What are we discussing? I've lost, completely lost the thread.
[00:50:48] Sean Turner: I think we've waffled back and forth between one over the other, or should we do it at all? Right? I mean, I think that's where we've gone a little bit. And that is one of the questions that we were gonna ask. And we've added another one, which is like, do we have enough information at all?
[00:51:03] Dennis Jackson: Okay. So I think splitting trying to split it into two use cases. There's, like, transition and backwards compatibility in one box, and there's hedging in the other box. I don't think either of these approaches are valuable for transition. I accept that, like, the composites approach could be valuable for hedging. But personally, I'm not excited about it. I recognize that others might be. That's my 2¢. K.
[00:51:30] Chris Wood: Chris Wood. Yeah. Thanks, Dennis. There are use cases where people want this as a hedging improvement over existing classical deployments. Composites is a vastly simpler approach for those use cases. It gets us code points to you, for example, hybrid signatures with raw public keys. And there are real world deployments which use that that also want hybrid. So as to Eckers' question as to whether or we should do this, not really sure what that means. Like, fundamentally, there's a draft that has a specification, has an IANA table with some TBDs in it. I don't understand why we don't just, like, get cold points and move on and, like, end this discussion now because that would unlock those use cases that I'm referencing. We can have the discussion here, perhaps heated, about which of these two approaches is best, but I think it could be avoided if we could just acknowledge that there are use cases that for for hedging reasons, want hybrid composite and composite the composite approach is the the the simpler way to do it. But if we're going on that route, there's, like, 15 algorithms in that table. Please not 15.
[00:52:38] John Gray: Yeah. Hi. It's John Gray from nTrust. Actually, gonna speak more here than I was up there. So, yeah, we definitely need this. And I guess the reason for having a draft, the the only I mean, we need at least need code points, but the reason for having the draft in my mind is if we're gonna do that intersection of, you know, TLS recommendations like the RSA one dot five stuff and that, if we wanna have that intersection, then that's why we would need a draft because we'd wanna write that there as recommendations. If people don't care about them that, then sure. We can just have code points. But, at the end of the day, we we need to use these things, at least from our perspective. Thanks.
[00:53:18] Sean Turner: Andre?
[00:53:24] Andrei Popov: Andre, of Microsoft. So we do have use cases for hybrids. We would like to use hybrid authentication with TLS if it becomes possible. And the preferred approach would be composite because that encapsulates the ugliness of the crypto layer and doesn't change APIs for TLS. Less change for TLS. So at least if we could get the code points, that would be great.
[00:53:50] Sean Turner: Rich.
[00:54:01] Rich Salz: Hi, Rich Sauls. I'm having
[00:54:03] Sean Turner: a problem
[00:54:03] Rich Salz: understanding the motivation. I mean, I hear many comments where we need this, but the use case was just like the one that was showed was data center to data center trans transited over an optic link. Just carry TLS over TLS the way VPNs work. So I'm not really ready to decide one way or another if we should be doing this without seeing more concrete examples of how and what needs this addresses.
[00:54:38] Tiru Reddy: Come to
[00:54:38] Sean Turner: the mic or said it was jurisdictions that have that that require this. Jonathan?
[00:54:44] Jonathan Hoyland: Jonathan. Just as a what property are we trying to go for here? If we ignore all of the peculiar and it's just like I have two different certificates and I want to use both of them and they're both, I don't know, elliptic curve, whatever. Is the idea that they have to both be broken to complete the handshake, or is the idea that only the outer one needs to be broken? What the property here from here is very unclear. Like and it matters based on what we're trying to do.
[00:55:26] Sean Turner: Yeah. Chris, do you wanna jump in there and do the use case thing? Okay. Hannes, I think you're next. Is that right? No. Sorry, Jonathan. Yeah. David. Sorry. David Benjamin.
[00:55:41] David Benjamin: Interesting box here. Alright. Oh, whatever. So I'm assuming I've I've heard both hedging and transitions getting mentioned. I'm assuming this is about hedging because transitions is sort of unrelated. For hedging, I think the thing to look at is the cost of doing this hedge and the value we get. I think between these two, composites are dramatically lower cost. And so if we have to do one of them, I think composites is the way to go. I do think, however, that the the value of the hedge for signatures is much, much, much lower than the value of the hedge for, for example, KEMs because So let's The game here you're playing is you do a thing and then you roll out whatever you think you were trying to roll out and then, oops, m l d s a is broken. What do I do now? If you didn't do some kind of hedge, your recourse is you go revert back to the classical state, ship a software update, and move on because there's retroactive decryption of data to worry about. And the benefit of the hedge is that you don't have to do the software update. And so we're really only looking at The gap we're looking at is the relying parties that did not manage to pick up They're like particular instances that didn't pick up the update. But for any kind of PKI where the relying party vendor or the root programmer, whoever, is not operating the CA, so like sort of a public PKI as opposed to a private one where the same organization operates both, you already have a much higher probability failure to hedge against, is, oops, I picked the wrong humans to trust. That happens so much more often than our cryptography failing. And and for that, you have to do a software update anyway. And so the value for almost all PKIs, I would argue, is basically nil. The value of the hedge is really only in those few cases where you did not have something else pushing you to make the key updatable. And those do exist. And if people want code points, sure. But I expect this to be a fairly niche thing.
[00:57:53] Hannes Tschofenig: I want to comment on the use case aspect. So I I think if you are specifically in the room and work on web browsers, this is probably not your main area of interest. And we've run into that challenge before in this group. Everything that falls outside the browser space is immediately met with suspicion and sort of degrades in value very quickly. But there are other deployments that exist as well. And if you don't want if you think you can do the transitions differently, just ignore it and go and just do the other thing. So I think that's perfectly fine.
[00:58:37] Kyle Nekritz: There can also be value in this in cases where aside from an algorithm hedge, you are able to, you know, deploy keys that are protected differently. Like, your traditional key is protected in some hardware, whereas your post quantum key is not. I don't think this use case is something that justifies any complexity that dual certs does, but the composite is simple enough that I think it is worth it.
[00:59:08] Andrei Popov: Andre Popov, since I'm in the hedging camp, I wanted to answer David's comment there. I wanted to say that, you know, changing key exchange algorithms is a configuration change. Changing your certificate chains is an issue of deploying different fruits of trust potentially, and that could be quite a slow process. That's why we would like to we would like the hedge.
[00:59:31] Chris Wood: Chris, would yeah. Like I said earlier, there are there are real use cases that are using classical authentication with broad public keys. Composite would allow us to implement a hedge solution for that. Yes. It's perhaps very niche. Yes. I don't wanna I don't wanna deliberate, like, what or not that's valid, but, like, it's niche. It's real, and the only thing that's blocking us from doing it is an email to IANA. That seems a bit silly to me.
[00:59:55] Sean Turner: Alright, Hector. You get the last word, and we're gonna do some hums or, sorry, some show of hands.
[01:00:01] Eric Rescorla: Well, I I I am enjoying Chris, replaying my my my my my hits back to me of, one of you just email IANA. I think, you know, but what is at stake here is, not what is allowed, where the tails working group spends time on it. It. And, because you take an email, Anna. And I think that really, you know, that really motivated. Think many people pointed out that really pushes one quite strongly towards these composite versions. Right? Because, like, we can spend very little time with the composite version and get it done, and in fact, that's basically done already. Whereas we're gonna spend a northern amount of with the dual certs version. So in terms of, like, you know, here's the cost benefit for the working group. You know, I, you know, the positive version is, like it's just, like, vastly, vastly easier to do. So if if what we want is a cheap hedge, that's the place that's the way to go. And and I think, you know, when I said grudging earlier, I guess, maybe I was being a little too grumpy about it. I understand people I understand people wanna do this. I'm, like, I'm not opposed to doing it.
[01:00:56] Sean Turner: Alright. So we're at the fun stage where I flash some stuff up that I've typed, and, hopefully, it it works. So I think the first question that we have to ask, which you haven't seen yet, is do we have enough information to take a decision on the way forward for PQ plus TL signatures for TLS? So that's like, if you think, holy crow, we're not like, making the decision now is a complete waste of our time. We need to have an interim and talk about a bunch of stuff. Say yes. We're still gonna ask all the other questions, but I'm curious to see what we got going on here. And I'm sorry, Deirdre. We definitely didn't run these by, so I apologize. Alright. Well, that's out of the 145 people, it's, like, trending heavily. Yes. We have enough information. 60 to 10. Is there anybody that wants to get to the microphone to speak for the no? Alright. I guess we're gonna oh, sorry.
[01:02:11] Chairperson: Sam is in the queue.
[01:02:13] Sean Turner: Alright. I'm gonna go ahead and terminate that one. Yeah.
[01:02:20] Scott Fluhrer: So how
[01:02:20] Mohit Sahni: much you addressed in? So I think we kind of have some information, but I have objection on the the last moment when the slides were uploaded. I mean, if they were, like, uploaded, like, one week before, that would have been nice. One could review that and see that. I've been assessing in this feed for me. It's fine, but but I think it was uploaded very, very late. One needs to analyze the two solutions and see and make a dis better decision.
[01:02:46] Sean Turner: These drafts are not new and have been out for a long time. I take your point, though. Alright. So now we're gonna get to the questions that I had. Let me actually put those that's not gonna matter here. That's so I'm gonna put the one up and said, should the working group work on PQ plus t signatures for TLS at all? Like, this is the rage quit moment where we're done and move on. Balance. The shark is coming to the thing when I said, does anyone that voted no? Alright. So it's pretty good. We have a pretty good number. At this point, it's stabilizing about 53 guests, 20 no. Chris, did you wanna get to the microphone to speak for the noes or say something for the no?
[01:03:55] Chris Wood: Yeah. I'm a no. As I said, like, I don't think we need to spend any time on this. Send an email to IANA. I get the code points. Let's move on.
[01:04:01] Nick Sullivan: Okay.
[01:04:04] Sean Turner: Alright. So the next question is, should the working group work on only one? Again, remember, if you want to work on both, you hit no. If you want to work on just one, hit yes, and then we will figure out which one. K? It's too many questions. I apologize.
[01:04:28] Kyle Nekritz: This is. Alright.
[01:04:35] Sean Turner: Working on one. Bob Beck? Did you get in the queue for a reason?
[01:04:42] Victor Dukhovni: No. I just need
[01:04:43] Sean Turner: Okay. Sorry. Alrighty. We're trending 50 ish yes and 10 ish no. Does anyone anybody wanna get to the no? Get to the microphone to speak for the no. Alrighty. Now we're gonna do this is the individual ones. Alright. So I'm gonna skip the the the other ones. We're just gonna do the ones about working individually on one of the other draft. Alright. So this is the first one. This is the dual certs one. Okay. Definitely trending towards no. Again, we're gonna have to confirm this on the list, but just it's trending pretty heavily. Alrighty. Now we will go to the one which is the composite ML-DSA draft. And, yes, it's got an algorithm name in it. I'm sorry, but it's alright. Let's do it. Alright. Let let's run from the twenty seconds or so. Alright. That looks pretty like, we're trending towards yes for the m l the composite MLDSA draft. Thank you very much for your time. We'll send out something that summarizes we're only doing one and see how that goes. Alright. That's it for that topic. We are now moving on to, I believe Chris. Yeah?
[01:07:08] Chris Wood: I'm sorry. Could I suggest, like, one more show of hands?
[01:07:12] Bob Beck: Sure.
[01:07:13] Chris Wood: I have just one more quick one. Sure. I'm on. With the question
[01:07:15] Sean Turner: k.
[01:07:15] Chris Wood: Can we allocate code points and move on? Yes or no?
[01:07:21] Hannes Tschofenig: It's not the
[01:07:21] Chris Wood: same thing.
[01:07:22] Sean Turner: I I don't have a problem with that. Let's do this. Alright?
[01:07:28] Eric Rescorla: What so sorry. Just I wanna be clear what we're we're we're all set to be humming on here. Is it can we allocate code points and then not adopt the draft, or we can allocate code points and adopt and then and publish it?
[01:07:38] Chris Wood: Not adopt the draft. Not adopt.
[01:07:40] Eric Rescorla: Thank thank you for being clear.
[01:07:42] Sean Turner: Hold on. Let me let me let me nuke this one. I'm gonna start over and be more explicit so that it's in the record. Where is this silly thing? I gotta end it first. Sorry, Nick.
[01:08:00] Nick Sullivan: I don't have the draft.
[01:08:05] Sean Turner: Sorry. I had start it over. Yes. Okay. I'm starting over, guys. I'm now I'm now frustrated if you haven't told. What is the question that you would like me to ask? Okay. So this is can we But should we. Should we. Should we allocate code points for composite composite MLDS for the ID.
[01:09:03] Eric Rescorla: I honestly thought that's what the no in the first question was about.
[01:09:07] Sean Turner: I I hate that this guess guess. So okay. I'm skipping this. We're moving on. Okay. Alright, Nick. Sorry. That doesn't I'm done. Yeah. I'm we're done. We're moving on. We're not we're not nitpicking the co poll. We're not nitpicking the questions. Moving on. Am I up? Sorry. Yeah. Keep it in the. Yeah. Not doing this.
[01:09:34] Eric Rescorla: Okay.
[01:09:39] Nick Sullivan: Thanks, folks, and thanks to chairs for letting me present this. Huge announcement. TLS 1.4. I'm the version of TLS.
[01:09:49] Sean Turner: That's already been out there. We have
[01:09:51] Jonas: to No.
[01:09:51] Eric Rescorla: I'm kidding. I'm kidding.
[01:09:52] Nick Sullivan: Look. This is this is just TLS with a new KDF. So this is a draft I put together. It's more of a proof of concept than anything, but it essentially takes TLS 1.3 and all the places in which SHA two is in there and replaces it with something based on catch- act. So what's unchanged? Basically, CypherSuite, AEAD, the state machine, the way that it looks on the wire, the flow, the places in which the intermediate data points are are deleted. The key schedule has the same stage, same name secret leaves and checkpoints. So only the KDF changes. And this is negotiated in a separate extension called schedule profile. Apps in this extension, you fall back to the KDF that is derived from the hash that's listed in the Cypher suite. So this is this is our nice key schedule. Right? This is the entirety of tls one point one point three, and it's a 156 compressions. There's a couple other features here that aren't fully listed. But, yeah, it looks like this kind of flow. Right? And if you decompose it into the different parts and look at some of the analyses, you see there's a hash, an extract, expand label, MAC, drive secret. At least in paper, this talks about these as roles rather than anything. So thinking about about that as a ETLS as a decomposition rather than as an entire protocol helps you think of how to how to change it. So what's the natural kind of naive way of upgrading this and removing TLS 1.2? Well, just use SHA three. Right? So everywhere where there's hkdf, you do hkdf SHA three. Anywhere there is hmac, hmac SHA three, etcetera, etcetera. You end up with 156 permutation calls, which is just similar to what you would do with TLS 1.2. Now this is decomposed in a really nice way, and there are other constructions that satisfy these constraints based on the Ketchack primitives. And a lot of them are specified by NIST. So if you actually go in and replace the expand by kmac kdf, replace hkdf by kmac, and keep SHA three for hkdf, you end up getting a nice little reduction, down to 117. And the shape looks exactly the same. So that's good. And yeah, this is this is nice. Right? So every box is one extended XOF file. And it's just that the Mac is two. So this is this is nice. You you can drop you can you can do this and and have, like, a pretty fast, smooth ride through some of the existing transformations. But we can do better. Right? XOF has there's a lot of different ways that you can take an XOF and and put it together, one of which is called a deck function. And so you can construct a deck function in different ways. And in this doubly extended cryptographic keyed deck function, you can decompose it in this way. This is there's keyed decks. There's various ways of doing that. But effectively, you have a sponge that you can initialize, you can absorb into, you can derive out of, and then you can ratchet the state, which brings you into a brand new sponge. So with with these, you can actually go in and plug some of the holes. Right? This is TLS one one point three with the deck. So the only really chain real change here between the NIST version and this version is that there is an init function at the top there and then two vertical lines near those two drives, two thick lines, and then two thick lines near the ratchet, which imply starting a new sponge. And these are exactly the places in the key schedule where you would want to delete data or move onwards. Doing so with a very optimized series the the nice thing about a deck function is you can stack a bunch of things in, but you don't have to hash every time. You only hash once you need to squeeze something out of it. And so you can actually get down to a nice 39 permutation calls, which is quite quite an improvement. So just from, like, a step back here to go from where we started to where we are, you have SHA two, SHA three, the NIST primitives, and then the deck function, which and to kind of there are ways of of of taking the hash and the MAC and putting them into a deck function as well, but I'm taking this the very conservative approach here of using shake and using k mac, which are studied and trusted. So let's walk through it. SHA two, SHA three, nest primitives, deck function. It looks the same. The places right here where you had the early secret, handshake, secret, main secret, these are no longer concrete chunks of data. They're state inside of inside of your deck. So they end up turning into clones, which is just a copy of the deck function. So the derived function's pretty nice too. You take your state. You can clone it. And then you can frame all three things that you're extracting from it, absorb once, and then squeeze out three times. And this is not exactly like TLS-one point. It's very close. The only really difference here is that you're swapping the order of two of the tags, which is really only concerning in HKDF and not in an XOF format. So transcript hash, no optimization here. This is a place for optimization. Just swap out your SHA two fifty six with a shake two fifty six and go forward. Looking at the key key schedule, there's two different constructions. The early secret doesn't exist. Handshake secret doesn't exist. Main secret doesn't exist. But it does exist on the on the diagram. So things come in the same way. You absorb the PSK. You absorb your Diffie Hellman or asymmetric secret. And you don't really need to absorb a zero. So, yeah. As I mentioned, there's sort of different ways of analysis. This is one. And the reason why the intuition around this makes sense is that you can think of all of these things with an XOF as a random oracle. Here's the payoff. This is the number of permutation calls for the the naive SHA three all the way to the deck. It's quite fast. You can also reduce these numbers are dependent on the size of the the input. So if you have post quantum keys, it might be a few iterations more, but not many. And if you use shake versus turbo shake, you can cut it again in half. So this can be pretty nice focus on the handshake. So the ask here is if I just released a new spec just an hour ago, so I don't expect anyone to have read the updated spec. There were some really good feedback on the list. Thanks to everyone who replied. And and and, yeah, there's some issues here. Doesn't the translation doesn't of the of the proofs doesn't work exactly. So I'm looking for folks to take a look at it, see if this is safe. And and then there's some future optimizations here that like, I took a very conservative approach. But you could, in the absorb phase, not start a new sponge. Right? And that would save you a hash at the cost of maintaining the state going forward. The issue there is that permutations are reversible. So if you you don't get internal forward secrecy inside your handshake. There's the idea of taking this Mac, which is k Mac right now, and folding it into the deck using some type of deck based Mac function that was brought brought up on the list. And, yeah, there there's also suggestions of duplex designs. Like, are there other ways to do it? The way that this is put together is to look almost exactly like TLS 1.3, including with all the same labels and tags so that it's as conservative as possible. But there may be some optimizations here. Okay. So here's the takeaway. This is TLS 1.3, not TLS 1.4. So it's one primitive throughout the entire handshake. And luckily for the folks who are implementing post quantum, this is something that you get with ML-DSA and ML-KEM. You you have the Ketchik primitive inside of it. This doesn't take away two from the entire protocol. There's still SHA two in a lot of the certificates. So, like, this would be great for PSK mode and whatnot. It extends the importer and the exporter. It works with ECH. There's still some some work that needs to be done to see how the exporter works with QUIC and some of the other derivations from here, DTLS. But at the very least, this is this is the core key schedule can be upgraded. And a lot of protocols at the IETf are exploring, you know, SHA three, Ketchack based things for their key schedules. There's some parts of EdHoc, for example, that picked up KMAC. So this is this is really an exercise in taking something that's fully SHA two based and seeing what it would take to get a relatively optimal version using Ketchack. And, yeah, with that
[01:20:00] Sean Turner: Alright, guys. Questions? We gotta go real quick because we're basically over time at this point. So
[01:20:07] Mohit Sahni: Osama, so very quickly, I think the formal analysis will not be helpful here. So because we take one way functions. So I think that what what you are asking for is the cryptographic analysis rather than the formal analysis. Is this correct?
[01:20:21] Nick Sullivan: I I'm asking for any any analysis that can be provided. I mean Okay. This is a this is this is a proof of concept that I wrote down and implemented in Python and Go.
[01:20:32] Quynh Dang: I'm Quynh Dang at NIST. If we decide to do this, then, you know, this will will would carefully review it and determine whether or not the final spec meeting our cryptographic standards or or requirements. And and and then we go from there. But even in the case, it did not meet our specs. And after evaluation, we decided we we we have a determination that it was good and secured, and we we would find ways to prove it. And for the people who who want the code and compliant way with SHA two, that is fine. So I just want to say that I'm totally supported. I think it's a really a really good one to work on for for the group.
[01:21:25] Nick Sullivan: Okay. Great. That thank you. Yeah. The the middle one here is outlined in the appendix, and it is shaped to fit the NIST analysis of TLS 1.3 pretty directly. But this one obviously brings in a lot of new concepts. Dmitry Believskiy, Red Hat. I have a question. Do you have
[01:22:03] John Price Mattson: John Price. Mattson, with PQC using all Chart three, I think it's great to have the option to use Chart three family in Thales. I think I think the deck option is the right choice here. I think and this is a great first proposal. I definitely think Thales should work on this.
[01:22:23] Jonathan Hoyland: Okay.
[01:22:23] Nick Sullivan: There there's been a lot of positive feedback to at least this idea of adopting something in this shape. So I don't know if Eckers on the on the line.
[01:22:35] Eric Rescorla: I I am. Hi. Just waiting for you to be ready. Thanks for presenting this. I think it's interesting. A few a few initial thoughts, but I haven't had time to release something like this. The first is I think that, you know, being modestly conservative is appropriate here, you know, because of Amdahl's law. Every you know, squeezing last couple cycles doesn't really get us very much, especially because, like, the the p k is already pretty expensive. So, like, know, getting down from $1.70 whatever the number was, the 30 the the fifties gets you through a lot. I'm like, it's not clear to me, you know, getting down to 20. You're gonna help us that much. The second thing, I wanted to observe, is if I understand correctly, you're negotiating this with a tail off extension. Yes. It seems to me that may may not be the right answer. Like, you know, you already have to negotiate the hash of the transcript hash. And so, and so get as I it just seems like maybe you could just say, like, if you're using shot three, this is the way you do it. And, you know, rather than having to be, like, you negotiate shot three, and then you're separately saying use the deck. It's like, like, I think we might might be easier just to say, look. Like, I know we say h k d f, but when you do when you do, when you do Keccak, what that really means is we're doing sorting this.
[01:23:42] Nick Sullivan: So to be clear, are you suggesting new Cypher suites that have hashes?
[01:23:47] Eric Rescorla: Well, so you so you so you are the almost I've forgotten the ciphers who's already have to have to name the transcript hash.
[01:23:54] Nick Sullivan: Yes. They do. And that that was the original version of this, and Martin suggested spinning this out, and it uses the KDF.
[01:24:00] Eric Rescorla: Right. So so I think I think Martin may just be wrong about that because, I mean, I guess, your my point is you're gonna say, in this scenario, you're gonna say like, let let's say it's going to use shot three. Right? You just say, you know, AES plus shot three is what you say. Right? And and I guess and and so that would like, the your version one your version one, right, where you just replace shot two or shot three. Right? And I'm just saying, like, you know, like, if we just agreed that shot three meant don't do version one, but do version two or three, that would be, like, be fine. And rather having just and because is there any reason to have it is there any reason to have a shot three variant that is HKDF for shot three? And if there's not, then we can just, like, overload the
[01:24:36] Nick Sullivan: Oh, yes. Yeah. I I the first two were just examples. I think that No. Exactly. Yeah. I mean, the the deck function is negotiated using the IANA k d f registry, which only has two values right now. So we would be adding two more, one for turbo shake, one for shake. Rather than rather than having a new version of every single current Cypher suite with SHA three, there would be less expansion.
[01:24:59] Eric Rescorla: But may may may sorry. Maybe I'm missing something. But I think the idea is, like, you're gonna what what what so you but you but you would say then you would say you would say, tls a e s one twenty eight plus shot plus shot two fifty six, and then you'd have a separate extension that said, do the do the deck function?
[01:25:18] Nick Sullivan: You'd use the current cipher suites and then negotiate Right.
[01:25:20] Eric Rescorla: But with this. Right. But right. But then but then but then the structure doesn't mean anything, right, in the in the in the cipher suite. Is that right?
[01:25:26] Nick Sullivan: Yeah. This overrides.
[01:25:29] Eric Rescorla: Yeah. I I think I I think that's the worst I think that's worst answer. The the right answer is to read it in cipher Because the whole point of the whole point of that name was to say the whole point of that hash is to say what the transcript hash is. And so if we're changing it, we should we should
[01:25:40] Nick Sullivan: That that's that was version zero. Take it up with Martin Thompson.
[01:25:43] Eric Rescorla: We we we we if we beat this up, we could we could fight that out.
[01:25:47] Sean Turner: I think we need Thank you.
[01:25:48] Chairperson: Yep. Take this.
[01:25:49] Sean Turner: Victor, I think we're have to take the list. Sorry, man.
[01:25:54] Chairperson: That should work.
[01:25:57] Sean Turner: Sorry. It's okay.
[01:25:59] Jonas: Okay. Hi, everyone. I'm Jonas. This is joint work with Constantine, Matthias, and Thomas, and I want to quickly talk about encrypted Client Hello deployments. So because you're here, I assume you know it doesn't click.
[01:26:11] Chairperson: Okay. One second. Sorry. Because
[01:26:14] Jonas: if you're here, you know about ECH, and you probably also know there's one large ECH deployment, which is from Cloudflare. And with our research, we set out to answer the question whether there's also other ECH deployments out there because we wondered, is this really all? And then second, what are typical ECH configurations? How are operators actually handling ECH? Is there actually a latency impact? And how stable is ECH support? How do we measure this? First, we do not rely on the ECH configurations in DNS. Instead, we perform TLS handshakes with deployments and an ECH extension. So, basically, this is a grease ECH connection request, and in the outer SNI, we put target names from topless. We aggregate those over now more than a year. In response, we get hello retry requests with ECH retry configurations, so we learn about an actual configuration, and we then use that one to perform an ECH connection. Yes, this doesn't reveal all ECH deployments because our input set of domain names is not complete, but it is actually finding more deployments. What did we find? So we found actually 5,500,000 domain names from the top list that support ECH. If we break this down to not weigh too much domains that have multiple subdomains on the top list, we end up with 4,100,000 domain names that support ECH. And you can see, mind the logarithmic access, there is the largest deployment is by far Cloudflare. The second largest is actually meta with graph.facebook.com as the ECH public name. And you can also see there's domain names that have an ECH configuration actually in DNS, and there's ones that do not have this. For the case that do not have ECH configuration in DNS, the largest provider is Meta. Also note, not all of the ECH public names that you see here are actually linked to the entity they might the name may suggest to. So looking at the deployment for Meta, we asked ourselves, well, without an ECH configuration in DNS, there is no way for browser implementations to actually use ECH. And what we did to verify this, we actually collected the traffic from an iOS device and inspected whether we would see an ECH extension or not. We saw this for both TCP and TLS connections. Sorry. TCP and TLS and quick connections. And this could also at this point, this could just be a grease ECH connection, but we then verified the ECH configuration ID as well as the ECH public name with the ones that we found in our measurements from the retry configurations. So I'm pretty sure this is actually real ECH traffic. And we also saw that not all of the TLS requests that were solicited by the applications carried an ECH extension. Doesn't click. Okay. Let's look at how the deployments actually evolved. Top slide, see top graph, you see how many different second level domains are in our input data set. And then we also see the deployment sizes for Cloudflare and Meta. And last, we also see all other deployments, and we see that that is very few, actually. Those are just up to 250 different second level domains, and in total, we observe actually more ECH public names than second level domains, and this is due to one deployment using random subdomains to example.com, but having only a single second level domain. What we do not see is a very large increase due to a CDN enabling ECH all at once for all of its customers. Next slide. Okay. What's typical ECH configurations? So most commonly, an ECH configuration carries just a single configuration set, but we do see deployments with much more ECH configurations. Second, not all deployments actually rotate ECH configurations and keys. And last, what we also observed is that the maximum name length from ECH is frequently just the length of ECH public name, so maybe this option is not well understood. Now, you have also seen just the grace period on the slides. How do we measure this? Well, we connect multiple times to the service, in this case of Cloudflare, because they do configuration rotation and try how long the first configuration that we extract still works. And actually, after four hours, four hours after the key is removed from the DNS, this configuration no longer works, and then we get another retry configuration. Why do they do this? I suppose this saves them a round trip because the client doesn't have to use the retry configuration, so it saves that round trip. Next, we also tested a variation of the configuration that was provided by the deployment. So why would you want to do this? Well, if you accept ECA10 checks with an arbitrary ECA public name, this makes it a little bit more resistant to censorship and detection of ECA actually. And what we found is when we tested this that no of the large deployments support this. Yes, this prevents domain fronting. And if you would implement this now, this would also break this retry mechanism. There's an alternative already proposed that was discussed yesterday. Last, is there not last is there a latency impact of ECH? We are tracking the time as seen from the client, and you can see the graph is slightly shifted to the right. So ECH connections take slightly longer than just TLS connections without an Ech. Next, we also looked at stability. So, if an Ech deployment, if a domain name supported Ech at the beginning of the graph, we also track how this behaves over time. And you can see, yes, it decreases, but most of this decreases actually due to failures in named resolution. So I would argue that the ECH deployment is overall stable. Let me conclude. ECH deployment is actually emerging, but relying for your measurements and discovery just on ECH information in DNS, this is not comprehensive. We're seeing there's also other large pipelines, like the one from Meta. We've also seen those smaller domains. I haven't looked into We haven't looked into the details, but for those smaller domains, the set of private domain names is just smaller or equal than 55 domains. You should choose an adequate grace period to optimize your ECH connections, and there was mainly a latency impact. Last, if you want to play with this a bit, so use the method that I just demonstrated, you can use ECH tool, the tool I worked on during the hackathon, and you can find it also on this website in a live version to play with. Okay. Thanks.
[01:34:00] Sean Turner: Thank you,
[01:34:01] Kyle Nekritz: Kyle. Guys, real quick. I think it's great you're noticing this. I'm hoping a lot of more to share about our deployment in the not too distant future. But as you noticed, we do have at least one of our major apps that is actively using ECH widely. It works great. It's performance, and I encourage others to do the same.
[01:34:26] Participant: Hi. Thank you, I think this with the ECH deployment is important. I will suggest also to add an additional KPI that is the privileged observer point to the diversification of client facing server. As today, the response is obvious. It's just one. But with the following deployment, this could increase the privacy because now with just one client facing server, there is a privileged observed point.
[01:35:00] Jonas: I didn't fully get your question, so we should talk about this afterwards. But there's not just one deployment, there's also the large meta deployment that is in use.
[01:35:10] Participant: Thank you.
[01:35:10] Sean Turner: Alright. Thank you very much. Go enjoy the farewell reception. Thank you. Sorry we sorry we almost ran over. I'm glad we're here.
[01:35:21] Chairperson: You did well with this.
[01:35:38] Sean Turner: You know, was that was questionable.
[01:35:41] Chairperson: Yeah. Which which?
[01:35:42] Sean Turner: I'm trying,
[01:35:43] Chairperson: man. You
[01:35:44] Sean Turner: guys did one. Yeah. Yeah. Yeah.