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

[00:00:37] **Tommy Pauly**: Good morning, everyone. We are

[00:00:40] **Tommy Pauly**: in HTTP. Happy Friday. Hope you've had a good week.

[00:00:44] **Tommy Pauly**: We're gonna get started in a second. Should we ask for notetakers here? Yep. We do have the ability to get some AI assisted notes, but we really do appreciate getting some human note taking as well, mainly just of summarizing important decisions or relevant comments that we need to remember. Can we get a volunteer to jump into the notepad to help take notes?

[00:01:18] **Mark Nottingham**: Lisa, you for your service.

[00:01:22] **Martin Seemann**: Round of applause, everyone. Thank you

[00:01:25] **Marius Kleidl**: very much.

[00:01:28] **Speaker 5**: Alright. Uh-huh. So we we have enough. Should we get started? I well, it's Give

[00:01:33] **Tommy Pauly**: it a minute.

[00:01:34] **Mark Nottingham**: It's 09:01. Maybe give them one minute since it's Friday morning.

[00:01:37] **Speaker 5**: Yeah.

[00:01:37] **Tommy Pauly**: Yeah. And

[00:01:38] **Martin Thomson**: I think we'll we're

[00:01:39] **Tommy Pauly**: not gonna use the whole time.

[00:01:41] **Speaker 5**: Well, I don't know.

[00:01:42] **Mark Nottingham**: We'll see. I think you just give everyone an incentive.

[00:01:50] **Ben Schwartz**: Right. We're trying to make sure we run out of time before that.

[00:02:06] **Tommy Pauly**: Mark, would you like

[00:02:07] **Mark Nottingham**: to I can I can delete them?

[00:02:08] **Tommy Pauly**: Would you like to just describe the picture we're

[00:02:11] **Mark Nottingham**: seeing here? Sure. So so as has often been the case over the years, we try to stay with the theme for the meetings. This is in a town south of Salzburg, and it seemed serene and thoughtful just like this group.

[00:02:30] **David Schinazi**: Sure.

[00:02:32] **Mark Nottingham**: Good good luck with that. I can probably go ahead get started.

[00:02:45] **Speaker 5**: Yeah. Okay.

[00:02:46] **Mark Nottingham**: Alright. Welcome, everyone. It's Friday morning. You're at the ITF, and this is the HTTP working group. Hopefully, you're familiar with this. This is the statement of the policies that we operate under. By participating, you're agreeing to these. Yes. It is a click wrap or maybe a browse wrap, especially regarding your behavior, so professional behavior, harassment policy, the handling procedures thereof, intellectual property, and that includes the statements you make as well as what you write and submit to the group either in an Internet draft or in an email or a GitHub issue, and the status process that we follow. Also, this is being recorded, so there are photographs being taken. Hopefully, everybody's familiar with this by this point. Any questions, please talk to us or your local area director. We have a scribe. Thank you again, Lisa, for your kind service as well as well, really accurate scribing too in in in some fashion. So we have the full power. We have a packed agenda today, but many of these items are going to be fairly short. So anybody have any bashing for the agenda? Doesn't sound like it. Sounds like we have a typical Friday morning crowd. Let's go ahead and get started then. First up, we have resumable uploads. How do we drive that? I believe it's gonna be Marius presenting.

[00:04:28] **Marius Kleidl**: Yes. Yes. Let me request slide. Alright.

[00:04:31] **Tommy Pauly**: Giving you control right now. Wait. Hold on.

[00:04:43] **Marius Kleidl**: There you go. Alright. Good morning, everyone. This is gonna be a lightweight update on resumable uploads. We've started a working group last call in last July, pretty much a year ago. We got a ton of feedback. In total, we opened 90 issues for all of the individual comments that were raised. So thank you all very much for all of these comments. We were able to address most of them so far. 82 have been closed already, meaning that only 80 are sorry, eight are remaining to be addressed. Most of them are more editorial or asking about certain clarifications that are on edge cases, there's not really much substantial in there, that we have to discuss or that needs a big venue to be addressed. Overall, we aim to close the remaining eight ones as well, and then cut a new release or a new version, and then, hopefully, for a second working group last call. So if you're interested in reviewing a document, I will recommend you to wait until we've addressed them, and then it's probably best to review the document in its entirety as a new document, because there have been many changes, many small changes since, the last working group last call. So yeah. But, yeah, thank you all for the feedback. It was really great. Talking about new releases, we've done substantial work since the last version 11. I'm not gonna go into all of them. These are just a few highlights because there have been really many changes. We removed normative language around, addressing the topic of, like, the final response, what if it's lost. That was the result of discussing this into multiple ITF meetings, so we removed that. We also clarified what happens if the server wants to stop the upload prematurely, just how in h two, for example, you can interleave requests and responses, if you wanna send a response a bit early. And, unfortunately, we also had to remove the section covering integrity digest. Lucas wrote more about this on a mailing list, but the motivation was that the semantics were not entirely clear, and we also didn't have the practical experience yet. So this felt more like a theoretical exercise rather than actually burying this in practical experience. But we might revisit this in the future, but not in this draft. But, yeah, if you wanna see the full change log, it's in the draft in the appendix. Go check it out if you wanna see that. Besides that, at the workshop last week, there were also some discussions about how to integrate resumable uploads into browsers and specifically into the HTML forms and the fetch API. There were some considerations around how to handle cross origin resource sharing or what happens if the origin changes when you resume an upload. What about cookie, content security policies? This isn't the right venue to discuss these, but I just wanted to point you that we now have a tracking issue for these for both pointers to the corresponding issues in the working group. So if you wanna discuss this, if you wanna learn more about this, you can click the issue in the slides and then be redirected where you can learn more about this and discuss this. But, yeah, this isn't the right place to discuss this, but I just wanna point out that this is the place to go. Yeah. And I think that's all I have for now. As I said, we're gonna work on closing the remaining issues, cut a new draft, and then hopefully add for a new last call. Yeah. That's all I have. Thank you.

[00:08:24] **Tommy Pauly**: Alright. Thank you for the update. Are are there any questions from the room, from online about this document? Not seeing any. I I just wanted to ask probably for the process of this. Given the changes that you've made so far, and it sounds like the remaining ones are more editorial, for anything that is a normative change or that would impact interoperability, have all of those changes been reflected in people's implementations yet? So do we, like, do we expect that the version that we would go to last call with is reflected in what people are testing with and implementing, or do we also want some time for implementations to update?

[00:09:14] **Marius Kleidl**: I think the implementation, for example, in Apple's networking stack, I think that has been caught up. I have to update my implementations a bit, but the normative changes have mostly not impacted interruptibility as far as we know so far. Okay. And we'll probably wanna do a bit more testing after the final version, hopefully, but I don't expect this to delay the process of this draft for that.

[00:09:43] **Tommy Pauly**: Sounds good. Thank you.

[00:09:46] **Tommy Pauly**: I think we'll move on.

[00:09:47] **Tommy Pauly**: Thank you for the update.

[00:09:50] **Tommy Pauly**: Alright. Next step. Great. Yeah.

[00:09:52] **Mark Nottingham**: So next step, we have a very short update on the layered cookie specification. As as well. That looks nice. As you might know, we have a revision of RFC 6265, the BIS document for that in the r c editor queue. That was approved a while back now. Just checking that is in the final review stage, which is what some may be more familiar with as AUTH48. They've changed the name so that people don't think about the numbers and the time there. So sorry? It's not for me. Don't give people ideas. So it looks like it went to final review earlier this month, about two weeks ago. So the authors are going through their last processes there. Frankly, they may have to their attention may have to be refocused because it's been a while, and it is, of course, holiday season right now. So that's the status of that document. The other document that we started towards the end of that process was the layered cookie specification where, effectively, we're refactoring the cookie specification. So the split of of normative text is more reasonable between what we're doing on the wire in HTTP and what the implementation is doing in the fetch specification, at least for browsers. So that's still in train. We we've had a communication from the authors that they're still working on it. They don't have anything to report right now, and more importantly, they're on holiday right now. So that's that is the update of that spec. I don't know that if there are any questions, we can talk about it, but I I I would just assume we're gonna get another update in November. We'll continue to discuss that on the issues list and the mailing list. Next up, the preliminary request denied HTTP status code. So this is my specs, so I'll, you know, virtually go to the floor. There has not been a lot of discussion on this. I think the core of the text is is relatively stable. What we do need to do is to choose a status code for it because it's four x x. And we had discussed on list, I believe we're looking at four nineteen, if I remember correctly. Sorry. It's been a little while. And and the only thing that we found doing kind of squatting on that status code was that, I think, Laravel is using it for for their purposes. I've had a preliminary discussion with them. That hasn't concluded. I think there is a migration kind of path for them to to, you know, use another mechanism, probably not a status code, to be honest, because I I kinda don't think they need one. But if they wanna come and try and standardize one, that's great. So I guess the question for the group is is do we wanna go ahead and use I I believe it's four nineteen, or try and find another status code and then go through the process of figuring out if anybody else is using that for their own proprietary purposes? Personally, I I think if if we set a precedent of not using a status code because one implementation has been squatting, we're in a lot of pain pretty quickly. But I'd I'd love to hear what other people think. It's Friday morning. 419. 419? I I hear support for 419 in the room. I see another thumbs up. I feel like I'm an auctioneer all of a sudden. No. No. No. No. No. No. We're not going there. Okay. So I think what we'll do is I'll we'll send a very explicit message on the lists outlining the proposal and the situation. We've heard support in the room. Unless we get an objection and an argument behind that, I think we'll we'll go ahead and use that and and continue to probably go to working group last call pretty soon then because I don't think there's a lot more. It's it's a very small specification. Any other discussion on that spec?

[00:14:05] **Speaker 5**: Okay.

