Session Date/Time: 03 Nov 2025 22:00
[{"startTime":"00:00:01","text":"I get it. Sorry Don't get that fixed Oh, no Oh, no All right, it is time to get started Welcome to the TLS Working Group session There are two sessions, one today and one on Wednesday Wednesday. All right, get everything ready to go This is the new IETF Notewell. They would like us to linger on this and read this little quote. This is the IETF note well. It's a reminder about the policy and processing policies including about conduct, conduct, privacy, and intellectual property rights. You agree to follow and participate in the IETF Please read it carefully. You're encouraged to read this source documents to which the note refers. If you have any questions, please talk to the working group chairs, us or the area director Paul. You can scan the QR code to get a link to the documents All right, there we go Meeting tips, please make sure to use the on-site meeting tools That's how we're going to use the queue to make sure people in remote land can also get the talk. And it also makes sure that we get the right -sized room. So please make sure to log in there The next thing is the agenda. Again, we have two um i just about a little bit about the agenda is we get more requests often than we actually have time for some of topics are quite controversial think last time we were a little bit rushed we've given a little bit extra time for people to try to make sure we can come to consensus on any of the open issues So we're gonna start up with us doing a bit of a monologue about the status Then we're going to jump into the working group IDs, which hopefully some could go kind of quick, some might take some discussion then we're going to Rich follow up with some DE distinguished expert report"},{"startTime":"00:02:01","text":"and then on Wednesday we're going to do DTLS BIS update from ECHR, and then we have two two non-working group drafts which are related to ECH Any additional bashing? No, okay Put other deck. All right, we're going to talk briefly about document status All right Okay, so we've completed, well the, at least part of the appeals process has uh uh with these documents and so the ML CAM draft, the complaint was unsuccessful and the ID is still a working group adopted draft and in the situation with SLH DSA, the appeal was a success and the internet draft is not a working group either either. That's status there there um we have a bunch of documents in flight quite a few um there are two that are in IASG evaluation that deprecate obsolete key exchange and TLS 1 3PKCS1 there's some discusses that are still lingering We're working on getting those resolved, this week And we have two documents that are waiting on implementation experience experience. If anybody has any experience with these, then it would be good to know so we can start trying to move them forward uh finally uh we just uh completed a last call"},{"startTime":"00:04:03","text":"call on ECDHE, ML Chem. We did through during chair review, we found that that they're one of the sections of the document absolutes the experiments with code points that were registered for previously before the NIST standards were completed completed. The intent here would be to mark them as D in the registry, unfortunately or fortunately, this requires standards action. So we have to figure out what the path forward is here We basically have two options One is we can move the current internet draft to standards track there was a fair amount of discussion during the working group last call on this so we we have to we want to validate this with the working group basically here there are no other changes other than to mark the the experiment registered code points to D discouraged. The other option is we just pull that section out of the current document that says we're going to obsolete these experimental code points and we go and create a short document to just obsolete those experimental code points points and get that through the working group pretty quickly um there is also the possibility of an IESG action but the preference here would be to do this through a document rather than trying to go directly to the ISG So what we'd like to do is take a show of hands here as to what the working group would prefer in the room here And if anybody has any"},{"startTime":"00:06:01","text":"clarifying questions now would be a good point to ask Okay Is it? I have a yes do we just we only get yes and no options? we can't change the yes and no give it a title, I can give it a title and I can can start it okay all right then. have a question Which one is the faster? way of going about this it sounds like Option A is the faster one, but I want to confirm that that is the fastest way of dealing with this with the least amount of effort because I feel like any effort that we waste on this is based effort yeah i i option one is that we is the is the quickest way if we can come to agreement on so that's the yes the option two is the no so option one yes means we take the current document and just move it to standards track and make the change to deprecate deprecate the experimental code points points. No is we create a new document to do just that Sorry, so while people are voting, Palvard is 80, I think it's technically means we need to do another last call, right? We change the track would have to... Maybe you're one week last call, just a quick last call and it also confirms it under this anyway yeah we would confirm it on the list and we call it a last call can see. Yeah How much longer do you want to go? I think we're probably good Keeps climbing, though"},{"startTime":"00:08:03","text":"All right, let's call it good good. We have a pretty strong consensus to do number one, so we'll take that to the list Okay. Great cool That was going to take a lot longer All right Who's up next? I believe it's Stephen One second There you go There you go. Next slide slide oh nice so this is probably the only slide you need so we published draft 10 from comments we had previously and Watson gave us some good comments we think it's ready for working with basketball again the The plan was to kind of do a working group last call if that's all good then hang around up until we get somebody else to implement it which is fine there's no open issues we did move the Git repo so so I'll spin out a draft 11 that fixes the link to the old Git repo And then that's all I don't think is that to talk about I mean I think that the I think Watson beat me to the working group last call, and then he sent comments before that so that was so I think basically what you're saying is you'll spin a new version when we see a new version we'll work in group last call it Great. that would be the plan Do that the next five or ten minutes minutes. Okay. Well, that's it. There's three more slides It's your slow Update slides, one second there you go right hello everyone i'm presenting on behalf of"},{"startTime":"00:10:01","text":"co-authors of extended key update our latest iteration of the draft we have have published 07 recently, but we only published 06 before the cutoff so this presentation will be on updates that we've done on in 06 again quick reminder, what is extended key update in uh regular tls 1.3 key update you get new keys derived from the same material so it solves confidentiality limit of EAD, but doesn't give you post-compromised security Idea of extended key update that you do a fresh Diffy Hellman key exchange or whatever TLS group you negotiate and so your blast radius of potential potential compromise is compromised is reduced few updates that we've done recently so we tightened up terminology, so converge to post-compromise security. There were lots of meta kind of discussions about what is perfect forward secrecy or forward secrecy or backward secrecy. So right now the term the least controversial term seems to be post-compromised security. And there are some references that we've added to hopefully that is acceptable for everyone everyone. There is some more terminology that we need to tighten up in the document that we will be working on on. The most significant, I would say, update in this version, previously we were registered three code points in TLS message types and that's too much because it's a single byte and there is very limited number of messages we could have in the future So we followed Eckers advice and now moved to a single extended key update message with"},{"startTime":"00:12:01","text":"a single byte message subtype and there are three subtypes that we define X key update request key update response and new key update that tells that new key is now in operation we will be asking for aiana registry just maybe somebody will want to do something else with extended key update message some kind of other post handshake thing so instead of registering a new message type, they would be able to abuse or extend the use of this one And there are many more bits remaining after three bits that we have here here. Okay, then another relatively significant change is no more failures at some point, we decided that allowing both standard key update and extended key update is potential recipe for disaster, because you could have also of wonderful race conditions and clashes. So we suggested and it was more or accepted by the working group that if you negotiate extended key update, know longer do the regular key update um that also means that we cannot really fail so if you agreed to do extended key update, you add need to do it. You cannot no longer you cannot anymore say that, hey, change my mind, don't want to extend that key update anymore So we completely got rid of error codes The only response that you have to request for key update is, well, you have to complete the key update that doesn't mean that you have to do it immediately. If you're too busy doing something else then potentially you could delay a little bit and if requesting party got tired of waiting, well, can terminate the connection connection and similarly applies so there are no more error codes such as we try or"},{"startTime":"00:14:01","text":"I don't want to do key update that we had previously and that should significantly simplify implementations okay we have added security considerations. There is a little bit more work to be done on the security considerations so first scope of key compromise what we are protecting against and what security risks obviously are remaining post-compromise security denial of service security consideration so if you have negotiated the next expensive TLS group and you're really low-powered, you know, be careful with extended key update because potentially you can be dosed um you're if you're really not careful with doing way to free extended key update and operational guidance So you, another thing that we added that is still work in progress. Unfortunately, we couldn't finish it in time for 06 is TLSDTL estate machines machines so right now in recent versions, are updated, but still work to be done. I encourage Working Group to review those state machines and provide feedback those state machines are in appendix so they are informative still the feedback that we've got so far, they are very useful for implementers to understand what is going on and what can possibly go wrong So next steps for us something that we've already done in 07, but as far as this presentation is concerned, it's next steps align labels and key naming with TLS103, another suggestion that we had from Acker. Previously, there was no benefit of having separate HKDF labels compared to regular TLS key schedule. So we would be in the newer version, we have exact same labels as in TLS 1.3"},{"startTime":"00:16:03","text":".3. More clarification around impact on exporter APIs so exporter API is a challenging when it comes to extended key update because for some applications you want to keep this same exporter and accept the fact that you could have been compromised In other applications, you're okay with deriving new exporter after extended key update happened So implementation may want to have two separate APIs for exporters, one, that would be up to date and another that would be original one, but might be outdated now now um and uh we will be finishing non-normative state diagrams in appendices because again the feedback that we've got is they are helpful for implement implementers. We've done few prototype implementations. Hannes did one on EmbedTLS. I did one a prototype on Rust TLS. Seems to be working um we will be obviously doing more and we are looking for enthusiasts who would be interested in building and implementation and working with us on Interop to explore this further And we're obviously looking for more reviews would like to further refine these draft and get it finally on the path to working group last call within foreseeable future Any questions? suggestions concerns Yes, Muhammad Usama Sardar Thanks for the updates I provided on the overview. One question I have still outstanding is"},{"startTime":"00:18:01","text":"how would it be possible for an attacker to compromise the application keys and not the long-term keys? The answer that was given to me was that the long-term key is protected via trusted execution environment and I'm struggling to see why would you not protect the application keys also in the same trusted execution environment. Like, why would you, uh, the application keys not protected while just the long-term key being protected? I believe that's the whole motivation of this work, right? that can you clarify a little bit what do you mean by long-term keys? long-term keys with which you do so so the post-compromise or whatever you are calling is, is to say the key which is not compromised so the application so the so where do we're doing fresh key exchange right and deriving you keys for key schedule from that. Sure but meaning that it's previous when compromised like you had a memory dump that you can no longer decrypt a session that's in flight right but but would you, if one can do a memory dump, why can't it extra? out the long-term key that's my question question again and don't quite follow what long -term key you're referring to here So the server has an identity with which it is authenticated okay and the keys are the ones which are in private key private cube certificate. Yes Yes, the PQA identity. Okay, that would be a separate attack surface yeah that's not necessarily related to already established session right so if we took a memory dump and somehow server private key was also in that memory that got compromised, we did extended key update even that you possess a private key of the server that won't allow you to compromise already established session"},{"startTime":"00:20:01","text":"session but i don't think that so do you have a realistic example of how what could could compromise one but not the other i'm struggling to see a use case of that because you have a a long standing session yeah right so at the attacker managed to get a snapshot of memory. Yeah. be able to decrypt data that is being transferred in that memory okay here is my attacker has that hacker also now have somehow private key of certificate of that server Extended key update happen still have access to the private key of the server, but you can no longer extract data, clear text data from that long-term session that's already established and that's what we're trying to solve here okay maybe you can clarify in the draft because I still have trouble to follow the kind of use case to have you assume that one key is compromised but not the other that doesn't no we're not assuming that so you say in the draft that the long term key is not compromised that's what the draft doesn't say anything about long-term keys Okay, I will see the term that it used, but anyway, the issue it was mentioned that the long-term key is not okay I don't believe we're talking about certificates or identity you know draft right when i say I don't, yes sorry I think there's confusion here I'll put out. You've got the long-term credentials, which we don't talk about here And you've got the original master secret where you derive new keys from if that one is compromised then you want to make sure that you could do something so this is like a perfect 40th security by be doing it a development key exchange. So you get a whole new fresh sets of keys that generate session keys. Yep So I've opened the draft and the version 7 has 7 or 14 instances of long term or long live okay so you actually let's let's if you could open uh issue on GitHub so that we would"},{"startTime":"00:22:01","text":"again, tighten up terminology a little bit more to clarify what do we mean by long-term key that it's not certificate private key thank you In terms of us, DOS resistance have you considered setting a floor in the number of bytes exchange? before these messages can repeat in quick succession? We have actually and it seems very much implementation specific, CPU-specific, algorithm-specific We looked at how other protocols deal with that there is no consistency whatsoever whatsoever so far we decided to leave it as an exercise to their reader Just as data points again in SSH and IPSEC you can do somewhat analogous process at any point in time Protocols don't mandate you to do any kind of timer or transmit volumes of amount of bytes wire guard is more prescriptive there but but everything in WireGuard is prescriptive So let's leave that outside of IETF. All right Um, one last comment in terms of uh knowing that the session is no longer compromised after a memory dump if the memory dump is quick enough and during an idle period in communications the attacker could presumably also take over the communication channel and resume, right, on behalf of one of the other party and then you don't really know right again this this this is sort of this is not about uh recovering after a compromise This is about reducing risk reducing blast radius of a potential compromise if you know that compromises happen then yeah you probably need to switch things off and investigate instead of relying on extended key update to recover things for you"},{"startTime":"00:24:01","text":"But isn't that what post-compromised security is supposed to give you? for some parts of the problem, yes, not for others don't think post-compromise security security uh guarantees that everything is now okay because we've done extended key update depends on what attacker have stolen and what they can then do with that information all right so it sounds like we just best effort rather than you know, actual recovery right? It's reducing the scope for such things but you get no assurance assurance yes yeah yeah and this is something that we now discuss in security considerations and it seems we could do a better job there Dennis Jackson, Mozilla Yeah, thank you for updating the terminology and the the graphics. think they were great. terms of the sort of extension mechanism, that you're proposing with the IANA stuff, as I understand it, this extension is negotiated through TLS flags and it also says that if there's an unrecognized message type, the client should have bought and send an alert So those wouldn't seem to play well with an hour on a registry. So I think you would either need you know some more expression in your negotiation or maybe it probably makes more sense to not have a registry and just have some fixed message types and if somebody wants to do something like this but not this they just use a different extension extension point and then you know you don't need the overhead of the the registry registry i don't have a strong opinion there maybe yeah yeah, let's just let's, um, mean registry doesn't re-cost much and then we've run into many situations over there years when lack of registry then backfires badly well i think if you want the registry, I think you need to be a to negotiate hey, I'm going to be sending some additional messages. Are you okay with that? right at a minimum the other thing"},{"startTime":"00:26:01","text":"with the sort of threat model around PCS i think it might be worth thinking about things like um session resumption tickets and stuff and how they relate to this. Like if you do an extended key update does that mean throwing away or past session tickets? Right that's actually what i do right now in the prototype that I've built perhaps worth codifying that. Oh, and one other probably that doesn't belong to the draft text but one other unpleasant discovery that I've made when building the prototype is quite often TLS stacks split socket after the negotiation and to receive part and transmit part And if you just downloading and you're not transmitting any then you cannot complete extended key up because you do need to send data in the both directions and the library doesn't have access to the both directions then bad things happen I guess some of those problems we based in the past with renegotiation in tls1.2 but yeah, that is going to guidance, yeah Yeah, Okay we exhausted the queue. And I'll note that we've started the fat formal analysis triage process for the document. We'll be collecting initial triage responses from the team and sending it and having a point person person yeah thank you John Yeah, thank you So this is a presentation of the large record sizes for TLS with reduced overhead Didn't not have time to submit the new version in time for the submission deadline. So this was submitted"},{"startTime":"00:28:01","text":"recently Next slide slide. So there's quite few updates was some discussion at the last IETF and then also after last IETF on the mailing list and on GitHub And I think we have addressed all the issues and so we're a new version There's clarification that basically everything works the same as in RFC 8449 It was also the last night after it should be a variable length field Suggestion that it should be done as in quick then on quick on on GitHub, there was a lot of discussion and the suggestion was to do it as in MLS and to name this new type for you so that has been done it's similar to quick but it's but it has requires minimum size encoding. You cannot choose the size anymore then there's on clarification and correct regarding to AAD limits This is table is the same as in MLS. And that's basically it, we can take next slide So I think it's quite stable at this time no new issues as before there's an ongoing implementation and I think we are starting to be close to working group last but very happy to take more comments or reviews Dennis, are you in the queue? All right, so it feels like we've adopted, we got a lot of feedback last time and it got worked through in the repo. It is"},{"startTime":"00:30:01","text":"brand new, but that's why we have Working Group last call So I'm going to propose that we do a working group last call, but as usual, probably pause for implementations So if that sounds like a wave, if that doesn't sound like the way forward, let me know what you think All right, I'll go ahead and we'll get that working group last call issued as well One second We'll do that Quick update on ML Chem only registration It's just registering ML Chem 512 MO CAM 768, and EMOCam 1024. That's all it does Here it is. Here the numbers Here they are in the IANA table This is what the document says says Recommended N and nothing about MTI uh you've this Hey, I deleted all these slides sorry All right. the updates as of 05, got some nice reviews, cleaned up language aligned with ECDHML CAM on every about what to do if any of the chems fail, which is literally just, you know, let TLS do what is going to do with it. Nothing explicit about like there is a one in, you know, two to the 300 chance that this will error and everything is gone you know correctly because there's nothing to do about that So it's just whatever we're saying in the in the hybrid concrete uh document, we're saying the same thing here, and we fixed up some reps. The only open issue is an open uh request, which is asking to change it from recommended equals n to recommend it equals D for discourage this is not a what we're doing for similar hybrid"},{"startTime":"00:32:01","text":"demo camsipher suites in ECTHMOCEM would also require standards action as we discussed before and would end up grouping the brand new ML .Kam-only cipher suites with null cipher ciphers, RC4, DES export ciphers, MD5, and so on in the INA register This is the only open issue before we do maybe a working group last call I just did a quick Google This has been implemented and is merged into boring SSL. Oh OpenSSL, AWSS2N, Russells, and probably others that I did not find. So this is already out there Questions? I'll go back to the only open issue Not only is it in boring, but it's also in Chrome behind a flag for 1024 So I don't see any reason to mark it as D while later speaking as individual I was a confused where the pull request proposes to make D or to make N, sorry The pull request proposes to change the current the current document which is n, to D Okay, so then I think the last, line of the slide pretty much summer if i should not do this because these things are all broken and weak and this one is not broken by numbers of years of research so far yeah does anybody want to get up and speak to making a D? D? We're obviously going to take this to the working group last call So if anybody wants to do it later, that's fine does anyone want to say now? um i'm willing to make it D. I think it makes some sense because we do have a"},{"startTime":"00:34:01","text":"clear alternative. It is implemented openness to cell. the one who added it But off by default, is kind of aligned with D perhaps although if it then has if standards action is a problem then I'm not that strong in favor of this right If we, if we make the change from n to d it would turn it from an informational to a standards thing and yeah so yeah so Victor I didn't get the impression that you're like willing to fall on a sword on this either no uh just inclined to let it happen and somewhat in favor of it. Okay thanks okay so this to me sounds like we cancel this poll, or you close this poll request we get ready to issue working your blast Go in one going twice Okay clicker who's next? uh laura i believe yeah laura i got the right deck of it. click the clicker yes there you go You have the power Awesome Hello. First time presenting as an adopted draft, so yay Yeah, so since IETF 123, the draft is adopted we moved our repo to the TLS Working Group GitHub. please check it out if you haven't already It's mostly been me talking to me Yeah, PRs are not up for all existing issues that's a lie but most of them So goals for today are to sort of go over the open issues we've identified get working group feedback, and identify any issues that we haven't"},{"startTime":"00:36:01","text":"even touched on yet So these are the open issues we have right now. Most of them are honestly pretty small, the PRs are like a couple line changes. So I'm not going to go through all these right now, just wanted to put them all on one list I'm going to start with like the biggest probably most controversial questions and they're sort of two interrelated ones The first one is sort of like what are we willing to negotiate and are we willing to support? multi -round pakes and then the second sort of sort of separate but it'll also be like impacted by our decision on that is what we to do with the extensions Do we want a single Pake extension? or do we want to define multiple extensions for each of the PAKE algorithm? Yeah, this is the first part about which peaks we're willing to support and what we would have to do to support multi -round pakes So the two basic requirements for a pig to fit into the TLS 1.3 handshake message flow are that they, need to have two messages to derive a shared secret So one in the client hello, one in the server hello. And then the other requirement is that the key confirmation needs to be provided by the TLS finish message so if they derive the same shared secret, then you know they both knew the password or the password verifier Some pakes require more than two messages This is going to make me really popular Yeah, so would need a new handshake message which is obviously going to increase handshake time and handshake complexity complexity. So to start, I'm just going to go"},{"startTime":"00:38:01","text":"over, like this is our existing flow Spake 2+, and c pace which are the two we've like actually spec fit in this flow so they start with a peg message in the client hello peg message in the server hello They both can derive a shared secret using the peak. That goes into the key schedule then the key confirmation is sufficiently provided by the TLS finished messages since if they both drive the same like shared secret then you know that they both know the password or the password of error This also works with Oak Wake, which is a PQ symmetric peak So, to support a three message pick, we would have to basically find a way for the client to send back another fake message before a shared secret could be derived from the pake. So before the server could derive application encryption keys and send back encrypted extensions extensions. So in the slide, I showed this as, and the motivating algorithm for this is C-PACE earthquake, which is a hybrid pake, which requires that you run a classical pake and then a pq pique so they have to be run sequentially, which is what causes the extra round So this could be a new hand message could also potentially be a second client hello if we use hrrr semantics i have not thought through that approach it would probably either of these would be modifications to the handjake. And the next slide gets worse but i'm going to show it it. It's a five a five message take um So this is C -Pace Oakquake Plus, which is a hybrid augmented pake and it would require, obviously, five messages difference here being you still get a session like a shared secret"},{"startTime":"00:40:01","text":"after three messages but that doesn't prove that you know the password You have to do an explicit challenge response flow, those would need to happen later in the handshake. So Yeah, I don't need to go through the exact details. I feel like this is sort of a brief overview Bigger question sort of being, are we willing? to make modifications to the TLS handshake to support multi multi-round pake and what are what's the working groups response to that? I guess I'll start there there Effort gets in love. Your timing. No i mean let's be clear like there was like modest enthusiasm for this work It was not like, let's rewrite the world enthusiasm for this work so like if we can cram it in great. If we can't grab it in, then no Two HR Thank you David Benjamin oh, I would also, I would also have that for, like the really complicated, like, flow things like this sort of generally two ways that we could integrate something like this we could either stick it in the handshake and sort of get the one round trip time thing and all like you know have the nice like handshake than application data ordering thing, or we could do a TLS handshake, maybe anonymous or so and then after the handshake go run your funny off thing with the channel binding The benefit there is that we can do whatever ridiculous off thing we want. The downside is now you sort of need to sandwich in between the off layer and the application layer So for something like the one or two, the two message picks where they sort of fit in nicely with a handshake it sort of made sense to just go well we'll just stick it in"},{"startTime":"00:42:01","text":"there. But once we're at like five or so, like messages, like, um, think that's probably where the sort of channel binding approach is probably more natural um sort unfortunately, we kind of have this like split and you kind of have to like decide which universe you live in but that seems to be sort of the space we're in especially if we do what they J. Sophie Schmeek, Google especially if you do what David Benjamin's suggested it would be nice to also have short authentication strings mentioned somewhere instead of just pakes because they're really nice and are underutilized I don't think they fit into the TLS handshake without adding more messages easier but yeah, if you do them in the application layer, they would be really nice to actually have them written up somewhere Chris would, yeah. I'd say that the again, motivation for shoving this into TLS was basically so you could just like do TLS and then have the channel authenticated by the pig. It is super unfortunate that this complicated pig protocol has like five messages and it would require like this pretty invasive change to the handshake and so I I the desire to punt that up to the application and do it at that layer We wanted to avoid though the sort of problem that David was describing, which was like you potentially want to get your application to using something like HTTP but you want to make sure that the authentication has been done correctly before HTTP runs. So you have like this kind of shim in between TLS and the actual application protocol you want to run but we were talking about it before the session I think, like, reasonable compromise is something like you have like a kind of a custom application protocol that is specifically for like bootstrapping other long-term credentials like a like a raw public key or PSK or whatever using a peg or using a short authentication string or whatever and then you like run this application protocol and then like once you have your long-term secret like jump over to a new connection using HTTP. And that seems like it would make sense, because the"},{"startTime":"00:44:01","text":"use cases where this is relevant or this was that motivated this work was not like latency sensitive you know you know it's not like eyeballs won't be sad if they happen to do this So I think that would work That would be like, not work that's done in HGTP, work that's done in TLS, but like some new application protocol that we could probably like I don't know try to scope out or whatever is like a Boff or something next time. If that's the approach we want to go down. But especially if it accommodates things like short authentication strings in addition to pakes of any rounds like you can even like take the if you had this application protocol you could take something like spake 2 plus and do it this way and then you wouldn't be in this unfortunate situation where someone who would have to choose between the TLS approach or the the -TALS approach And so maybe that's the route we go down. But yeah i just want to say like that was the motivation for this all together Shoving in TLS was like, so you don't have to do this like custom complicated application dance but maybe we'll find out back there anyways so so Bob Hello, it's Mohebel Mahmoud. I'm relatively a new participant. So my question is on mixed deployment case like so like how this draft plan will prevent application from unintentionally degrading from the certificate-based authentication to pay only mode yeah so in case of it is it is it it is a mixed deployments deployments so you're saying like in deployments where the server is willing to negotiate either with a certificate or with a peak? Yeah, so if it is like how it is prevent like from like downgrading to the yeah so right now in the draft is you specified like if a client sends um extension and it sends"},{"startTime":"00:46:03","text":"sends signature algorithms. It assumes you're doing a PIC and a certificate You'd have to do both Okay, you Okay I will move on to the next one I feel like that was a very clear. We're not going to do this Okay, so this one again summer, or was the Q&D? Sorry, it was not, yeah Hi I'm Johnson. I was just wondering with another way of thinking about or approaching this which is very inspired by what Chris said, would be to have a way of injecting the a channel binding binding or material into the TLS handshake so you do the first two steps of your pique or three steps of your PIC, pre tLS whether in another tls connect or whatever. And then in the state into your TLS key derivation and that gets you that that sort of avoids the issue of having to extend the TLS handshade So you're saying, like, run the peak first and then use it's one now It could potentially work. I think one thing I need to talk more offline to david benjamin and uh chris uh just want to make sure we have a place where we can standardize this. lot of this has to do with like interoperability. And if you like the, it's a weird layer between TLS and HTTP is sort of a weird land to be in but yeah, I feel like it's probably the right approach than trying to hack it on to the tantric"},{"startTime":"00:48:03","text":"Okay the second one, again, it was sort of related to the first one, but it doesn't really matter It's a little bit less important if we're not doing the multi-round peaks, but it's essentially right now we've declared one extension called pig and it could have any peak algorithms defined in it using PIC schemes And it's whether we basically want to to change that approach. the other alternative is instead defining multiple extensions, like one per algorithm so that would look something like this So defining more more extensions instead of having, yeah, each extension could define its own semantics or have its own like peak algorithm parameters set to it The reason this was better for multi -round pay because it was if you wanted to mess with the message like which messages each extension could be on, but that's not going to be an issue anymore So it's more just a matter of preference do we like this approach or do we like the current approach which looks like this? So it's one extension with multiple like peak scheme, like code points identifying each pig and it's associated with parameters anyone have. Yeah opinions on that The biggest advance or like the only difference I really see between the two is this one we could potentially like we currently only send one client identity and one server identity we have an open issue on whether that's the best approach and whether we want to actually support sending multiple. But we couldn't do that at all with this approach So should we be sending? a client identity and server identity for every like fake algorithm? Should we just be sending one? And then do we care about the extension format is sort of the question we can just leave it as is or yeah"},{"startTime":"00:50:03","text":"I think I like the idea of just having one extension drawing the kind of the simplest, most constrained box that we can for this kind of thing thing. Specifically for the reason I'm nervous about supporting multiple rounds so yeah yeah I think that's fair sort of say this one and then this is just the one round pick that I had on that first slide if you have two extensions doesn't allow you say things, doesn't a lot of the server say things? that are incoherent? like i support two different pakes simultaneously The server would say that? mean, the server could, right? Oh, like, does the client? do if the server? I haven't gotten that. I haven't gotten there yet, but yes that's where I'm going going right it seems to me like this it that this allows you to at the at the, at the, the, the, at the, purposeable to choose more than one peak, whereas, I mean, the way extension processors and tLS typically work right it's kind of independent and say it's a store like, you know, NSS one is. And so you get like store like, oh, he like shows, you know, he, like, shows, you know, peak and now he chose this peak and like what, you can't do that right so i think at the not to have a design a lot you to say and coherent things um unless i'm let's is a strong argument for the design that other design Cool. Yeah don't have a strong preference either way. Just wanted to talk through both options What about the, I guess, we're already on this slide, does anyone have opinions on? whether we want, like right now we have client identity server identity and then a list of like any of the offered pake shares So if you're offering Speak 2 Plus and c pace there'd be two in that list list would we prefer to have a client identity server identity per share Oh, what use cases would we have? for multiple identities for either?"},{"startTime":"00:52:03","text":"either side? I'm not totally sure, which is why i originally wrote it this way but i think echo brought up in the past that, like, I'd also mentioned like, oh, there was a client enumeration risk with that but there's not as long as we specify that like the server needs to pick which pick algorithm it wants first versus inspecting like which identity do I recognize It's a little over my head There's a GitHub issue number six, right? I pasted what you wrote wrote. Would one potential use case for sending multiple server identities be, I, as a server of decided, I to migrate from one paper to another and therefore the second pick would have a different identity Maybe I would need to think about that but that could be a good argument for it, potentially I'm not really sure mean, kind of depend if there was some way you were deriving these identities. Like how do you get the identity? if it's somehow tied? to the algorithm or something then you might kind of be stuck with different identities for each one, but it doesn't seem like you would do it that way but we'd have to understand a little bit better how you would if it's just something you choose then it seems like it I now remember my point So for the client, typically doesn't matter. The client knows the password But supposing the server has a different verified, disjoint verified database for different pakes. Then you can get into kind of an odd situation, situation, right? Whereas, and the client may have may have may have have information so um"},{"startTime":"00:54:01","text":"I mean I mean I I don't think it's a huge issue, but that was, that was what I had in mind Not going to light down the road other way I guess I'll can continue to think about if there's any use case where this would be helpful We're not going to go over that one one. Okay, a lot of these are sort of small, but I just figured since we're here, we have the time we went really fast today. I'll just keep going going okay um so this one's maybe somewhat related It also has to do with client enumeration It's a very, yeah, these are sort of small but basically we said a client can send both the PSKX extension and a PIC extension and the server can pick which one that wants to do You can't combine them them. And basically I just wanted to add text that says like the server should choose between the PSK Pake extensions based on its preference for which, like authentication mechanism, not based on like it knows the client identity otherwise an attacker could potentially do a client enumeration attack So that's literally all that changes Cool This one's even smaller. I want to add a TLS prefix to the context string And those are all the open issues So yeah, I guess we don't we still have time. So if anyone else has looked at the draft and has thoughts on like other questions we should be answered or looking at i'd love to hear about that Just going back to the multi -round page, what would I gain by?"},{"startTime":"00:56:01","text":"having a multi-round? pick is there some multi round pig that's like, you know? cures? you know some rare disease or something or is it like, is there a reason, is there like a concrete? reason why I would really? want this other than like, well my pick doesn't you know has more rounds or or... Chris, did you want to answer? saw you got up. Yeah, our PQPake is the reason why it has multiple rounds and um it's not because more rounds is better, um despite contrary uh our popular belief it's because we want a hybrid security property wherein you need to break both of the classical and the post-quotum pegs in order to actually recover the password And to do that, you have to run the two pakes in sequence as opposed to running them in parallel and And there are technical reasons for that, but that's basically what it boils down to um if we could do it with fewer rounds and fewer messages, we would love to to. But that's true. But yeah, that's that's the reason Thank you In terms of any other stuff, you've got sort of guidance, framing of document. It looks great, But I would maybe try and give a little bit of guidance to somebody reading this and when they might want to use it. And I think it's very much like when you have no alternative If all you've got is low entropy secret, great here's a pake but if you've got anything else, use that instead. I think that sort of framing might help people know when they need to use this kind of thing John ahead Just a question on the on the last point was the idea of the the TLS slash thing that want to distinguish it from quick or"},{"startTime":"00:58:01","text":"Yeah, I guess I was just thinking that right now we basically said the context could be empty or could be provided by the application and this would just maybe prevent against a cross protocol attacks i didn't have like a completely specific one in mind, but figured we should prefix for TLS But if you were using aspect 2 plus in Quick, what would you put as the string? oh sorry. guess it would still be TLS Okay So a general question on the draft you mentioned about the open issue in one of the sections and that says basically this requires formal analysis to confirm section 8 .4. I was wondering if the formal medicines is already ongoing Have you already started or are you looking? for someone or what is the current state status we've done some work so It just died I'm sorry. just try to use that one on to this. Sorry we've done some. I don't think it's up to date with the current draft version And if you are interested in doing more, that would be great So something is ongoing. So you don't need any specific help on the formal analysis that's what I want you to ask like you are you you you guys are already doing formal analysis, right? Is this? correct or Okay. I'm not sure Chris Wood, yeah, analysis is underway. But of course, more people can contribute to"},{"startTime":"01:00:01","text":"it. That's not going to no to help but it's a working group document now and if people are interested in doing that analysis and helping with it fantastic I heard the suggestion that this should be not recommended when other options are available like certificates is that a client that has a reasonable, you know, entropy pay actually has much better assurance that it's talking to the right server than when some third party did some unknown test to give the server a certificate. So we should not discourage this too strongly because it can actually be the most secure option available in some cases I don't think it's usually the most secure option available I don't think it's usually the most secure option available Pakes are very specifically only secure if you do some rate limiting on the amount of tries that you get and while you can do that in a lot of situations it's not something that you can just point it any problem and assume that it works. So I don't think it's a, like it's a nice thing to have. And I really like that it exists but it is a very special experiment. If I don't think we should encourage its use with our first analysis of the, of the, around it right I'm not saying encourage i'm saying don't discourage too strongly the client knows it has a very strong secret then it can be the more secure"},{"startTime":"01:02:01","text":"Thank you Just speaking as myself the hybrid pake, you mentioned, uses Oquake, which uses one round that would fit in the existing key exchange it's pure post-quantum. Would you be interested in registering that or writing that? up? He left Chris disappeared. laughed. Any author I said yes we'd be willing to register it Okay. As for using Pake as I generic security mechanism, would like to point out that one problem with a PIC is the necessity of exchanging at least using symmetric pake, is the necessity of exchange the same uh password high entropy or not to both sides. That is a fundamental problem and it rather is discourage it it makes it difficult I agree. It'd be hard to use pakes in places where you'd normally use certificates would argue I see some use cases where like external PSKs would potentially be used like having a higher entropy going into opaque is okay Thank you You want to just do it from there?"},{"startTime":"01:04:03","text":"How about I take this up there? there? You're not going to have any questions That's right. Yeah No, I'm working Is Sabrina here? Where is Sabrina is the ionic contact we use most often, thank thank her yeah okay um there were many updates to the registry most of them kind of editorial, things like TLS .2, added another column column, 8446 bits, 8447 bits, a lot of to all of the documents change The more interesting ones are the ones here at the bottom was a new return I forget what it said, return receipt control, a new registry added for that for the DTLS. can specify alternate ways to indicate that the path still the return path still works SSL key log file, nude labels if you want to, for debugging, record all of your private keys could now just register them Not saying you should, but if you wanted to ECH config that comes from Stephen and we and some others document So there are extensions for adding in the ECH data to the HTTP binding I thought this was a really cool trivia fact When I asked Sabrina, what has changed? since the last year? She just included a transcript that had, you know, Git log with the before and after. So okay some simple additions there's a new alert type General error came from 8446 bis. There are three new signature schemes as we heard NLS, yeah 44, 87"},{"startTime":"01:06:01","text":"There's one new supported group which adds P384 to the hybrid key exchange There were four new cipher suites that we just added last week This one, these ones, are interesting because they are from the NIST I forget that actual term, it was for, pardon me? Oh, it was from the NIST Lightweight thank you i couldn't take the word lightweight cryptography thing So they started to write a draft pardon they started to write a draft, Paul had pointed out, well, if you just, if you're, if you're content, of your draft just as points to, you know, the NIST spec, why don't we just register based on the NIST spec? So that's the first time I think we've ever done that, having something yeah we we have a registry entries based purely on an external specification The only thing that caused it to happen was they sent mail to, you know Ianna saying, please register these things, and here's the reference. And so we approved it Yeah it's even like weight now Oh, yeah, go ahead, Victor Census SECP-384, MLM knew. It was around back in February when I implemented it Yeah, was just, it only just showed up in the registry registry. It was in the registry, that's where I got the code point I thought. well, okay so maybe it was only in a draft maybe I'm misremembering where I got it Yeah, you misremembering or get got something wrong Okay SLH. So this came from an unadopted draft, as we all know there was discussion. There was a major concern that this, the document the concept was not fit for general use in tls um There are three security levels"},{"startTime":"01:08:01","text":"can do small or fast and two digests. You multiply those out because you're doing all combinations and we got 12 12 ciphers So we pushed back a little bit, Yov started it, saying, you know, it's an unadopted draft and nobody else has done more than two or three You sure you need all 12 and i added could you consider a private use until you figure out which ones are actually going to be used? But they were insistent And per the rigid, per the designated expert registry instructions, we have no choice So they're going to be registered you know sometime whenever we get around to doing the mail after this week And that's it Anybody? Victor is still in the queue Yeah, you still in the queue or not off the queue? There we go Excellent. Okay, cool That wraps up our session. have another session on Wednesday. Just to remind people, we're going to have like three working group last call flying out. I'll probably give it an extra week just because this week people might not be reading them, we want to get them started Get ready for it um if a huge blow up happens on anyone one of them don't forget there's two others going on Thank you very much Let's just pile through I would run it to some time Thank you"},{"startTime":"01:10:03","text":"We need a lot It's down Remember, people who wrote this is it's an automated death track Just to say hello I'm dry running slides So he could Thank you. Thank you You know, you're say this stage We see you You want to go to I think about it I'm just Thank you"}]
Session Date/Time: 05 Nov 2025 19:30
[{"startTime":"00:00:08","text":"All right, folks you're here for the TLS meeting then you're in the right place We're going to get started now do we already have a, do we have a scribe? all right i need note taker It's true, but just in case in case the cloud does not do exactly what we wanted to do do um can we have somebody volunteer for notes Yeah, there's is just recording the major action so that we can test it against the AI later this All right, thank you, Chris All right, folks here is the note well um what yeah you've already agreed to all this but just uh reminder that these are the policies about conduct, privacy and electoral property that you agreed to follow so if you have any questions you can talk to the chairs of the ADs Uh, please join the the uh with your on-site tool so you can join the queue that's how we'll manage the microphone line, both for on line attendees and on site attendees don't turn your video and audio on in the remote attendees until you are talking and presenting presenting uh okay we have uh on the agenda"},{"startTime":"00:02:00","text":"Yeah all right just some things to note we have a couple of adoption calls going on and working group last call going on right now so No, I'm just getting the QR code Okay, I thought I was in trouble again Yeah, sorry And so for for today, we have, uh, DTLS and then some non-working group IDs, any other business people would like to discuss If we have enough time, then there will be an additional surprise presentation i guess All right so shall we get started with uh I don't have the clicker here Thanks So this is my homework from last night literally uh literally uh um next slide oh i can do next slide can I? Ha, look at that. Maybe So I guess a backstory for people who may remember you know, we had 9446 and we are doing 8436 bistic clean things up and i like hopefully thought 9947 is really done and then David Benjamin read it and then it wasn't done Um, yeah, and um you know, we're doing on any 147 best to clean up a of like, I think somewhat more serious issues, but not too serious hopefully, 91.47, largely in response to some comments from the ground team So, uh, hannes um did it humans work and generated a lot of PRs based on the existing errata, which have already been approved?"},{"startTime":"00:04:00","text":"approved. And the 01 draft includes basically a pile of these errat um i'm not going to go through this detail You can go read them yourself. I think they're all essentially uncontroversial. They reflect real defects in the specification specification of various kinds I want to talk through a small number of issues, but not all of them, large as I didn't get to all of them I don't know to tell you man like pressing the button I think we're going to have to because I'm pressing this progressively. Okay. I'm going to go through a selection of the issue This will not be all of them, but hopefully some of the major ones So the first issue, RC-94-947 as all previous versions of GTLS has a replay detection and suppression mechanism inspired by the old IPSEX sliding window mechanism It's always been optional Maybe you could detect and suppress or you could not John Mattson pointed out that it would better to have it mandatory, and in particular, that there is at least one setting where um post-handcheck authentication, where it's a little unclear what things look like if it's not mandatory. Like if you're, if you're doing post-aging authentication and don't don't suppress replace, what the semantics of that? It may not be okay, arguably easier to say, like, are we alive and replace it all? We could just ban it entirely Um, Paul, you want to be in the queue there? Okay, We we could just ban entirely um but the problem is it turns out that um and we had a long discussion, Michael took some on the issue, DTSA service, CTP, his own replay detection, that should say so it doesn't want duplicate drops. And in particular, Michael's point is, there's like um the way that"},{"startTime":"00:06:00","text":"the wind mechanism works is like a sliding window and that you might have um, the things that are on the SCTP is maintaining a longer, a longer window and so you drop things in the detail later but not after the SCTP layer, that's obviously bad. don't have to fight each other. So I think there are two options. One is to leave it as is, in which case about the Rick, we examine this question of the postage of the and make sure it's okay, which I think it probably is is. And the second is to basically write some text I can have here for option two, which to say, you've got to do all time, except unless you know your transport has any replay which i think like the only case that really is, is this a CTP case Paul. Paul Writers, IP enthusiast and not speaking as AD We're just designing a new version of ESP in IPSEC working group where you can disable replaypoint detection because it really sucks for performance I see So I would strongly not recommend making this mandatory that's really helpful I did not know that that I don't have a strong opinion on this this. If other people do, you get to the mic, now um otherwise what i'll probably do is go read the spec and see if I understand John's point about the post -agent authentication and see if it's right and if he has to deal with it it, and put something that way And John, course, of course, on the list. don't see John in queue or anything can complain that we did this wrong and we can take it to the list as well well. Okay, next Okay, this is a fun one So -9147 specifies how to use axe in every epoch including epoch zero It also includes epoch 1, which is incoherent and we remove that at David's Benjamin's suggestion epoch one being early data"},{"startTime":"00:08:00","text":"data. But the problem is you're not allowed to send acts to DTLs 1 .2 clients or details what we do servers for that matter because it's an illegal content type and then we'll choke And so this, like this mechanically can't do it um but that means you can't send an act and the version is DS1.3, otherwise you're going to cause errors errors um uh so um that's not does not mean that's not impossible to know when you can send acts, but people, most implementations, parse the client hello or the server hello in one big chunk, which means there's basically not a very common situation at least in a one -round Japan shake, where you would know that the other side was T.L.1.3, details 1.3, but you would not have like, the entire client hole hole all server hole to work with. It's not impossible you'd know. say, instance, that like the supportive versions was like the first extension and then like made it the first packet and like you had a giant post-quant and so I was spent with all packets but it's not like a common set common setting um um so so So the one case, what actually is kind of plausible that you might know you had 1.3 but also be able to use X, is after HR, because after you've received an HR, then you do know you're in 1 point three votes um david in david's comments on um linked out of issue 291 he suggests that it's probably easiest to just ban acts entirely epoch zero um this, um, would definitely not cause a, well, let's not say definitely, but should not cause a functional regression because you don't need act to make the handshake complete because you just retransmit the whole flight It may cause if the hand client was like super big, like you're doing classic public lease, what might happen is we get a less efficient first flight because like you have to retrans with the entire thing rather than just the pieces that were delivered um i think this is probably a pretty low impact change change, because like A, we all never do have like things spanning like a big ton of packets at the first flight um"},{"startTime":"00:10:00","text":"and um uh and if we probably did, and like, if we did have classic Mickles, we'd some other things to do. So my instinct is that this is like a lot of to do with Davis suggestions if we remove them um that we'd actually firmly have to do is to forbid sending them and then um but if you receive them you like ignore you can either process it or ignore it, because there might be 9147 compliant clients or servers that already sent them in some confused way and so you don't to create a not problem. So I think think it's a problem to fix this, but I think so if anybody wants to speak up and be Martin in favor of routine accident at box zero, now is your time So Martin Thompson this is not very loud So I'm a little interested in the assertion that you can't send an act to a DTLS1 to client This is DTLS, right? And so if you get garbage, you're supposed to throw Does that, are there situations in which the acknowledgement would cause the handshake to part? Because it will be marked as a different record type so it's not going to come through in a way that would look like a handshake You know, I have to admit this is not something that occurred to me last night at 10 p.m I don't know if I don't in fact know what implementation is do if they receive a non -record types so I think I think that may be the question you want to want want to answered here Because if they are just discarded as they should be, then keeping the axes useful because it means that you get better loss recovery for that first round trip Assuming that there is a scenario where you are aware that... It doesn't matter. You would just always acknowledge... You're saying if saying if you're a 1.3 stack and someone says you'll call who love any flavor, you send acts. Just send an act. Yeah So I think we really want to persuade ourselves that there was no staff that freaked out in the circumstance that's what that's why i suggest"},{"startTime":"00:12:00","text":"And there's also, by the way, a separate PR um at have commentary from you about clarifying what it means to reject bad packets that I think I tagged you to ask you if you could produce some text for So that may interlock with this discussion Great Paul Writers, again, I IPsec enthusiast and not AD I'm just triggering on the, you get full retransmit there in the classic Michelese cases you have there Again, in Ikev2, we can do McAlees by using ICV-2 fragmentation and a protocol there has like if you miss a fragment, you add for a retransmit and you get all the fragments again and it's like well it's not really optimized but it will work. I'm not sure if this is doing something similar, but we've now found out that in some practice deployment cases where people have actually done this in production you run into cases where you actually never complete a handshake because you'll never actually get all the fragments collected. Yeah, so the way TTRS is supposed to work is that, well, the way 1.2 worked is there were no axe at all. And so you retransmit the entire flight. And so in this case, what happens is, you time out and you-transmit the entire flight And so what the axe were designed to do is lie to suppress some of the, you know, some of the unnecessary packets precisely so you made headway in the way you're talking about. But it should, I mean, if you are like winning this situation where like the reason you're getting drops is because you're overflowing, you're like like some very short queue and so you always lose the last two packets then yeah less it will like you will never complete but other than that, if it's just like random drops, you work fine? David Benjamin I will double check this again, but when this came up, I'm fairly sure the reason this came up is that all OpenSL and all OpenSL derives stacks will get upset if you send an unexpected content type like allowing error thing usually is limited to or in the stacks that I'm familiar with, it's limited to decryption failures and since we haven't started decrypting in the first place like there are no decryption failures Or decryption failure and failure to parse the header. Right we are succeeding to parsing the header is just that is"},{"startTime":"00:14:02","text":"Could you check for us? Yeah, I'll double check for sure sure. I mean, I guess my put here is if David is correct then we kind of have to just like live with this problem and turn it off And if David is incorrect, then we have to do some more research to find out if Martin is right Is that match your opinion, Martin? So I think we have a provisional way forward of some kind I don't think we'd wait for David David, could get this later later um uh next um okay uh we had so as people may remember, 1.3 now encrypts sequence numbers, imitating quick NVIDU proposed an extension a while back for unencrypted sequence numbers numbers um uh i um hannes made an issue so I'm dealing with it I do not think we should adopt this in the court at all, like if they wanted to publish as a separate extension spec, maybe that's okay. like I don't think any change at the core is indicated so i want to just close this issue with no Okay, I see some thumbs up so we're going to do that unless somebody objects objects. Dave, did you want to know your . Didn't SSH just have a bug that they are deciding to close because they had numbers like this control flow numbers. I think we should not do this i think we're okay look but like so from the perspective this presentation we'll just turn this off and then if they want to come back with this, can debate that later without having to resolve the question you just raised, which I'm horrified to think about Next slide Okay, so where are we? I think we have ways forward and if the issue that is raised, there are a few more issues that are floating around um david had raised some issues around Act boundaries, are related to this epoch zero thing, but not exactly the same. I need to frankly go through those and make sure i understand it So I'll come back to the working group with like an attempt to like channel david some and probably after i've talked to david for something that makes some sense"},{"startTime":"00:16:00","text":"um uh so So I imagine what those will say was like whatever David written in Iran was going to do, but I won't be sure until I read them. There's a outstanding small issues that have questions on I'm hoping to resolve all this stuff, basically the next IETF given my child a little bit earlier and he pointed out that like the writing in this is not necessarily as clear as it could be I don't think either he or i or hannis really have the energy to like go fix that stuff up up. So my target here is let's improve the situation. We've had David, found a bunch of problems. Let's fix the problems so that the effect becomes clear on its own face. then if someone gets the energy to do a of the writing cleanup, we can do that later but like i don't want to hold that up because i think the practically the chance i'm going to do that is quite a a lot. If there are any, so please consider this to be a not last call, a for if you were aware of any more tactical issues in the spectrum and not reflected either in the spec in the current draft or in the issues list, please tell me and put them on the list because I'm planning to work off that list. And when that list goes to zero, which I'm hoping is by the next IETF then I'm going to ask the chairs for working at the last call So So the only other thing I can think of is that there are like nine or 10 errata against details 1.2 that it would be nice to see if we've addressed them as well i know hona said a bunch of erada but those were against one three. I can go look. Okay. That's awesome If you could file an issue so I don't forget that, you can just like literally say, do the Arandifam 1-2 and I'll know what it is All right, people are getting a lot of time back Is it Nick? quickering"},{"startTime":"00:18:04","text":"This is going to scroll out mine, I guess My apologies yeah yeah yeah well let's see no you can do it All right, it works It's fixed. Okay all right so this is a draft way back when I kind of proposed that maybe the working group would think about adopting it It just specifies a file form for ECH for private key and an config and that's an example and that's about the limit of the spec. There's not much to it it. Meanwhile, it's been implemented so it's part of this Opel SELDCH feature branch Boring doesn't produce these things or consume them, there's a small shell script you can use to do it and then a bunch of servers are in various stages of incorporating this format as a way to store ECH keys And you can see the status there a bunch of them have code it's not necessarily released. Pardon? Back one slide. There you go Okay. And forward one side So if we wanted to make changes to it, later would be a really bad time. Now it's not a great time because you'd have to go, you know, beg all these people to make changes but it's very simple, so I don't know if there is one anyway so i while back on the list said, should we look at this again because now is a good time to make changes if they're really needed But meanwhile, some people said, well, there's a key format we don't might want to do it paul agreed on the basis of precedent of of RFC 7468, which I can't remember what it is some other file for them file for some Anyway, Paul said, he's okay to AD sponsors. Seems like a good plan to me"},{"startTime":"00:20:00","text":"If people want to read it, and it's very short that it'll be going to get comments like I say changing anything there's not much to change anyway, changing it significantly might be a of a pain because you'd have to go back to all those maintainers and ask them to change code But editorials and stuff would be fine So, and it would be much harder to change later. So if you do have comments, there's a good time So let's just know longer asking the working group to do anything other than not complain to Paul or complain now if you want to sell. And I think that's all want to complain not complain want to complain, I'll have to separate it Thank you garroslav um yeah i i want to complain a little bit It's too late but oh um right. I want to complain just a little bit I know that it's probably too late, but having ECH config list that contains always one config is a bit weird I think it would be better to just have a.H config. So it no longer says that. says one ECH config list but it can be multiple ECH configs. You it as long as one of them matches the private key. Oh, can you have multiple private keys of different? formats and this each one private code zero or one private keys only? So there is no, you cannot have multiple different ECH conflicts with different cryptographic. Yeah, you could have different, you could have multiple ECH configs if they match the private key you could change the AED stuff for the public name Okay. Would it be feasible? to have multiple private keys if you could have multiple ECH configs so that you could... I think that would complicate it undesirably but it won't break existing it would probably would And it's undesirable anyway Okay. you But I guess there'll be a last call"},{"startTime":"00:22:02","text":"Asama? Yeah Muhammad Usama Sardar. So I just wanted to be sure there was an extensive formal analysis. There was an extensive formal analysis and i was wondering if this change was already or this configuration that you propose in this specific draft was it already verified or does it even need any analysis? at all or it does not okay i haven't read the data okay so no just a file for it need for a crypto it's it's not making a change to TLS one three key exchange protocol anything like that's just a file format. Yeah, it's mostly harmless um yeah um so so apologize, Stephen. haven't read this draft, that's why I asked you to go back So is the, are these separable? Namely, can you have the ECE config without the perfect key? key? As with current, I've oscillated a bit, but yes, you can have zero private keys But that would be not nothing between the tags but it would be no nothing that said big in private key. Yeah. these age. Okay yeah, um for what it's worth i think it is a little unfortunate you can have more than one public key and only one private key but I guess I understand how you got there there And the private key is the same format as it always is is. Like that is the same format as like every other private key that as far as I know it is and if it's not it should be seems harmless yeah okay harmless great Thank you. Thanks Thank you very much"},{"startTime":"00:24:00","text":"Okay, hello everybody. We're going to talk about ECH again So it's been deployed in a lot of different situations We talked about it at the last IETF meeting and the meeting before this challenge with respect to updating the ECH configuration if it's out of date There's a mechanism for doing so and it's deployed and it works, But the issue is that it restrictive in terms of how ECH can be configured by clients So here's the main issue that we're hoping to deal with within this new draft is that these ECH configurations are basically a structure containing data that is unsigned It's served by DNS or via HTTP, but itself does not have some way to authenticate it as an independent object So this indicates that there's potentially a need for a single authenticated update mechanism if you have an ECH config that's out of date So this is the proposal I've discussed with this extensively with Dennis and Alessandro who are going to join me on this draft. But the idea is that there's an extension for ECH config that advertises public key hashes or certificate info that correspond to ways to update this particular object And so in this would be delivered either in DNS where the the the ECH config usually is or in the TLS encrypted extension in the retry config, which is the current mechanism for getting an update we have in this draft defined two authentication modes"},{"startTime":"00:26:00","text":"and we might not we might want to end up with just one at the end of it. But these, these two seemed to have distinct benefits. The first is a raw public key mode where you, when you first get your ECH config, it has a list of hashes of keys that can be used to sign any config that can be used to replace it it. So this allows in the TLS Handshake the retry message to be signed by one of the keys that was originally in the config And you can check that and validate it without having to go through the current mechanism which is relying on the handshate certificate to authenticate this object. The second mode here, is certificate-based. This is much more closely aligned with how the current mechanism is for updating ECH configs. But effectively, effectively, you sign the ECH config with a certificate that has a new critical extension for ECH config signing So it can't be used in other situations But it's just as, just as you have to validate this public name in the UTLS handshake, In this case, validate the public name in the certificate that's sent along with the object So this is what it looks like It's a new extension in the ECH config. It has off method off info. This includes something that I'm sure people will discuss, a mechanism mechanism for exploration for these keys, but it's relatively simple either a list of hashes or a certificate chain and uh not after so here's the it's very very simple and the signatures at the end. so this is required to be the last extension so that it, it,"},{"startTime":"00:28:00","text":"the entire object Next one why do this? This seems like it's working or why are we even updating this, But the idea here is there's advantages like deployment agility which means you can do this ECH key rotation through all sorts of different methods, not just DNS. You know, we also have the HTTP distribution method This helps bind the authentication to the object itself so that it's cleanly separated Another thing that this allows, and this is sort of secondary, but was part of the genesis of this idea, is that it does enable something that's allowed in the ECH spec, which is for the client to choose different names in the outer SNI. And for the name in the outer SNI to not be related to the authentication of the update update. So this is a good thing. It allows more flexibility on clients with regard to using this deprecated outer S&I field that's currently being used to current deployments to list a public name The other benefits here is, you know, it's a unified framework that doesn't require cross, like, object to protocol validation of trust it's all self-contained it's relatively simple the state is for the certificates is you really just have to have a certificate and with the with the keys a mechanism for having keys and updating them and publishing the hashes in in an eCH config The other good thing about this is that it fits into the ECH retry config mechanism, very nice in TLS. There's no changes to TLS required for this All right, why are we here? am I asking for? Well, we'd like folks to try to implement this and interoperate and to see which one of these two modes"},{"startTime":"00:30:00","text":"is easier or is preferred for folks who might want to implement this, both on the side and on the service side We have open questions here about, you know, operational guidance, what the expiration window is, retry policies whether or not you can put signed things into, there's just some questions about where these things go that we'd like to discuss um and speaking of implementation folks want to implement it and give feedback to refine the mechanism speed up deployment we'd love for that as well without just we can do questions if they're already are any Thank you No, I was just going to be supportive uh i think we should work on something that is i notice you're not asking for adoption yet i think that's probably correct. think some of ideas might need to be fleshed out a bit more before you get there but I think working on this seems like a sensible thing Okay, we now have people to ask questions. Martin That's great Martin Thompson, I'm enthusiastic about working in this general area think it's probably something that would make the recovery part a little bit more robust and potentially some privacy stories could be improved. I do think that there's some interesting questions that deployments will have to ask if they hand clients the ability to choose what the public name is that has implications I do think that you want to choose one I don't see a lot of value in in directing through the public name I think the whole um the whole value of this is removing that coupling between the public name and otherwise. One thing that"},{"startTime":"00:32:00","text":"you have done that I don't know if I agree with is that to some extent the public name and the config ID are things that a server can use to choose the configuration that it's going to apply for decrypting the ECH. It be, but it's like it could it's not supposed to be. It's the ID. The ID is supposed to but let's let's face it the public name is also a selector on this one. I did ask the implementers and they're not doing it, using it that way. yes, Maybe they could And the reason I say that is that that that suggests that having the server have a say in what the public name is is potentially something that you want to consider as part of the design So I think there's a distinction here that we have to make clear the public name itself is chosen by the server exclusively The public name is what's published in the EC config. What you're referencing is the outer SNI. Outer S&I, which is not the public name. Correct. Right So public name, think, was it was a misfeiture in the in the first place but it was the way of got us off the ground ground so so public name retiring that concept as a way of doing recovery, think, is a good thing and this is a this is a better way to do it it opens up these possibilities in terms of different distribution mechanisms for the updated configs which is healthy I do think it creates that risk so so there's one question here that we did not did not decide is, you know, upgrade scenario where some some servers have have supported this mechanism and clients haven't or clients have um We are going to be stuck with the public name based authentic because it's what's deployed right now And if you add you know, this signed extension and make it critical, well, there's no critical extensions in ECH, don't think"},{"startTime":"00:34:00","text":"You can't force the upgrade. What I'm saying, is the public name based off is going to be there for a while Whether or not we move to RPK well there is a quick well we have the possibility of changing the version in that. Right, it would have to be a breaking version right right but you can publish old version and a new version things in the DNS if that's what you wanted to do Thank you Hello. David Adrian Chrome. I'm really supportive of trying to get rid of elder s and i and all that however um in terms of like implementing this specific drive this was to make it easier to deploy but who are there interested server operators Check the third name on the list this sorry where check the third name on the list yeah um the people that have already deployed the existing one? Yes Exactly. like in reality, what we have here is a protocol implemented by Chrome and Firefox and deployed by Cloudflare that like Google has been struggling for a while to deploy internally for reasons that are unrelated to outer S&I and this part. it turns out they're getting keys coordinated between d your front end server and your software and then tying all that into your DNS stack or your TLS stack is like just a complicated process and so I'd be like a little wary to implement this on the client side and if the only server implementer that's interested in it is the people that have already deployed it I'm not convinced this is going to expand adoption so I'm curious what extent this is about removing outer S&I, which seems great, versus like actually expanding adoption because it's not clear to me that this is going to expand adoption I'm not convinced"},{"startTime":"00:36:00","text":"that this will necessarily expand adoption either I think it allows any new implementers on the client or server side to kind of remove this hacky update mechanism And the hacky update mechanism exists for the same reasons that you listed dns is very hard to keep in sync with these keys And having something like this, which is a whole list of future keys that you can use to update the configs, might actually alleviate some of the pressure that you're seeing with stale DNS, for example So it may be able to help deploy but I would have to hear from the implementers themselves Thank you Chris Patton, I am enthusiastic about this idea Can you go back to the RPK versus our peak X slide? Okay, server signs okay Okay I missed something before about this that I think is, uh, I going to The thing about like sticking signing keys, signing, eck signing certificates in the web pk i is making sure we don't miss issue is like becomes really really important um and i guess having a critical, I'm just thinking aloud now having a critical extension is good. So the idea is that the signer, okay, so you would have to this certificate would have to be authoritative for the okay i'm good i think this makes sense sense yeah it would be nice to pick one of these I guess"},{"startTime":"00:38:00","text":"is the only other pitch critical extension is really what closes this off. we've seen other examples of groups use the WebPKII and critical extensions, new ones web packaging, for example, to sign objects with a TLS search And this prevents that from being cross used in previous protocols the fact that it's critical So I guess, how will discovery work? Like, it's all published the first time you see an ECH config That gives you all the mechanisms you need to so but if i'm i'm just getting like an EC config from from a dns like record and it's unauthenticated so far i don't know if i'm supposed to trust that public name like somehow don't you need to pin the public name, like public names you trust like on the relying parties side dennis maybe can answer this that's how you see h works today you get a public name from DNS. It's not authenticated and that's what your sort of trust is for the retry config so this is identical to that there's no increase or decrease so we're still like trust on first use and we don't This is how ECH works, right? If you're not DNSX signed you trusting the first one Okay, Yes. mean actually on that specific case, you could do that if you learn the ECH config from the website itself because your connection to the website is authentic You know that you are connecting to that specific website. So when you get it through HTTP, have a good presumption that it is a valid config but my point is not that what happens if if the client-facing server protected server co-located"},{"startTime":"00:40:00","text":"because i have this tension in in eCH engineering the eCH architecture is that the client -facing server must know the private key associated with the configuration, otherwise it just cannot unwrap the ECH envelope But the configuration itself is published by the final server That final in that case, of HEDP it is So I mean, mean I I have this tension there I mean how do I resolve the tension? Normally, I have myself server. want to say, for example, my server can be served by Cloudflare and Akamari. How do I do that? that? What is the effect on publishing the configuration? What's the effect on this mechanism? I don't know that there is an effect think this is just taking object that is currently unauthent and adding a signature tag to it. So in every case that it's used, I would imagine you would have more assurances but maybe I'd misunderstood the question So your signature tag has to be signed by the fonting server, correct? So, sorry, if I can, Dennis Jackson, Mozilla. So if we lived in this happy world where Akamai had rolled out eCH and looking at rich here here, then what would, when you sort of want to do, that kind of dns advertisement you're actually in a really tricky spot and when cloud flow rolled out ech i think there were some issues with this where third-party sites were doing interesting things with DNS and free DNS to sort of load balance between CDN and they weren't always aware about you had which ECH private keys So I would say this is like largely a bit of an unsolved, unsolved area, doing like multi-CDN deployments of ECH"},{"startTime":"00:42:00","text":"is not, not trivial Yeah. There was a comment in chat around like sort of how retry works and recoverability around our And I just wanted to sort of highlight that this doesn't change anything about how that works So today you have an initial config, which is authenticated by a public name. In these drafts, you would have a key signature sorry a key hash and that none of that state persists beyond the initial, when you get the retry configs from the server so they're as recoverable as each other Hi, Eric Griscollah, more a question than a comment comment. Have you talked to any CAs about issuing this kind of PK certificate? No. Sorry, Not yet. Okay. That seems like a threshold question pretty early on, right? So as I understand it, Dennis, the way things work with the um that with the multi-seed end scenarios this is why the ICPS service B records contain the IP address is so you get the right CDN So, and I, I read this last night, so like, forgive me if it's like, it was quite late, but as I recall this in fact does say that you are supposed to only use this with the same IP addresses before, right? So you don't get in this weird state where you connected first to Akamai. And where you connect the doc, where you connect, but you sorry we're cloud fly advertised you ECH to Cloudflare and then you reconnect to Akamai with a new thing. You've got to buy it you got to treat it as if it came out of the same HGPS record, right? Right. You have one HGPS record that has the IPs and the key and this retry mechanism you would only trust the updates or the listed keys on the IP address that you would originally crosses out the ECH config and puts in the new one. Right, that seems like it all to work fine um uh i also not i also am a fan of only one thing and i think and my I guess I'm open to being"},{"startTime":"00:44:00","text":"persuaded that is the Pek's thing, but my, my current impression is the RPK thing Yeah, there's mixed opinions on this They're both practical, I think, in my opinion, but it's some it's about the ecosystem Alessandro Gadini, Cloudflare, mostly to address David's comment about adoption as someone who's actually deployed DCH, it's not you know, universally adopted across all our network So while I can't say, you know, we do this and then suddenly everything's great and we can enable ECH a hundred percent. It's on the path of getting to that point or at least expanding adoption so can you explain yeah versus the current deployment? versus the deployment with this? why it would be easier to deploy? Yeah, it's mostly about the the disentangling the public name with the retry config. So this is the you know sort of deployment agility case And for us, I guess the raw public key would be the method that we would adopt because the peak X one kind of as similar problem with the public name name. So even if we went to you know one method the RPK one would probably be, you know, my choice in that case if that makes sense yeah yep First presentation Bonus presentation Who are we asking for? Yes Yes. Isam? Where is he? We got time"},{"startTime":"00:46:02","text":"and discussed unless there's been a couple of messages has been discussed on list he asked if we had time we didn't think we would surprisingly we got done earlier i will note i know know you have 10 slides and you got 15 minutes and please leave five minutes for questions OK. So So thanks to your talk about in the chance. So I want to today's our new proper for the service affinity based on the TLS I'll hear is the background for this proper you know, we are now in our network the service the And you can, yeah So we are now in the network network, the service may be deployed in several locations with the same address. So it's ground for can can now. So it's, is applied the three occasions with any cuts or death. And so when the customer access the service, uh the router will select the different service node to match their requirement different customers may be directed to the different service. This is okay for the overall traffic but for the for one same same customer and the says the the system of the same customer all the packets will be reached to the same service node But if we stick, if the service is, accessed only by the kind of this, by the network,"},{"startTime":"00:48:00","text":"is are changed the packet from the same system of the same customer made be directed to our service node. So we want to avoid the same such such a problem so we call the necessary for the service affinity So this is our, this is our one to solve We also consider the possible solutions for example, balance and HTTP and DUNS, DX, we answered they are not suitable for this scenario because for example ATP rely only on the application info and cannot utilize the network data info. So, uh, are also drawback for the council. I do not introduce their in detail. So our solution for this requirement in the uh you know everyone first the the customer X when the customer access the service uh it will use any cost or just, but when the server, received the first packet and recognized the packet, is from the cost of this. We want to serve to return to the customer, by unicassautis and the less customer established the TLS system, new TLS system and then the following packet will be be directed to the unicast The connection to the unit council address will be uh uh uh, uh, will be stage two, uh, surface node because it is unique hasn't. If you use the, it is"},{"startTime":"00:50:00","text":"any console or this is the packet may be directed to our service. So they utilize the switchover procedure to accomplish the the service affinity requirement. This is our main main proposal. So, here we just also list the procedure you know, the first, of the client sent a request to the server using or any cost of this and when a router in network, this was such a click that will direct the packet to the most optimal service node When the third node, for example, the, I, I, a node, this is the first packet. When the service node, use this packet, it will realize that the packet is to its any cuts or this. It will send back a notification, information, to the customer and told the customer it's a unicastardist and the customer, the the then please the when TLSS to the unicast of the servers So to accomplish the, we extend the TLS in uh uh three we define the three extensions. The first is the notification for the uh from the customer it supported the migration and the second is the negative token at the it is from the server to notify the the customer what is the unique address and the what's the second token for the previous? previous connections and the third is the you use the the letter by the server to make notify. The migration can be"},{"startTime":"00:52:04","text":"be can be can begin at the immediately or can be initiated from the custom or from the server So the media list notify is used by the server Yeah, they also consider the some second, you know, we rely the switch over based on the TLS is the the TLS that can keep the switchover be secure and it can less the middle in the attacker when the switchover take place place. So yeah, this is our overall proper i think there are some discussion in the list. So if, uh, So, the had a number of comments. I think on the list we had a particular discussion. I think there are two primary comments I have. The first is, that I am not yet persuaded to tell us the right layer for this. I don't understand. I think this is a much more appropriate application layer we don't have to worry about like the race conditions between when the when the switchover happens and what application message has been delivered and act in which ones are not been because the application message already have all the other mechanisms for handling connection failures and now you've introduced a new connection failure that like is weirdly asynchronous to that so um so i think that's i think that there's not the right place to do it To the center, which is the right place to do it, this mechanism is not good um so like you don't need all this this mechanism because the just stuff all the state in the session in the session ticket you don't need a migration token in need any of stuff take all the state pickle in the session ticket you don't need any tell support that. The only thing you need is the mechanism to say switch over to this IPA And I don't"},{"startTime":"00:54:00","text":"know where you think that goes, because again, this is another reason to put it like an HTTP header because it can't go into work because there's no room for it in the alert um but if you put an application there then you can put any application there just fine fine. Whereas having like the semantics, the NST is just like goofy So, um, I just think this is like architecturally the wrong solution solution So I just want to explain because the this scenario, the selection of the the optimum server is taken place at the the network lasers so and the the application layer what to do do. It should bubble up the application layer to instruct it what to do Yeah if we let's work being done in the application later, we because there are various applications we we must do the extension in each of the application later. But if we do the switch over in the TLSZL it can be applied to all the application sensor as done on the TLS Yeah, but that's bad, not good. And the reason it's bad is because you're creating this basically asynchronous from the application layer perspective you're creating a network failure that is asynchronous to the application layer stage It's just like the connection just terminated And the application, unless you tell the application, which packets were delivered, which packets were not then it is as if the connection just got dropped off in some weird state Whereas if the application does it, it can arrange to synchronize the state in an appropriate fashion fashion. And by the way, it's like really only one application that matters anyway was HTTP. I see that solution is the application agnostic solutions. Yeah, I understand you do, but I guess i'd you to respond to the point i just made which is that it creates an asynchronous failure from the application's perspective where suddenly, like,"},{"startTime":"00:56:00","text":"packets were delivered and some packets were not. And the thing in the connection is terminated I have mentioned in the mail list at you know, quickly, also have some similar procedure. It is also in the transport layers no Quick does have that, the abstraction, or Quick does, is pretends that the when quick migrates, the connection state stays up and so if there were some packets that were sent before the switch and some packages after switch they're still delivered as if it one connection What this is is two connections and there's no way there's no way of it and there's no reliability mechanisms and no way of no which packets were handled which packets were not, when the alert was sent and processed Okay, thank you Yeah, Martin Thompson, this is, I think, superficially like, like preferred address mechanism and that happens during the handshake but in that mechanism there's an essential property that this isn't able to provide And I think that's very challenging in this case because you're you're talking about making new TCP connections So if this were purely at HTTP TLS, you would do it redirect and you would point that at a different host name. You would point that at a host name that resolves to the Unicast address address the um rather than the anycast address right so you you make a connection and then you redirect and And you'd have to do a full handshake that's a little unfortunate, but that's just how it works for that. If there are other applications that need other applications protocols that would need this then they would need similar mechanisms in that it just to give you an example of why why this particularly challenging, you've got one, you've got this original connection that's that's up at the tcp layer"},{"startTime":"00:58:00","text":"that has a bunch of messages that have that have been exchanged. And at some point, there's a message that comes through and says, stop using this one and go and connect to this IP address But the application that's sitting on top of that is seeing a connection break Zika pointed out. And you then have to have this session continuity layer and we don't have one of those So would you like to summarize in list? Okay, you Because, you know, we also uh a lot of coercion from the Pell Network we can discuss more you concerns. Okay thank you That's it Have a nice day. We got done one minute and 17 seconds early"}]