[00:14:09] **Mark Nottingham**: Next up, secondary certificate authentication of HTTP servers. This is something that we've been talking about for a while in various forms. We've scoped it down. We've been back and forth. I think we're in a state where all the issues have been addressed. And talking with the authors, I think we're ready to go to working group last call. So I think, from from the chair's perspective, our intent is at this meeting, we're gonna go ahead and kick off mid two or maybe three week working group last call just because it is holiday season. Give people a chance to have a look at it. Any thoughts? I see thumbs up in the room. This is a dangerous precedent where I have to proxy all the feedback. Centralization's an issue here. Oh, dear. Any any comments, any thoughts in the room, or should we just go ahead and start that process? I see the area director making motions towards the microphone.

[00:15:04] **Tommy Pauly**: Awesome. Awesome.

[00:15:05] **Mark Nottingham**: And author. True. Yes.

[00:15:08] **Mike Bishop**: I I can't speak here as area director because, technically speaking, I'm an author on this, although that's kind of by courtesy since it's a generation ago from what I wrote. But, yeah, we have been working on this a long time. I'm two houses removed from the house where I wrote that initial draft. So, yes, please send it during your last call. And ironically enough, even though I'm credited as an author, it's been a while since I've read this version. So I will do a last call review. Okay.

[00:15:39] **Mark Nottingham**: So it sounds like when we do the that last call, let's maybe make it three or even four weeks just to give people time to page it back in, freshen up their memories, and get a good look at it. Yep. Okay. Perfect. Next up, template driven HTTP connect proxying for TCP. Do we have Ben? We do.

[00:16:02] **Ben Schwartz**: Good morning.

[00:16:06] **Tommy Pauly**: Do do you wanna request slides? Yes. Fantastic.

[00:16:19] **Ben Schwartz**: Alright. This is Connect TCP. This is just a reminder slide about what it is that we're talking about. I'm not even going to discuss this. This is just your reminder about what the draft is. So, we talked about this at IETf-one twenty five, which was draft 10. The since then, there have been two major changes. For there have been two revisions. First, draft 11, which made essentially one change saying that instead of, saying that you may send a proxy status trailer, draft 11 says you must not send a proxy status trailer. We had an extensive discussion about that. Draft 11 entered working group last call, and and Eric provided 19 working group last call issues. Thank you. Also, thanks to Willie Tara who chimed in and, offered some valuable insights. The last call concluded revised ID needed based on those issues. And a couple days ago, after the window reopened, I published draft 12, which hopefully addresses all of those issues. There are lots of small changes between draft 11 and draft 12, but none of them are things that would break compatibility. Here is a list of all of the issues in draft 11 or filed against draft 11 that resulted in changes in draft 12. All of these issues I have marked closed either because the change seemed to pretty clearly address the issue in my view or because we had some discussion about this, on the issue with person who filed it and determined that it was reasonably satisfactory except for one. So there's one remaining issue that is open. The changes for it are in. Hopefully, anybody who cares about this issue can comment and tell me if they think that the changes in draft 12 are sufficient to close. This issue was filed by Eric. There are also a number of issues that were filed that, had some discussion, but were closed without making any changes in draft 12. And I'm happy to discuss any of those issues if anybody has a topic that they want to address. But, otherwise, I think that we're done here, and, the chairs can decide if this is the revised ID that was needed or if they want to repeat the working group last call.

[00:19:45] **Mark Nottingham**: Any comment or questions from the room?

[00:19:49] **Dennis Jackson**: One sec.

[00:19:50] **David Schinazi**: We're going up the issue.

[00:19:51] **Mark Nottingham**: Okay. I mean, I think, you know, the the rough path forward here would be we'll give a notification to the list, but not a full working group last call just to see if, you know, if anybody wants to say my issue wasn't resolved. But, otherwise, it sounds like we can do our chairs review really quickly, get it into ITF a last call, give it to the ISG. And then, you know, if if someone does discover, oh, wait. This, you know, didn't address my issue or or what have you, there still is that opportunity.

[00:20:27] **Tommy Pauly**: That that sounds good to me. With regards to the one issue that you didn't get closed, what we think is addressed, is that potentially something we can where you you can summarize for this group? Because I I think we also have the option of reviewing that here and then deciding as a group that, yeah, that sounds good, and we can just go ahead and close that issue.

[00:20:52] **Ben Schwartz**: Sure. So I I think it might be worth pulling up that issue on the screen if you wanna talk about it. But in brief, this is continuing to think through the the details of, of, certain shutdown situations. So this is really about abrupt closure in in different variations on the problem of signaling signaling that a connection has shut down in kind of an unclean way and also some consequences of that signaling. In particular, there's some interesting implications related to resource utilization Because depending on how a TCP connection is closed, it turns out that the TCP state machine can be it can end up in a situation where where one side or the other is holding on to some resources open for several minutes, and there's a risk of some kind of DOS attack where I can, like, exhaust the number of open ports for certain kinds of situations. So that was all that topic has all been discussed a lot already in the draft, but this is some further clarification and advice about that.

[00:22:45] **Tommy Pauly**: K. That seems reasonable. Oh, David is getting up to the queue. Please go ahead, David.

[00:22:53] **David Schinazi**: David's. Thanks, Ben, for all the work here. This seems good. I one small thing, if you want, I can follow an issue. Can we say that, like, immediately after working with last call, we can assign lower capsule types? Speaking with my capsule type, I know expert hat on. Just I've shipped stuff with multiple versions, and it's somewhat of a pain. And I think this what we've been doing in a bunch of cases, and these capsules are simple enough that I doubt their semantics would change. So I would I would request we change them then if that's alright.

[00:23:34] **Ben Schwartz**: That's certainly fine with me.

[00:23:36] **David Schinazi**: Awesome. Thanks.

[00:23:41] **Tommy Pauly**: Yeah. I think that sounds fine. So I guess, Ben, at this point so you're not planning any more updates, so we can just send a mail to list to confirm that with people. And then I'll I'll work on the Shepard write up and kinda any final review there. And then as part of that, I'll ask you to do a further revision, and we can, in that revision, get the updated capsule numbers allocated for you.

[00:24:13] **Ben Schwartz**: Yeah. I'm I'm not exactly sure how the the bureaucratic procedure works of, like, who submits exactly the request to the registry at what point in time, but I'm sure we can figure it out.

[00:24:26] **Tommy Pauly**: Yeah. We yeah. We we we can we

[00:24:27] **David Schinazi**: can drive that. Yeah. Just it's a expert review registry, same as quick with provisional and permanent. So anyone on the planet can put a request for provisional, and then it and we'll and then it'll become permanent when the ERC is published. I'd say you as Auster get to pick your favorite numbers, for this. Just, follow with Diana, and and I'll approve them.

[00:24:55] **Ben Schwartz**: Alright. Okay.

[00:25:01] **Tommy Pauly**: That sounds like a plan. Thank you.

[00:25:05] **Mark Nottingham**: Great. Now we're on to the news. So that's the active drafts that we have to discuss today. We're gonna move on to other topics. These are not official work items of the working group. They're just things we're talking about right now. So first up, we have the card, HTTP signature key header. Look at the slides.

[00:25:31] **Speaker 5**: And I'll make the clicker work.

[00:25:33] **Mark Nottingham**: Right. Thanks. The clicker.

[00:25:40] **Justin Richer**: It's a draft that myself and Tivo have been working on. It originated out of, you know, me seeing what Tivo was working on and what bought off and some other things. I'm thinking it'd be useful to have a more generic mechanism for how to do HTTP message signing. So quick overview. I'm gonna go over what's happened since 01/25 and then talk about why I think this is important. Really, the 9421 defined, know, how to sign things but didn't define how to have the key. And the goal of signature key is to be able to pass the key along and be able to resolve that key back to something. So there's a number of different schemes around how the key is moved. There's just send the raw key. H w k stands for header web key. It takes the same parameters that would have been j w k and puts those as structured fields in the header. There's jacket JWT, which is a thumbprint of a key, and so it's a key enclosed in another JWT. So then you could use a root key that's in an enclave, but use another key for signing all the time. There's javkest URI where it's URI. Hey. Go over here to go and get my key. Self JWT, which is a new one, and then a JWT, and then x five zero nine because people like that, I think. Maybe not. You can kinda skim over these things. You know, the scheme dictates what the parameters are. So number of changes since the last one. I chatted briefly about Jack a Jot the last time that's now in it, renamed it, came up with the sig key parameter. There's a signature header. We've had a fair amount of implementation feedback that's sort of driven some changes, added the self jot scheme, and then added references to where it's being used. One of the things that came up in implementing was sure. Mhmm. A parameter DWK, which stands for dot well known, which simplifies a middleware to be able to go and verify anything that comes through in signature key without needing to know the specifics of the dot well known. And so if you know the issuer, you know what kind of dot well known is, you can go and resolve and get the JWKS URI. And so that's a parameter in the header. Or if it's a JWT, it's a property in the JWT. And that dramatically simplified a number of libraries that people have been working on that they could just generically be able to go and verify the signature and then let the next layer in the stack deal with more application level parameters. So the jacket JWT scheme, I talked about that some. The self JWT scheme came about where you wanted something like a JWT, but there wasn't a layer of indirection. And you wanted the JWT because you want the JWT to be go down further down in application processing, and so you want some layer further down to be able to know which party actually made the statement. Sort of a key thing about how we're using signature key and other pieces is that you're able to go and just move regular HP messages so you're not impacting the API you're on. And so all of the authorization, you know, essentially authentication authorization are all happening in HP headers as opposed to trying to have that be in the body. And so sometimes you want that to need a JWT and the header to know who did it and be able to hand that further down. And then came up with, okay. Well, what if you wanna say that, oh, I want you to send me a signature and but then there's a couple of different kinds of signatures, ones where it's just anonymous, one where it's identified. So we're adding a new parameter for the accept signature header. And then, you know, an error message so that if something wasn't right, the other side would know what was wrong with the signature. And a new another one's come up since I did this, which was, oh, that maybe you don't know what the scheme is that you got handed. So the unknown scheme would be another type of error. It's set up so that you can have incremental adoption. You know, you'd that the other site can say, hey. I want that, and and then the sender can send that. And then there's a couple specs building on it. A auth, there's now libraries that you know, people have written a auth code in TypeScript, rust,go,.net, and then someone posted one up on Elixir this morning that I saw. And so to do AOS, you need to do the whole six key stack as well. And then have it in email verification, and then there's a new spec and implementer's draft in OpenID foundation called OpenID Connect, key binding that binds a key to an ID token. But then there's not really any what's a good practice for if I've got the ID token, how do I prove possession in calling to another party? And so looking at using signature key for that as a mechanism for people that don't have an existing way around that they're proving position of the key. And then at AFNite, people heavily use this because it's sort of, like, a useful thing around how do we get rid of API keys as opposed to proving you're the right party because you've got an API key. You can prove your live party by proven possession of the key that binds back to a durable identifier. We had a number of demos on that. You know, because people have been building it, you know, a number of things. People have found errors, and we've updated the spec with those. But the to me, the bigger picture issue here is and you think in HTTP, we've solved how do we know the server identity with TLS, DNSSEC, and let's encrypt. But we don't have a standard way around how does a client prove who it is with a you know, essentially, say, I am this Drupal identifier. And so I think that this is a nice generic mechanism for how can a client prove here's who I am. You know, that same primitive solves, you know, problems in a number of other areas. And so there's a fair amount of interest from quite a few parties around using think this as a mechanism to get rid of API keys. It's sort of where a lot of the interest is. Of course, that's also a similar mechanism as to what's used in web bot auth. And so the question is, is this something of interest for the working group and whether there's interest in adoption? I'll turn it over to the chairs.

[00:33:30] **Mark Nottingham**: Thank you. So, yeah, the the thinking here is that this is a generic kind of extension to HTTP signatures. This group produced HTTP signatures, so it's a a reasonable place to take on this work. We'd like to test that with the group and make sure folks are comfortable with that. I don't think we wanna go too deep into identity land in this group. That's not where our expertise is. But I think as long as as the characterization is is that this is just a natural continuation of the work of the HTTP signatures work, this this might be a suitable home for it, as well as, of course, as if folks think that this is the right basis for continuing that work. So comments? So we got Dennis in the queue.

[00:34:18] **Dennis Jackson**: Dennis Jackson, Mozilla. I can see why this would be useful. There's a lot of security relevant text in this draft. And I think if this group is gonna do this work, it needs to do it very carefully in coordination with sec area.

[00:34:33] **Mark Nottingham**: Of

[00:34:33] **Dennis Jackson**: course. Work in these sort of the appropriate considerations for verification and maybe the general security property that every instantiation of the scheme is intended to provide around proof of possession. We'll need some pretty careful work and sort of wordsmithing. But, yeah, I can see why it looks really useful.

[00:34:51] **Justin Richer**: Great. Thanks. Cool. Yep. And that's the motivation of bringing it to groups to get many eyes on it. Yes.

[00:34:57] **Mark Nottingham**: Yeah. And and We'd

[00:34:58] **Justin Richer**: love your feedback on it, Dennis.

[00:35:01] **Mark Nottingham**: Just from, I guess, from a chair perspective, you know, the fact that we were able to do that successfully for the signatures, that gives us some amount of confidence. Anyone else? I I will I will put on a different hat. I I did notice from a well known URI reviewer specification registry expert perspective, the the the ability to specify an arbitrary well known URI in the URI give just tweaks me a bit. I think we need to talk through that in that that namespace is is managed by registry, and it could be a bit of a foot gun, but we can talk through that.

[00:35:43] **Justin Richer**: Yeah. The motivation on that is that there's a number of different parties, and they're calling, and they have their own dot well known that gives some metadata about who they are. And then so this makes it a generic mechanism so so so that something that's verifying the signature doesn't need to understand the dot well known, but knows how to get the dot well known to get the JWKS URI.

[00:36:06] **Mark Nottingham**: Right. It's just a question of whether those parties are naming an arbitrary well known or not. But Yeah. We can talk through it.

[00:36:11] **Justin Richer**: Sure. Okay.

[00:36:12] **Speaker 5**: Yeah. Ted. Ted Hardy. My quick read of the the spec kind of ran into section four dot six with the coexistence with w w w authenticate and kinda tripped a little bit. I think that section might need a little bit more text on what you do if you're a client that understands both. And it just seems a a little bit more explanation of of how you resolve that would would be valuable. Thanks.

[00:36:40] **Marius Kleidl**: Okay.

[00:36:40] **Eric Nygren**: Thanks.

[00:36:43] **Justin Richer**: So But there's a issue tracker as well if you care to write one on that. Yeah. Or okay. Thank you.

[00:36:54] **Mark Nottingham**: Any other discussion? We were thinking just to get we're we're not doing an a call for adoption right now, but we thought just to get the temperature of the room, just ask a poll question. So if you're not logged into data tracker, please do so, and that also helps us get our virtual blue sheets. I was gonna ask who who's interested in in this. Are you interested in working on this in HTTP? This is the question. So So it should be in the polls tab now.

[00:37:34] **Tommy Pauly**: This is where you go back into your auction your voice.

[00:37:36] **Mark Nottingham**: Oh, no. No. I have here a beautiful no.

[00:37:43] **Justin Richer**: I see 13. Do I see 14? Do I see 14?

[00:37:49] **Mark Nottingham**: I guess the incentives are really okay. Yeah. So I see lots of yeses and lots of no opinions and no noes. So that that that's a nice signal to have.

[00:38:01] **Tommy Pauly**: Yeah.

[00:38:01] **Justin Richer**: Okay. Thank you, everyone. Thank you. Cheers.

[00:38:08] **Mark Nottingham**: Next up, we have Martin Siemens using quick stream resets with partial delivery in h t p three. Martin?

[00:38:20] **Jonathan Hoyland**: You have the slides?

[00:38:21] **Mark Nottingham**: We should.

[00:38:24] **Tommy Pauly**: All the slots are taken.

[00:38:26] **Speaker 5**: Oh, dear. What does

[00:38:27] **Mark Nottingham**: that mean?

[00:38:28] **Tommy Pauly**: Oh, it means I need to

[00:38:29] **Marius Kleidl**: take request back. Yeah. Yeah.

[00:38:30] **Mark Nottingham**: Oh, okay.

[00:38:33] **Speaker 5**: Okay.

[00:38:36] **Mark Nottingham**: There it is. Yeah. Yeah. There. Alright.

[00:38:40] **Speaker 5**: And I need to give it back.

[00:38:45] **Tommy Pauly**: Good

[00:38:51] **Martin Seemann**: morning. We recently just, published a an extension in, the quick working group. It's now an ITF last call. It's called RESET_STREAM_AT that modifies how the quick stream reset works. As a

[00:39:11] **Ben Schwartz**: quick

[00:39:11] **Martin Seemann**: recap, when you reset a stream in h in in QUIC, you don't get a lot of guarantees, and the ROC cost this out. It can be that the receiver received all your data and has already processed it. It's also possible that this data is still in flight or might have been lost. And then when the stream is reset, this data is never delivered to the application. And the RFC is intentionally very vague what happens. It it's a decision of the implementation to handle the situation. So even if you have received the data and you you received the reset, the RSC is like, what do you do with it? Do you deliver the data to the application, or do you just drop that data? Don't care. Do whatever. What this new extension that we are now getting gives us is that you can say, like, yeah, I might have sent, like, this much data, but I really want you to deliver up to a certain offset in that stream reliably. So even if this data is lost, this data will be retransmitted up to this offset. Everything beyond this offset is gone, might might be gone. But the guarantee is that up to this reliable size, all data will be delivered to the application. We created this extension for web transport, and it's now implemented in all major browsers. It's in Chrome. It's in Firefox and Safari. It's in I don't have a comprehensive list, but it's in a lot of servers. Any server that supports web transport needs to support this extension. So this is pretty widely available already. The draft I wrote for this working group now outlines how we can use this extension in HTTP three to make things to to work around a few few corner cases there and to help with debuggability because h e p three uses quick streams, obviously, for requests and responses. And when these streams are reset, then both the request or the response headers as well as the as the the request body or response body might be lost. And in some cases, we can do better. For example, in when we are doing connect proxy, the RC defines that any any error that happens on the upstream link is just translated into an h three connect error. So you might just have sent the the connect request. The client might not might not even have gotten the HTTP response, and now the stream is already reset. In a lot of cases, it is it it is useful to say, like, okay. I want to communicate to the client the like, establishing the connection to the upstream server did succeed. I received a certain amount of bytes, and then the connection terminated. So you can easily do this with the reset stream at extension by just setting the reliable size to whatever your stream size was, making sure that all the data that was transmitted between you and the upstream and in the other direction is actually received. Another rather weird case is how RFC nine nine one one four handles certain errors in your certain errors in your your HTTP fields. So let's say you get an HTTP header. You put it through QPack and it decodes. But then there's a list of conditions of what these header fields need to look like. They all need to be lowercase. They can all just be, like, ASCII characters, and the list goes on and on. And you do this verification, and you notice, like, oh, the peer violated one of those. According to the RC, you just reset the stream, and that's totally fine. It's an invalid request. We don't wanna process that. It's also really hard for the client to know what it did wrong. Stream was just reset. Might might have been, like, a 100 header values. Which which one was like, what what's the reason that the stream was reset? Like, there's no way to get this information with RFC 9114. So the idea is here to just set an HTTP 400. It's a bad request. Set a request response body with a short header message, like this header field contained an invalid character, and then reset the stream. Now on the client side, it's very easy to see what you did wrong and maybe fix fix a bug in your HTTP stack. This is a very another case is is very similar when you wanna reject reject a request that we introduced in your error code, the h three request rejected, which is sent when the server receives the request but decides to not process it at all,

[00:45:03] **David Schinazi**: which is also a

[00:45:04] **Martin Seemann**: very unhelpful error code. You just know the request was rejected, but you don't know why. You don't know what to do with it. Like, can you just send it again on the same connection? Do you open a new connection? Send the request there. So being able to send an HTTP header in addition to the stream reset seems useful in that case as well. And that's already my last slide. So what what I wanted to do with this draft is just highlight that this possibility exists, that it is implemented in in all browsers and web servers, and you can just use this and make your life easier.

[00:45:46] **Mark Nottingham**: Mike.

[00:45:47] **Mike Bishop**: Mike Bishop. No hats. So for most of these, I agree. This is fantastic. Please use it. For rejecting requests specifically, the semantics of that error code are that it was not handed to the application layer. If you get an application layer response, that is by definition not true. So please don't use it in this case.

[00:46:12] **Martin Seemann**: Are you talking about the application layer on the server side or the client side?

[00:46:16] **Mike Bishop**: On the server side. So if you get a request rejected, that means that it was never actually processed. So if you go to status code, it was processed and resulted in an error.

[00:46:29] **Martin Seemann**: It could be your HTTP stack that generates that status code. Right?

[00:46:33] **Mike Bishop**: Yes. Layering. So it's the h three versus h the HTTP semantics. So if you're getting an application layer response, then you send a close because you that is your complete response. If you don't generate a response and you did not process the request, you reset with h three request rejected. But doing both is a little contradictory. Otherwise, good stuff. Yeah.

[00:47:10] **Martin Seemann**: Go ahead, Ben.

[00:47:13] **Ben Schwartz**: Yeah. So I agree with Mike. Also, on the TCP point, I'm sure you're aware, but I wanna make sure everybody understands that the whether we're talking about, classic connect or the new connect TCP stuff, the, the h three connect error here will if we are actually proxying into TCP, the h three connect error will be converted into a TCP reset. And TCP reset has exactly the same semantics as classic quick reset, which is to say that it potentially indeed, I think, usually, invalidates all buffered data on the received side. So the result is that although you claim that you've used reliable reset, you do not actually have reliable reset, and your all the data that you are trying to protect will probably be dropped anyway. So I think that this is perfectly valid. You're welcome to do this, but there are a lot of situations where it's not going to work as intended.

[00:48:28] **Martin Seemann**: You're saying it doesn't work in the client to proxy direction. Right?

[00:48:35] **Ben Schwartz**: So there are it's basically symmetrical. It's just that clients are typically more likely to have the the the application consuming TCP plug directly into the HTTP stack, but that's not a requirement. In principle, the client can be operating as a tandem forwarder between a TCP connection and an HTTP connection just as the proxy usually is. Anyway, I I also wanted to confirm that there's no proposed change to the connect TCP draft here. The minute let the minute show that the answer is no.

[00:49:23] **David Schinazi**: David's, Google. To add to what Ben was saying, I was just checking RC9293 and it the the the updated TCPRFC, and it says that, yeah, if you get a reset, any socket call to read must fail with whatever error. You really throw that data away. So, like, we're we're kinda cutting out a bunch of these use cases because they don't quite work. And so taking a quick step back, the reason we define this for web transport was that for web transport, we accidentally put we happen to put stream metadata that was critical to connection state inside the stream data because we didn't have a way to tack on, metadata onto a quick bidirectional stream. In this case, for transport, it was oh, we created a separate bidirectional stream, and we needed an identifier to say, hey. By the way, this is tied to this web transport session. If Quick had built differently, such as, let's say, if we we could if we could add a metadata next to it, we wouldn't need this. And so I can imagine cases where you wanna use this, where you wanna kinda save some of the metadata. And so the only ones that I find maybe compelling are the ones where you say, just please send that header's frame and make sure that gets across and then nuke the rest. But like other folks have mentioned, a lot of those aren't quite right either because if you send headers like you're kinda saying semantics, whereas the reset is this whole thing is blown up. So it's cool that we could, but I don't think this quite this maps correctly onto HTTP semantics. I haven't quite seen a use case that really works.

[00:51:24] **Tommy Pauly**: Right. Then I got in queue without hats on, but I'm gonna stay up here. I I think I agree with what I've heard so far. Initially, I was gonna get in queue just to ask about, like, hey. You're talking about connect. It feels like if we are talking about connect, we should at least mention extended connect and all the variants thereof, because I assume this wouldn't apply just to classic connect. But, overall, I think maybe just something that'd be useful for the document, and we can debate what stays in and what stays out, is to be really clear not just on you can do this, but, you know, what a client does usefully in reaction to this, like, give some guidance about at at least a couple examples for how they make use of this. Maybe it's just for error logging or reporting, but is there some action that they're gonna take based on this? And I think if those are spelled out a bit more clearly, then it would help us evaluate collectively, with oh, which cases make sense, and it's not just can you do it? But it's like, oh, yeah. We want to do this for these cases.

[00:52:36] **Marius Kleidl**: Yeah.

[00:52:39] **Mike Bishop**: Mike Bishop again. This time, h three editor hat on. So another case where this really would have been nice in the h three days. Everyone's favorite feature server push that I know all of you have implemented and thoroughly tested. So the server sends a push promise with a push ID, and then the data for that promised content comes on a unidirectional stream with the push ID in the header of it. But if that unidirectional stream gets reset before the client has read the push ID out of it, then it will see that push promise is never having been fulfilled. It's technically possible to leak push promises. This fixes that. So if this had existed in QUIC, we would have used it there. Because, actually, h three has the same problem that web transport does. There's metadata inside the stream data, And we just didn't have a way to fix it. And we just told clients, be careful with that. And servers, if you're gonna reset a stream, maybe you should send a cancel push frame as well just to make sure this gets cleaned up. So there is at least one case where we really would like to have this.

[00:53:59] **Martin Seemann**: Do you want me to add that to the draft?

[00:54:01] **Speaker 5**: Please. Okay.

[00:54:04] **Mark Nottingham**: And I'll I'll just get in the queue as me, but not move because I'm like Tommy. Just at a super high level, you know, I've always been slightly uncomfortable about how we talk about the the the connection level errors versus HTTP semantic errors. You know, when we went from h one to h two, we got rid of the distinction between hop by hop and end to end in in in metadata. And we said, okay. Well, the the hop by hop stuff is just the connection, you know, the this sort of stuff. We just need to be super clean about considering what belongs at what layer. Because as we know, you know, the stuff in the HTTP semantic layer is very available to applications, and it does survive end to end, whereas the connection layer stuff is tends not to be. So as long as we keep that thinking in mind, I think this is interesting stuff.

[00:54:55] **Marius Kleidl**: Thanks for the feedback.

[00:54:57] **Mark Nottingham**: So chair hat back on. Sounds like there's interest here. It sounds like maybe it needs a little more consideration by folks and a little more work. Martin, you're willing to work on a a revision of the draft? Sure. Okay. So let's continue to discuss on the list, and and we'll see

[00:55:14] **Speaker 5**: how we go. Yeah? Okay. Next

[00:55:19] **Mark Nottingham**: up, Eric Nygren talking about h t p one one request by going defense, and we've heard about this before.

[00:55:28] **Tommy Pauly**: Got the slides.

[00:55:29] **Speaker 5**: Working on it.

[00:55:31] **Mark Nottingham**: There it is. And here is the click review.

[00:55:34] **Eric Nygren**: Click review. Okay. So we talked about this some back in, I guess, Montreal. So one of the challenges that that h t p one one, implementations face is differences in interpretation when you when you have a intermediary and a, downstream or upstream from it. So, for example, if an intermediary is if a malicious client is talking to an intermediary, which is then talking to a downstream server like an origin or another, like a CDN origin or another intermediary, that there are scenarios where an attacker can either object inject additional requests or get the the intermediary in its downstream server confused on the framing as to which request is going on. And this is one where where it's kind of inherent in h t p one one and hard to avoid in implementations, and the and it's been a a continuing series of stream of of vulnerabilities in various implementations. So the idea here is to use an inbound protected signal to try and help the the intermediary and its downstream keep track of what which request they, specifically needs to be one one they think they're they're dealing with. So that if they get desynchronized and one thinks it's working on request number on the first request, and the sec another one thinks it's working on the third request, that they can go and say, ah, this is the some there's something is horribly wrong here and shut things down so that they don't leak things either forwards or backwards to the client. So as while it'd be it'll be while it'd be nice to say, that just move to h two or h three, and I would love to give that as the answer. I think we're kind of stuck with h one one being with us for a long time. So the, the initial proposal I gave back in Montreal had areas where where it required was a little complicated in terms of you needed to actually use, chiller session binding in order to implement it, which was which if you which was a a higher barrier than simple implementations we necessarily wanted to use. And I think the the one of the big pieces of feedback there was that that since this is a patch on top of h t p one one, the peep anything really, like, super complicated, the correct solution would be, say, just move to h two or h three for that for that path. So it needs to be something that is is simple enough that people could, that people could implement it within the h t h t p one one's on some of these existing h t p one one stacks. So the biggest changes since the on the zero zero version is we've defined an explicit threat model within the draft saying what is and what is not what what is and what is not covered. So specifically being clear that this isn't trying to protect the the the client intermediary hop, but it treat that as malicious. It's really for that downstream hop from there, but also providing some properties of the types of attacks it's trying to address. This also it also changes the way that the, key negotiation works and in both your ads and crypto agility, but also have allow for in band communication of a key. So rather than rely it still has the ability, if people wanted to, to use TLX exporters, But it has also the kind of minimal simple way to implement it where where the where you negotiate with something like ALPN and but then you send that the initial key in the first re request from the intermediary to the downstream with this hop by hop bound request in it header that says, here's the key to start here's the key to start with and to use for this connection, and here is the potential on the mechanism that I propose using. We also in include in here, just as an example for the the agility and also as a people were asking for a like, what is there a cheaper way we can do this than using SHA two fifty six? It proposes having, sip hash two four as a alternate hash function for the in band. I think that that's one if we do pick this up as a question of is that actually worth the complexity because in in in things that are doing hardware acceleration, it's unclear that there's a a big enough difference between CPaaS and Shaq two fifty six, but it's I think it's a topic for discussion. And then this also proposes that the a that using a separate ALPN, as much as I kind of hate it, is possibly the simplest way to without making changes to the h t p one one stack to say, this is a slight variation on h t p one one. Use use this mechanism. Just get stuck bootstrap. So I think the as we mentioned back in Montreal, it's kind of that solution here would needs needs to be something that's easy to implement, auto negotiates, kinda protects against that case where the request serial gets, gets, signaled, and it's really kind of a good enough solution. Like, this is one where it's not it's not meant to be a primary control. It's really meant to catch the cases where there's a where there's some bug or mismatch in interpretation. So I guess the question becomes, is this the problem that the working group and implementers are interested in solving?

[01:01:13] **Tommy Pauly**: Alright. Do we have any opinions, input? Thank you, Eric.

[01:01:20] **Mark Nottingham**: Benchwares. Okay. Ben?

[01:01:23] **David Schinazi**: Hi. So

[01:01:29] **Ben Schwartz**: I'll repeat something I said on the mailing list, which is I think that the key question for me is, do we believe that this is something that can be implemented on top of an unmodified HTTP 1.1 implementation? Because I can understand the value of essentially having application layer safeguards that we you can layer on top of HTTP 1.1. But if you need to modify the HTTP implementation, then I have trouble seeing the value because you if you have the ability to modify your implementation, then presumably, you have the ability to replace it, and you should use HTTP too.

[01:02:13] **Eric Nygren**: So I so the I think this would this is what I'm thinking would be the next step, would be to try to look take take a number of, h t p one one implementations and and see see how how's how much of a code change is it to implement it. I think for as the implementer of a of of an h t p one one implementation and the there's a big enough shift in in going and moving these things over to h two, and enough of the ones that are enough of these implementations do their h two as a h one, h two translation shim layer anyways, which is where some of these issues show up. So I think if we can if the if the changes to an h t t p one one implementation are small enough to get this hop by hop header to work, then I think it is worthwhile. If it ends up being that you have to make very substantial changes that aren't just, like, a few 100 lines of code, then I would agree it's not it it's not worth doing. So I think that would before I think before going too far with this and possibly before working group adoption, I think that is one of the things that I would I think it's worth experimenting with is seeing, like, is does can this be done as a small change to an implementation or is it a a big enough lift that it's not worth doing?

[01:03:30] **Ben Schwartz**: I should say that I do actually from the current draft, I do think it can be implemented on top of a standard library HTTP 1.1 that is unmodified. In particular, I note that it doesn't depend on the wire encoding of the message in any way. And so it it, as a result, can't defend against modifications to the details of how the message body is represented. Like, it it doesn't know the message length because it it seems like it's designed to be able to calculate these hashes before the content is encoded, which I think could be a reasonable trigger. I also wanted to just mention that there there may be some other cryptography that we could use here. It kinda seems like some kind of simple nonhash cryptographic Mac or maybe even some kind of just stream cipher for just indicating the counter, essentially, which message is this Mhmm. Efficient.

[01:04:41] **Eric Nygren**: Yeah. That's a good that's an interesting thought. Alright.

[01:04:46] **Tommy Pauly**: And next, we have Mark. Can can

[01:04:48] **Tommy Pauly**: you get it

[01:04:49] **Tommy Pauly**: can you get

[01:04:49] **David Schinazi**: in the queue? Yeah. Thanks.

[01:04:55] **Mark Nottingham**: Speaking only as myself, a serial proposer of of HTTP extensions that fail to get traction.

[01:05:03] **David Schinazi**: The

[01:05:04] **Mark Nottingham**: problem here is is, I think, widely acknowledged and and and serious. But, you know, from a deployment standpoint, you know, beyond the concerns that Ben has there, I I you know, this this seems like it adds overhead. It adds risk in that if you get things wrong, it breaks hard. And so it adds risk. What what do you see the deployment scenarios as? You know, how how how will this get traction so that it provides value to folks? You know, do do you think it's just gonna be built into HP implementations like Apache and so forth and so on or deployed behind CDNs with coordination with their customers? How do you see the deployment scenarios working out?

[01:05:50] **Eric Nygren**: Yes. I think the big deployment scenarios I would see are are, like, the from the CDN to a customer is is a big use case for that. And I think for that, trying to get implementations in some of the common front end kind of proxies of the the Apache NGINX, h a proxy star Envoy star reverse proxies is where where I think the big value would be. I think there's also enough kind of modern deployments today where which are implemented as a front layer proxy, like one of like, h a proxy or Envoy NGINX in front of some, h t p one one API service that's oftentimes implemented in, like, some Python or JavaScript library, but that's a big layer for that, that if we could get the the libraries to implement in the proxies to implement that, that that could defend across stuff across that path. Especially because I think in all of those cases, there's the the big risk is that most many of those patterns do have an h t p one one hop in them today in practice, and many of them are also multiplexing requests by different clients, like legitimate clients and malicious clients over the same downstream connection. And while I suggested last time, would be nice to say, just don't use one use, like don't use pecans there. That ends up not being realistic performance wise or in terms of what

[01:07:16] **David Schinazi**: people are willing to deploy. But

[01:07:19] **Mark Nottingham**: it it really does depend on whether that software at the other end is gonna modify, it sounds like.

[01:07:23] **Eric Nygren**: Yeah. So I think an important like, it's not worth doing unless there's a unless there's at least there's some critical mass of implementers there, which I think depends who are interested, which then depends upon the the level of complexity being being an overhead from it being low low enough to justify it.

[01:07:40] **Speaker 5**: K.

[01:07:43] **Dennis Jackson**: Dennis, so I see in the draft, you referenced an academic paper, HTTP sync, which looks like it has a slightly different design. It looks like, yeah, I guess, stripped it down to be more deployable. Could you say more about the relationship between the two?

[01:07:58] **Eric Nygren**: The the one that's in the academic paper didn't have any cryptographic defenses in it, and it's it the it was but in they inspired actually, they they were, simultaneously convergent evolution where the person who wrote that academic paper works, works at the same company as I do. I knew that he was interested in this class of topic because he's been he has been kind of involved in responding as as these sorts of issues come up. So when I had my draft ready, I shared it with him, and he was like, oh, yeah. Here's this paper that has something similar. So there there is

[01:08:34] **Tommy Pauly**: Okay.

[01:08:35] **Eric Nygren**: It's it is they they are have similar lineage or inspiration from this being a problem, which which we're we've both been interested in solving.

[01:08:43] **Dennis Jackson**: Okay. Thanks. It looks to my eye like, you know, the the attacks that these two designs will defend against is is distinct and different and would probably be worth characterizing a bit more. Like, in the paper, for example, they they looked through some recent CVs to be able to say conclusively what have fixed, what not have fixed. And I think seeing that for this work would be a really powerful, like, this is gonna be effective for the complexity it introduces or it isn't.

[01:09:07] **Eric Nygren**: No. I think that's definitely worth worth doing because it's not it's not worth it unless it can't address enough of their CVs that have been seen. Sure.

[01:09:15] **David Schinazi**: David Skenazi shoving weird crypto of TLX exporters into HTTP ex enthusiast. So, yeah, take a look at HTTP concealed off. It does some of this magic. So with my other hat on, I sometimes work on the Envoy open source proxy. With the AI bug apocalypse these days, request smuggling attacks have been a sizable portion of what we're seeing. So having work in this space is something I really support. I think this seems right. I think I absolutely agree with you that, from my personal experience with this, TLS export authenticators make people's head hurt. So something simpler having the option for something simpler is a good idea. And, honestly, sip hash, I think, is enough. And, you know, having a shot to 56 there as well, if that scares you, is great. The one so I for first and main point, I support this work. I think we should look into this. And the second point I'll make is I'd recommend having a response to the first request to your in it message, to make sure that the other side kinda supports it, and you could have it, you know, maybe, like, hash that and send you a hash of it so it's not just an echo and it does some work. It'll help you then, you know, if it doesn't support it, you don't add things on on later requests. I know that doesn't break stuff if you do without it, but overall, supportive of this. I'd like to see it progress.

[01:10:56] **Eric Nygren**: Yeah. I think one note on that is the there's a bits of that in the the risk the the first bound request response, but the the the you do need to do the negotiation ahead of the in it to at least say we support this general scheme because, otherwise, if you don't use something like ALPN or some or one of the the various TLS extensions we've proposed for negotiating flags to get a say, yes. I do this, then those are risks that a attacker can can go and starts can send the in it, you know, directly and in ways to cause or or smuggle it through smuggle it through some previous one in a way that causes problems.

[01:11:40] **Chris Lemmons**: Yeah. Chris Lemans, Comcast. I want this to exist, and I want it to have been deployed. Figuring out how we get from here to there, I think, is hard. Two hurdles. Yep. Mhmm. So so seconding a lot of what Mark Nottingham said around deployment and some of what he may have just implied around some of the challenges there. I do think that the story that you're telling around figuring out how to make this so that it's simple to add to existing libraries so that as a security professional, I can tell people, oh, just patch your NGINX. Just patch your ATS. Just patch your, your Go library, and don't turn off the flag that says disable this. Mhmm. And and and if we can start building that, then we can create an ecosystem that as people start building and upgrading and whatnot, they we wind up in a more secure place because I am seeing a massive amount of request bundling attacks all all across.

[01:13:04] **Tommy Pauly**: Yeah. Speaking. So I had been working for a smuggling problem in twenty years ago. And, yeah, and I hope if I had this solution in twenty years ago. But in currently so the many implementers are just using libraries as a and not implement the HTTP by hand by every person. So in this case, there should be a HTTP two is almost is no cost. So, of course, if we have already a supporter, big supporter for this proposal, it may be a good solution. But if we are just letting asking someone to implement from this time, maybe moving to the HTTP two is a definitely a secure solution, more reliable solution for that.

[01:14:00] **Mark Nottingham**: Okay. So it sounds like there's strong interest in this area and certainly in solving the problems. It also sounds like, you know, people are concerned about, you know, whether whether we can be successful, but but that hasn't stopped us trying before. I I'd I'd say, Eric, certainly continue working on this. It sounds like you have a little bit more that you want to do. So I'd say continue bringing it back to us. We'll discuss, but I can I can see a call for adoption at some point in the future if if you you continue to?

[01:14:33] **Tommy Pauly**: Yeah. No. I I I agree. I mean, it's it certainly seems like we have a lot of energy here. I guess I'd be curious to hear if there's anyone in the room today from the working group that would like to see certain properties addressed or considered before you'd be supportive of adoption. You know, certainly, it's the type of thing where we can adopt it and essentially adopt the problem space, and, obviously, the working group can change all the things in it. But if you already have in mind, like, oh, I I really wanna see blah blah blah blah blah blah, the deployment plan or some properties that would help you be more supportive of adopting the work, you know, please step up or add a comment to the list. But otherwise, I think we'll just keep iterating and then see what the right time is.

[01:15:28] **Eric Nygren**: Yeah. And especially if there if there are implementers who would be interested in being coauthors, I would love to have someone else join.

[01:15:34] **Mark Nottingham**: Right. And and I think that really does come down to it is it's it's of course, CDMs could implement this, and and I think there's some interest there. But it's really the the software on the other end that that's critical here. And so I don't think we have representation from those implementations in the room today, but we do know those folks, and we can have chats with them, see how that goes.

[01:15:55] **Speaker 5**: Thanks. Alright.

[01:15:56] **Mark Nottingham**: Thank you very much, Eric. Next up, David has two drafts to present. Correct?

[01:16:13] **David Schinazi**: I only have forty five minutes.

[01:16:17] **Mark Nottingham**: Yeah. Sorry. Sorry.

[01:16:23] **Speaker 5**: Oh.

[01:16:26] **Mark Nottingham**: Johnny said He's going wedding singer on this one. Yeah.

[01:16:33] **David Schinazi**: Hello, everyone. David Skenazi, a previous HTTP enthusiast for this presentation. Oh, good. I see Martin in the back. Great. Alright. So I'm gonna talk about Oblivious HTTP here. So can you transfer control of the clip?

[01:16:50] **Tommy Pauly**: Oh, sorry.

[01:16:52] **Speaker 5**: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. There we go.

[01:16:58] **Mark Nottingham**: Thank

[01:17:02] **David Schinazi**: you. So why do I care? My team at Google has been working on oblivious HTTP for the last six plus months, and we've deployed an HTTP gateway at scale that is currently handling about 500,000 requests per second at scale. It covers all of Google safe browsing for Chrome, for Android, and we're in the in the process of onboarding other browsers. It works. But as part of doing that, we've learned a few things. Why am I here here? OHTTp was developed in the OHAAI Working Group. Some of you might remember the meme. Thanks, Barnes. Though OHAAI Working Group has been closed because it finished all its work items, and it the responsibility for maintaining that is now here. So even if you if you don't care about oblivious HTTP, feel free to completely zone out. So I have two drafts. The first one that we kinda realized from from looking at from where we're deploying a Bladex HTTP is about perfect forward secure security or yeah. So get ready. I may I had too much time on my hands to make slides, so I apologize. So OHTTP initially was a very simple request response where you could only send one request that was fully formed in one encrypted blob and same for the response. And that didn't have perfect for its secrecy. Wow. Thank you. It's Friday. I'm tired. It's like, that didn't sound right. And especially for some use cases, that's totally fine. So for Google safe browsing, conceptually, you say, hey. Is this URL malware? Yes or no. At the end of the day, the response has no more privacy properties in the request, and so that's fine. But then Tommy got really excited. By the way, I didn't ask AI to add the kid to this image, but it did, and I thought that was hilarious. I just wanted a second train. It didn't add a second set of train tracks, so this is a little bit and the idea with chunk to HTTP is that now you can send your request in multiple chunks that are encrypted one at a time and same for the response. The downside of that is it also didn't have perfect forward secrecy. And for some use cases, that's fine. If your request is if you're using it to just send a simple request and your response just depends only on that request and will not change over time, it has the same security and privacy properties. It doesn't matter. But the problem is then with the second you give an abstraction that has a bidirectional byte stream to people, they're like, oh, that's great. Let me put my favorite RPC protocol over this. And then people are now interested at hacking this because the data is more valuable. And the child is sad. So what do we do about it? We make the train more secure. And the answer is crypto, not Cryptozoology. And so this is what this draft is about. What can we what is the minimal set of changes we can make to, I believe, let's say, GDP to give you these secrecy properties? There's a reason you put me at the end of the agenda. Alright. So a quick quick primer on how the cryptography for oblivious HTTP works. It uses HPK with the it's a hybrid encryption using asymmetric cryptography and symmetric cryptography. But at a high level, the gateway has a public private key pair, and it publishes its public key. And then for each request, the client does magic. I'm not gonna get into the actual crypto details, but it uses the server the gateway's public key to encrypt the request. The gateway uses some entropy for the response, and then they're both kind of encrypted using a shared secret that came out of that. Let's make the crypto more fancy. So same original concept, the gateway still has a public key that it publishes. I know you're into watches, Mark. And the client still encrypts this request the same way, but as part of doing that, it also generates an ephemeral private public key pair, and it sends that along to the gateway along with the request. And then the gateway does pretty much a the a very similar operation with hybrid public key encryption in the other direction to now and and and it kinda binds the two together using crypto magic, shoving things into info context and all that. And now you have a a secret that was ephemeral on both sides that was used for this. And so even if the gateway public key that is longer lasting gets leaked, there's no post compromise. You do get the perfect forward secrecy. If you're using the chunked extension of oblivious HTTP, there's a mechanism by which once the client gets this new set of secrets, it kinda shifts over to the new one and goes on. So the property you get the first flight of the client is still not perfect for it's secure, and that's a property we have with any system that has your that doesn't require round trip. So that's the same as TLSU RTT, and we wanna maintain that for performance for Bluetooth HTTP. But then everything after that, the entire response and anything the client sends after it's received the first response is perfect for its secure. So there are some open questions. Thanks, Martin, for the review. I promise I only have one AI generated bike shed this time. I learned my lesson. But plenty of things to figure out there if we decide to do it. Like, how do we actually bind the two cryptographic context? The entropy that was in the original one that I removed because I think we don't need it. Is that really true? And one, at a more HTTP level, do we want this to be backwards compatible such that the server can decide to use it or not, or do we want this to be kinda completely separate to force it? And I'm sure there's plenty more. So wrapping it all together, do we think this is useful? Would you like to work on this? Is it worth it building this? Because what I'm seeing inside Google is people using chunk to wanting to use chunk to HTTP for what it wasn't intended for, and I'm worried that not having PFS is gonna cause problems. So I like to have this. So the beautiful bidirectional stream abstraction doesn't have the foot gun that they don't know exists. Questions?

[01:25:04] **Ben Schwartz**: So

[01:25:05] **Dennis Jackson**: I think my first concern, this doesn't provide PFS for that first request. Right? Nothing changes about the first request.

[01:25:11] **David Schinazi**: That's exactly right.

[01:25:12] **Dennis Jackson**: Isn't that the request I really care about?

[01:25:16] **David Schinazi**: Probably. It it it really depends. For a lot of, like, bidirectional RPCs and usage of, like, bidirectional streaming gRPC, the first request and response are kinda setting up the channel and agreeing to what you're gonna talk about. And potentially some authentication material and some some other fun things. The

[01:25:35] **Dennis Jackson**: other thing is that if you if you don't do any of this, but you rotate your configuration more frequently, you will get a form of forward secrecy.

[01:25:43] **David Schinazi**: Mhmm. So the big yeah. Yes. You will. The the issue there is the because it's not just a single gateway. We're talking about a fleet of gateways because the when the client fetches this public key or the or HTTP key config and then goes to use it, it might hit a different region or things like that. Those keys need to be propagated quite a bit, and so they have way more propensity to or opportunities to leak, whereas something ephemeral that was really just between these two entities in there. I So think there is a measurable security increase because of that.

[01:26:21] **Dennis Jackson**: I I think it's just a little incongruous to sort of say, we really, really need zero RTT because it's important for our use case, but we don't need PFS for it. It's an it's an awkward mismatch in in what you're sort of demanding from the protocol.

[01:26:35] **David Schinazi**: So I I I think that's right. We we had a discussion, actually, and I forgot to mention this, for when the Oi OiHTTpbis-one 150 extension, I mentioned this and then said, like, hey. If you're doing bidirectional, just use TLS on top of connect. That gets you all of those properties and more. And the answer was we absolutely need zero RTT, and we can't use TLS with zero RTT because that allows linkability across requests. So that I took that as a kind of design requirements because that seems to be what everyone using HTTP really wants. Because if they didn't need that, they would just be using TLS over connect.

[01:27:18] **Dennis Jackson**: I see the queue, so I'm gonna get out of the line. But very quickly, we could easily define unlinkable zero RTT for TLS. It would not be hard if that's what you need. And then separately, like, if we're gonna do this HBK combination thing, it needs some really careful analysis because it's gonna be it's gonna have an important use case, and other people are definitely gonna copy this homework. Yeah.

[01:27:38] **David Schinazi**: Oh, absolute I we would not do this without, like, when we did other magic crypto and HTTP, we got a full, like, security proof of it and quite quite a lot of analysis. We would actually not publish this without that. So totally agree with you. I wanna pick your brain about the doing it in TLS because I've talked to a bunch of people about that, and I highly doubt that that's easy even if we forget the fact that doing anything in TLS is hard these days, just from a cryptographic perspective, I think that's hard. So let's let's chat more. Kazuha?

[01:28:14] **Kazuha Oku**: Kazuha, firstly, so I really appreciate this work. As somebody working in the company for which already provides chunked HTTP gateways. It's hard to explain these issues to our customers. And you know? So I I really appreciate this work. I hope that p IPFS would be apply at least 41 RTN following because it provides us more security.

[01:29:48] **Martin Thomson**: And the fact that, well, you know, we built something then that could enable bidirectional communication was almost an unfortunate sort of downside of that that thing. But if people are starting to use this for this and they don't wanna go to TLS, I think I might prefer fixing TLS and and finding a a nonlinkable profile of of zero ICT and TLS than than take this path. Seems to me like

[01:30:19] **Tommy Pauly**: we

[01:30:20] **Martin Thomson**: if we can if we can educate the applications about the use of the the sort of non PFS first flight, then we can educate them and and say, look. There's connect, And that might be a better outcome for everyone involved.

[01:30:36] **David Schinazi**: So on that, I think one bit I've heard from some CDN vendors at least that deploy HTTP gateways, they find that easier to deploy than connect. I don't know exactly why. I think that's true for regular HTTP. For chunked, I think that kinda goes out the window because you're just spelling it a different way. But part of it is, oh, the people doing connect are off on this side of the company and the ones that are over here, which, you know, is the reality we live in. But if we're gonna talk about the TLS thing just for thirty seconds, Google crypt Google Quick crypto had nonlinkable zero RTT. But for that to work, you needed a way to actually bind your HPK key or to transmit that securely and to kind of so what Google Quick did was to bind it into the certificate and do we have these bundles that went through. If what we're saying here is that we just need to slightly modify the TLS certificates and TLS, then that's gonna be hard. So let's I'm happy to chat about that because if there's a if there if that's easy, then I agree. I just can't see it.

[01:31:55] **Martin Thomson**: So once we understand the use cases a little better, then it it will be easier to make a decision here. That's all.

[01:32:02] **David Schinazi**: Yeah. I mean, I think the use cases are pretty simple. It's folks who have a back bidirectional stream and wanna put it over something that hides the IP address. And the reality of it is, at Google, we had this cool deployment of Mask, but the whole feature got canceled. So we don't have those anymore. Now we have this cool deployment of and we have people asking for this. And they're either a, please give us something like yesterday or we'll just ship without this privacy thing, and it'll be everything will be worse. Anyway, Jonathan.

[01:32:37] **Jonathan Hoyland**: Jonathan, no advantageous. If you're doing interactive chunked messages, then aren't you already in quite a bad place security wise? Mhmm. Like, you lose a lot of the obliviousness properties. So why, yeah, why why are we spending time on PFS if we've already lost other guarantees already? I think and correct me if

[01:33:05] **David Schinazi**: I'm wrong. The if you're doing, like, direct request response, the only thing you're leaking is the latency between the relay and the client, and that is nowhere near as bad of a privacy problem than leaking the client IP address.

[01:33:20] **Jonathan Hoyland**: So I was just looking at the chunk to HTTP thing, and it's was talking about interactive there's a, like, a section security considerations about interactivity. And it's I I see if I remember correctly, the attack is the gateway can no. Somebody who can see both sides of the connection can start identifying which packets are related to which customers and which requests. And so yeah. We're we're sort of going down the road that's already bad, is my point.

[01:33:55] **Tommy Pauly**: Well, threat

[01:33:57] **David Schinazi**: it's often a question of threat model. The main reason at Google we're deploying these is the threat is Google in that we don't want like, take for Google safe browsing, we want to offer this to all browsers for free with a clear guarantee that we have no access to the IP address. And so the threat is the the gateway, not a nation state attacker that could see both sides. Like, the nation states aren't trying to correlate things to sell you better ads generally.

[01:34:28] **Jonathan Hoyland**: You really hope not anyway.

[01:34:31] **Mark Nottingham**: Give me some time.

[01:34:32] **David Schinazi**: Yeah. Ben. Hi.

[01:34:40] **Ben Schwartz**: Ben Schwartz, Meta. I'm very skeptical of of this for mostly for the reasons that Dennis said. I think that the idea of offering a primitive that, is somehow, forward secret partially some of the time. But, you know, depending on exactly how you used it, like, depending on exactly where your chunk boundaries fall, I think seems like a a very difficult primitive to use correctly. Just to quickly respond to that, this is the

[01:35:17] **David Schinazi**: ex in in this aspect, that is the same primitive as TLS 1.3 with zero RTT.

[01:35:23] **Ben Schwartz**: So I'm not I'm not entirely convinced that that's true. The yes. There is a there is a forward secrecy question with, with zero RTT, but, but that the scope and rotation frequency of the keys that we're talking about, I'm not sure that they're directly comparable. You know, every every user is potentially doing zero RTT under a different key in TLS 1.3.

[01:36:00] **David Schinazi**: That's true.

[01:36:00] **Ben Schwartz**: So But

[01:36:02] **David Schinazi**: I think if we go to unlinkable zero RTT, we're gonna re we're gonna have that same problem where the ZeroTT is gonna have that as well.

[01:36:12] **Ben Schwartz**: So and, like, in general, I think, also, like Jonathan, I was I've been pretty I've been pretty concerned about chunked OHTTP in general, as a privacy primitive. Again, it it seems like much weaker than the original of HTTP. That said, my employer actually has, like, a very clear and high priority use case that almost matches what you're building here. And so I I think that it would be very interesting to compare this, and that is, WhatsApp private processing. So we've published a white paper on this. And, essentially, what it is doing right now is is compute enclave a tested TLS, r a TLS, over chunked OHTTP. So using chunked OHTTP as a bidirectional byte stream running TLS inside it effectively partly to try to get the the same privacy property that you're trying to build here. So in a sense, we've we've achieved that privacy property in production, but at some cost. It seems to me like there's gotta be a better way to do this. I'm not convinced that that the way this is backed out here is the right answer to that, but it's clear that there's some kind of recurring problem here across multiple companies, and,

[01:37:36] **David Schinazi**: I would love to see a cleaner solution. Thanks. Can I ask you to put a link to that white paper either in the chat, or I would love to read it?

[01:37:46] **Christopher Wood**: Thanks. Chris? Chris would yeah. Thanks for writing this up. I think this is useful on the point of you know, should we do this in HTTP or in TLS? I think it's a, like, a trivial, air quotes, trivial enhancement to what chunk chunked OHTTP provides. I do think we have the capabilities of doing the analysis either in this room or perhaps with people that we know well to do that. So I'm not at all worried about that. Could we do it in TLS? Perhaps. But we're also going to face exactly the same hard problems that we've already somewhat tackled with OHTTP. And changing TLS at this point is kinda difficult. It's much, much easier to ship an OHTTP solution in production that like, vastly simpler. And frankly, like, doing new things in TLS these days is kinda scary for other reasons, so I I would be discouraged from doing that. And I would like to explore this route whether or not it shakes out exactly as you've written up or perhaps with some alterations, maybe as Ben's suggesting. But, like, this obviously feels like a useful improvement. Feels like there's a problem solved here. So, yes, I think we should do. Thanks.

[01:38:57] **David Schinazi**: Mike?

[01:38:59] **Mike Bishop**: Mike Bishop, this time with hat on. As the AD who closed to OHAI, perhaps prematurely, although I don't think we didn't know don't think we knew that at the time. I I really get the caution about taking stuff to TLS and about the time it would take to deploy that. At the same time, there is definitely a reason that OHAI was in the sec area and not the WIT area because we're touching very, very cautiously on security primitives here. If we do this work in this group, I want very thorough review from the security directorate and formal proofs. Like yeah. I absolutely. More rigor than we usually do for SGP stuff.

[01:39:48] **Mark Nottingham**: I I would say not review. I would say continuous engagement.

[01:39:51] **Ben Schwartz**: Yes. Yeah.

[01:39:52] **Speaker 5**: Yeah.

[01:39:52] **David Schinazi**: And and for what it's worth, that's what we did when we published the concealed off RFC in this working group. We did exactly that. Right.

[01:40:01] **Mike Bishop**: So this is not a no. This is a be very careful.

[01:40:05] **David Schinazi**: Oh, absolutely. No. Thank you. Dennis? Back again.

[01:40:13] **Dennis Jackson**: Yeah. For the TLS serial RTT thing, I think that there'd be wider use cases for that in browsers that we would also be interested in. Like, you know, it would be nice to have just one transport protocol that that does the right things rather than doing TLS in your situation, then doing another full key exchange. Like, it's it's vastly more expensive. I still I'm sympathetic to both the dysfunction in that working group and the flexibility of HTTP stacks. I don't think that's, a happy world in which we just start slowly reimplementing TLS one layer up.

[01:40:48] **David Schinazi**: And I I see what you're saying. I think we unfortunately barreled down that path already when we built to live as HTTP. And, like, right now, I think my options are shipping to like, I have shipped chunk to HTTP, and I won't get those people to switch to TLS, like and not to mention getting any changes in our TLS stack at Google is complicated because, like, the team is not huge and all that. Anyway, so, you know, I hear you. Let let let's chat more about I I wanna get a better picture of what looks like, the change in TLS, and see if that's viable. I I think there's many roadblocks, some of them technical, some of them political. Tommy.

[01:41:36] **Tommy Pauly**: I'm wearing no hats as you can see. So overall, I I do think that, like, coming back to the context that Martin was giving for chunked, as that document says, like, it really should be about making the delivery of mainly responses, but also requests incremental, but shouldn't fundamentally change what's going on there. That is how it should work. And for those cases and the ones we talked about when we did adopt and do that work, we have use cases that, like, really, really want that to be zero RTT and fully unlinkable. Like, there's a lot of motivation there for those properties, and they just needed the incremental delivery bit. I guess it'd be good to understand more for, like, the bidirectional interactive stream. Like, how much do they really, really need that zero r t t beginning? Can I understand that there may be practical reasons that connect is trickier because of CDN setups? But,

[01:42:52] **Mark Nottingham**: like, what

[01:42:53] **Tommy Pauly**: are the actual technical problems? Like, if we did that, how much are those particular round trips that important, or can they be mitigated? Because then you do have a back and forth stream. You're not kinda limited to this one request response. So, like, just from some experience here, we have cases where we are doing, you know, multi turn LLM interactions with OHTTp, but those are separate chunked OHP requests. Right? So there's still the property of you have a request and you have a response. And then you can do another request response, and those are unlinkable at the OHP level. But, you know, you you can send other identifiers within the body to say, I'm resuming this session. You can send more background. So you can potentially design an overall system that has some back and forth, but at this layer is still kind of atomic request response pairs. So, like, to what degree are is that an option, or are some of these people really wanting Connect? And I'll just point out, like, in the chat, Chris, you were mentioning that, like, we can do both. Like, you you can have OHTTP, and you can also do things to make an unlinkable CRTT and TLS, and, like, that that's good too.

[01:44:15] **David Schinazi**: I mean, the more, like, tools we have in our toolbox. To I also wanted to respond to an earlier point. This works just as well for regular HTTP without the chunked. And so it doesn't give you PFS for the request, but it gives you PFS for the response. And I think there are cases where that matters because, yes, your request might have an auth token, but, like, those are bound in time. So it's pretty common that, like, have a request with an auth token, and your response is privacy sensitive. But if the key leaks a day later, you've your auth token is no longer valid for anything, so the response has much more privacy sensitive data than the requested. So I think there's uses there as well. Okay. I think the should I move on to the

[01:45:06] **Christopher Wood**: next draft?

[01:45:06] **Mark Nottingham**: Not quite yet. So chair head on, I'm hearing a level of interest in this. I'm also hearing certainly a level of concern. A lot of those concerns seem to center around the use cases and having them well described and also how it relates to other parts of the ecosystem and and and also our intent for what OHTTP is for. You used the tools and a toolbox analogy there. I think that's quite apt. Tools are designed for a purpose. They're designed for a specific purpose. We wanna make sure we understand what tools we need in our toolbox. So it sounds like the discussion needs to continue. No doubt. We'll we'll have you up here again.

[01:45:44] **Speaker 5**: Oh, well, great.

[01:45:47] **David Schinazi**: I'll get more tokens to generate more slides.

[01:45:50] **Mark Nottingham**: Do we need a content warning on the next presentation?

[01:45:53] **David Schinazi**: Actually, I had less time after I spent all on this. The other one is not quite as polished on the AI slides front. Then proceed. So I had to, you know, copy images directly from the Internet without AI, at least in this case. So completely different draft, still motivated similarly by the fact that we deployed our HTTP at scale, and we realized that not everything was perfect. So still got some AI slides, so don't worry. This is about the key configuration format for oblivious HTTP. So for for those of you that are familiar, we discussed about earlier the OHTTP gateway maintains a private public key pair that it rotates commonly once a week, and that needs to be sent to clients. So the ability to say GPRFC defined a key configuration format that tells you this is the chem, the key encapsulation mechanism we're using. This is the key derivation function that we're using. This is the a d AAD. I feel like this clicker does not work well. So why do we need a new one of these? We already have this config format. It's in the RFC. It turns out it's not quite as perfect as we thought it was.

[01:47:19] **Mark Nottingham**: Yeah.

[01:47:21] **David Schinazi**: It has some issues, and it it is fraught to cross that bridge. So one of the ones that I found that was really exciting and took me a while to debug and do some archaeology on the spec is that after working group last call, a change was made to this format, and the authors fully realized that it was not backwards compatible. And it was a good change. Don't get me wrong. It allows you to put multiple different cams inside your key configuration format to send your to clients. And that's really important if we wanna do post quantum but it's HTTP. It allows you to send, like, an x two five five one nine. So for the clients that don't support post quantum and then Xwing for those that do or whatever your favorite chem is. Reasonable change, but not backwards compatible, and the content type for this didn't change. So now the content type is kind of busted because some servers think that, well, we do what's in the RC, obviously, And I might be responsible for 4,000,000,000 devices on the planet that can't parse that format because no one noticed this change before like, they had shipped already, and this change wasn't noticed. Whoops. So another aspect that I think can be improved with the key configuration format, and my apologies, I did not have time to make an AI picture for this slide, is that so like we mentioned, the keys rotate. And the so let's say most server most gateways pick a key rotation schedule of once a week. But the guidance on that, both on the gateway side and especially on the client side is, I don't

[01:49:23] **Speaker 5**: know,

[01:49:23] **David Schinazi**: it's really completely unspecified. And so your client has no way of knowing that you rotate every seven days or every year or every hour. And so every client does something different and exciting. Chrome, for example, will just declared I if I receive a key, I will declare completely expired after three days because three is a cool number. Another client, the Android one said, I don't know. The RFC didn't say anything about expiration. The keys last forever, and we will just use them. And if the gateway doesn't have the private key anymore, it'll send me a four twenty two, and then I'll retry. That's not great. If the key leaked in the meantime, you've just sent your request with a compromised encrypted with a compromised key. And we've also seen that as a reliability issue for Chrome because we don't fetch these keys for every single time we do an HTTP request. We fetch them once in a while in the background, except your your smartphone isn't connected to the Internet twenty four seven, and your background refresh could land at a point where you don't have connectivity. And if you get multiple of these in a row, you can end up at a point where, oh, I haven't been able to reach the key server in three days, and I've now declared this key expired even if the key is still totally valid. Got it. So to explain this a bit better, let's say all of these blocks are kinda one week long. What we have to do because of this on the server is we keep the keys. Blue is when we kinda publish the keys, like, during that entire week. If you ask our gateway, hey. What what are your keys? We publish it. And then the next week, we don't publish that key anymore, but we keep the last two that that key valid for two more weeks. But if you look at here, the vertical red arrows will tell you if you come at this time to fetch the keys, the amount of time you'll have to use them can vary. If you are on the left edge of a blue line, you have almost three weeks to use it. If you're on the right edge, you almost have two weeks, but you don't even know that anyway because, like, our server policy is to double it, but some some gateways might do other things. So the solution to that is if we're tweaking the key configuration format, let's add a not before in an expiration to them. Jots do this. Private access tokens, keys do this. And we kinda noticed this because we were deploying those things as well. And it makes life a lot easier on the clients when you get the keys and you know, great. I can use it from this day to this day. And you can do something even better is you can publish them in advance and it's like, here is a key that will be valid for next week. Here's the key for the week after, and that gives you the nice property where anytime as long as you, once every few weeks, manage to get some information from from your gateway, you always know what keys to use and whether it'll be valid, and you can also shrink how long you keep the keys the key valid on the gateway instead of having to keep it a long time for those clients that are delayed. So bringing it all together, we take the config. We change the content type. Pretty straightforward. And then we keep overall the same key config format. This is the one from the oblivious HTTP RC where it has a length per config that allows you to put multiple configs back to back. The chem identifier tells you the length of the public key, and then the symmetric algorithm lengths tells you how, like, the how much room is spent by these symmetric algorithms after. The nice thing is there's a gap there at the bottom. Tada. We just put extensions in the gap. Brand new thing. I should patent it. And I forgot to put a conclusion slide. That's it. That's all I'm proposing. Small tweak to the format with a new content type and the ability to have extensions.

[01:53:48] **Mark Nottingham**: Okay. So any questions, comments? We need to keep it brief because we're getting towards time. Maybe people need to soak it in a bit more. Maybe it's the lack of AI generated slides.

[01:54:07] **David Schinazi**: I maybe if I say cryptos these times.

[01:54:11] **Mike Bishop**: Mike Bishop, mostly not head on. This seems fine. I do notice slight contradiction between I have a client bug and as long as we're changing the format anyway, you have a client bug. You can fix that. If this is something that we wanna do, let's justify it on that basis, not on the basis of those clients don't implement what's in the RFC.

[01:54:43] **Speaker 5**: No.

[01:54:43] **David Schinazi**: Absolutely. It's we're fixing it, but at the same time, if we're fixing it, I need a way to tell the clients you know, to to distinguish those. Yes, I can put on a different URL.

[01:54:55] **Mike Bishop**: But So as long as you're updating the clients, you could add more features at the same time?

[01:55:00] **David Schinazi**: Yeah. Yeah. Okay.

[01:55:00] **Ben Schwartz**: The the the of the argument I thought you were making.

[01:55:03] **David Schinazi**: No. Yeah. Yeah. Yeah. Okay.

[01:55:08] **Mark Nottingham**: So it doesn't seem like we have any other feedback. I think maybe people need to go and read and think about it.

[01:55:13] **Tommy Pauly**: There's discussion on the chat.

[01:55:14] **Mark Nottingham**: There is discussion on the chat. That's great. I I guess from a chair perspective, we need to have a discussion with our area director and perhaps loop in some of the security area folks. Sounds like both of these need more discussion, and we need to start talking about venue. I I think that's all we'll say for now.

[01:55:33] **Speaker 5**: Yep. Yeah.

[01:55:34] **Mark Nottingham**: Thank you very much. Thank you. That's all we have on the agenda. I wanted to mention one of the things since we have a moment. As you might know, we have an HTTP directorate. It reviews documents for other working groups and other folks who are using HTTP as a protocol. If if you're interested in helping out with that, of course, come talk to me. I'm the chair of that directorate. But we also have we've started to just think about using AI a little bit to assist in that, and we have taken BCP 56, which is using building protocols with HTTP and our editorial guidelines, and and we're starting to use that with some interesting results. If you wanna help out with that, it's it's an interesting tool to use. So come and talk to me. Any other business? Okay. Enjoy the rest of your Friday, and we'll see some of you in San Francisco possibly. Thank you. Thank you very much.

[01:56:42] **Eric Nygren**: Yeah. Alright.

[01:56:44] **Ben Schwartz**: Thank you.

[01:56:46] **Mark Nottingham**: And thank you again, Lisa.