Internet Engineering Task Force 101, 19 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF101-QUIC-20180319-1330

Description

QUIC meeting session at IETF101
2018/03/19 1330

https://datatracker.ietf.org/meeting/101/proceedings/

A

Oh, but you do drop the checker.

B

C

This is quick if you're not here for quick I'd, ask you to leave the room immediately. Folks, who are standing around chatting in the back of the room, make your decision now. Please hi, please find the seats as Lars mentioned, we have a packed agenda.

C

So this is the ietf note well in its new form, even more readable, if you're not familiar with this I would encourage you to use your savor, a favorite web search engine. To look for IETF note. Well, it's the conditions upon which we under which we participate, regarding intellectual property and regarding privacy and regarding taking photographs which is a new one and regarding.

C

Behavior in general, behaviors an attendee, so please have a look at that if you're not already intimately familiar, we have two sessions in this if'. Today we have the hackathon report, an editor's update, the editors. Some of you may have noticed the editors were quite busy last week, then we're going to talk about a proposal for a quick over DTLS and stream zero adjustments from ekor.

C

Then martin is going to talk about invariants and hopefully we're gonna get to talking about ecn and perhaps a short couple of very brief presentations about stuff, that's being presented elsewhere in the ITF this week on Thursday we're going to talk about the spin bit proposal from Brian and if we have any time left over we'll talk about either issues or stuff. That's build out of the agenda today. Do we have any agenda bashing?

C

C

C

Anything else, okay, so let's get started the hackathon Lars. Can you yeah.

D

I don't know if this my team's work right.

E

D

Right class I.

E

D

Know if you have any control over the.

E

Lighting but these slides are very hard to read just call.

D

E

Can't hear you, can you I, don't I, don't know if you have control over the lighting, but the slides are very hard to see.

F

C

Light on the front yeah we asked about that. They can't do anything about it. Apparently we can ask the Secretariat but I, don't think it's getting fixed in this session unless we want to sit in the dark, but.

D

You can join, you can join the meet echo and then you get the stream version of the slides. Oh.

G

D

C

I'm gonna need your help. Oh crap where's, my cursor there. It is so you go. No oh, come on.

D

Yeah bout that packed agenda yeah.

G

D

We go right so so can you say that this is the current version of T the interrupt matrix? It's the interactive version. Sorry, okay! Is this better? Okay, I, don't want to I! Guess I have to eat it all right! I can do that. So there's a bunch of implementations of quick. Some are closed, tour some open source- and this is I- think the seventh or eighth time we got together to interrupt s time against each other.

D

We typically do an interrupt event before every interim meeting that we're having three times a year and we're doing it during the hackathon before each ITF, which happened on Saturday Sunday.

D

um Basically, if you look at this slide on the left-hand side, you see the different client implementations talking to the different server implementations of each client is a row. The greener a cell is and the more yellow it looks the better um so you're seeing that that mostly we have some pretty good interrupts while you don't because there's a tuner in front, but we have some pretty good interrupts on things. Like version negotiation, the handshake data exchange connection, close resumption, zero, RTT and state.

D

Let's reset also what those letters are for um some informations are liking the behind and haven't really updated to the forth invitation draft.

D

Yet others, maybe only have a client at the moment or only have a server, but by and large I think this looks very promising and- and we are sort of now getting ready, I think in the interrupts event that we're gonna have in June before our meeting and she star to finally look into some HTTP non-http 0.9 interrupt, but actually using some of the HTTP binding stuff that we've been writing down for a while, but that we haven't been able to test yet because the underlying transport wasn't quite there.

D

So um it certainly is still going to be challenging to ship, RFC's and implementations by November, but I think it's still very feasible. So the cadence has been good and I think the activity has been nice. We're probably also going to be doing a virtual interrupts Day again sometime between now and June. Probably gonna do a doodle poll either on the slack or animating list. I would guess that would be maybe roughly middle May or something sort of between now and and Stockholm, and we haven't really discussed this widely amongst the implementers.

D

But my my feeling is that for the next virtual interrupts a and then the Stockholm / Easter interrupts event. We would do implementation trough 5, which is probably going to be the 11 releases of the drafts that aren't out yet plus whatever TLS 1-3 is at, which is 26 well 27, mile an acre whatever is the newest and most widely available TLS one 328, okay, clack God, we're still almost done TLS 1 3 right. um So so anybody can join right.

D

So if you have an implementation and I learned yesterday of at least one more implementation that might sort of get ready or if done in rust, and so if you have an implementation and you haven't participated yet right, please come along and everybody can invite anybody else to the slack channel or you can talk to mark and me. If you don't know anybody, there's public servers, so most of the implementations actually have a server out there, that you can talk to an inner up test and we're using this pretty widely.

D

So, if you stand, one of those up, people will talk to you and or try to talk to you about quick and, and we sort of do debugging on the slack arm right. That is basically all I had for a key phone event. Unless somebody has something to add.

D

All right, next on the agenda, we have the editors update, I, don't know who of the editors is presenting that or all of you I.

D

Sense, a certain sense, a certain fatigue creeping in here most editors.

H

Yeah I was like I, can't remember what.

F

E

F

H

Seems to working with hot issues. Alright next slide, so the editors went through all the issues. Yes, all of them at least not well, it used to be all the issues back until people started creating more of them.

H

We tried to tag close or a sorry, almost everything so quickly to issues or issues that we don't think are in scope for v1 v2 will happen, and these will ideally be in scope for that, it's always possible that something gets put into v2 now and gets pulled back. There was no rules, it's also possible things get put into v2 and by the time we ship v1, we decide we don't care.

H

Parked is considered non-blocking, but is something we will re-examine before we ship you one. So there are some things that are a wait awaiting more data. Some things are winning more implementation experience. Some things are just waiting and someone else to care more than any of the others. Do I think that covers most of them.

H

These discussion is we really want to resolve this soon, so we have slides coming up to hopefully touch on all those and close is yes. We there believe it's closed or it's not really an issue or all such so, if you disagree say so, which some people have. So thanks a lot.

H

So these are items to discuss on the list. We're gonna run through them pretty quickly and unless there's a clarifying question, I think we'd like to to punt on actual Russians to make sure we get through all so next slide, so fixing each to be priority for quick.

H

Currently, the HTTP mapping uses stream IDs the quick stream IDs to be clear. It does not have its own stream IDs. The idea is to add request IDs to the HTTP mapping, and so there would be an ideal at the HTTP layer as well as at the quick layer, and they wouldn't necessarily be linked. The motivation is HTTP. 2 allows you to have phantom strains in priority and quick has no way of creating phantom streams, and so you know, having request IDs in the HTTP mapping would allow this.

H

So there may be other solutions to this problem, but there is currently a problem with priorities in HTTP mapping, HTTP to queries back to quick that there are some features: the this phantom stream, in particular the you can't, can currently simulate and quick so and yeah. The idea is essentially to propose to extend push ID to all requests. So next slide connection ID privacy. Can we encrypt connection IDs? Yes, but it will hurt a lot.

H

So we've we've talked about this quite extensively. There are options. They are technically feasible in some circumstances, under some assumptions, but they're all either they're, all pretty horrible in some way shape or form, to the extent that it's not clear, anyone would be willing to deploy any of them.

H

So we talked about this a fair amount, but you know sometimes someone comes up with some great idea, the blue, and so if, if someone comes up with a new credit idea, we should reopen this, but it is currently open. But what needs discussion so did you want to add anything Martin next.

I

H

Priming the client with the connection ID for 0rt. So currently, when you have a zur RTT resumption token, you basically still generate a random connection. Id whatever you'd, like is a client. This would say when you do 0tt come back with this connection. Id one motivation is, it makes it easier to the limit replay attacks, because you know, if you, you know, have various routing infrastructure, that kind of Maps a certain ranges of connection I'd use, a certain machines. All of the replays would end up hitting a small number of machines.

H

Potentially it's easier to prevent and detect. Ddos is and other similar things. It might also limit some other types of attacks. I haven't really thought through, so it's possible to have a new session check session ticket frame and include a connection ID in it. That seemed to be kind of the most aesthetically pleasing option of all the options.

H

It does require an even wider interface between the TLS library and and quick which we will discuss later, but it makes it pretty clear that if you come back with this session, you know this is the connection ID. You should use yeah, so next slide ah get back. How far do we want to diverge from H back.

H

Mike, do you want it? Okay, I'll just run through this, and it do we have. The proto Mike I can pass to. Mike is just use that one I give hi.

J

Allan Fidel, so we now have adopted what was called Q cram and we renamed it to Q PAC. If you missed that it is very in its current form, very similar to H packet. R uses most of the instructions, and there are a few places where instructions came in from HVAC can be used in one context, but not in another.

J

So there's a PR from Mike that redoes all the instructions to be completely different from H pack, but there's no more places where instructions don't make sense, and it also creates some more small compression efficiencies but they're pretty minor. So we want to hear from people who have HVAC implementations if they are going to implement Q pack. Do they want to share a lot of code with H pack or do they want to start from scratch, because I think it reduces the share ability if we adopt that PR.

J

So it's kind of pending that there's also a change in that PR for how strings are encoded and how the static table is referenced. There was a and there some other things like integer encoding buck, had a proposal about perhaps finding a more efficient way for for doing that and introducing a static table which is different from the HVAC static table. So all these would take us further away from H pack.

J

All with some goal in mind, so I think that the question we want to hear from people on the list is: how much do you want to share.

H

Thanks Evan next lend a homework section next slide, so we will be talking about this at a fair amount of detail later on, but to say the list: there are some issues with Acts and the handshakes that are some edge cases that are complex and kind of ugly and in some cases, actually can cause some undesirable side effects. I don't really want to go into all of them, because I think eckers talk will be a better time to go into it. So I'm just gonna skip ah to discuss now. Yes, what great?

H

So this is the one issue I really want to talk about, because I actually would like an answer from you. If you don't give me an answer that I might just like yeah, basically do whatever the editors and I feel is right, so you know now it's time to express your opinion. Currently, both padding and ping instigate act frames and they both count towards bytes in flight so individually. That makes sense, but that has some problems. One is in the current state of the world. Padding and ping are redundant.

H

There is really no reason to use one over the other in the current spec they're, both one byte, they both elicit acknowledgments and they both come towards bytes in flight. The other issue is that there is no way to add padding to act only packets or to all a only packets. Technically, you could add it to some number, but those would also be immediately acknowledged in the side effects. There are fairly heinous.

H

So for those who want to pad their acknowledgments, I guess in order to provide cover traffic is, is the correct word I'm, not sure, then they see this as an issue, so it makes it easier to identify potentially like what the state on the receiver is from the size of the acknowledgments being sent.

H

But there is a principle here which is that if it instigates an acknowledgement, it needs to be added to bytes in flight and vice versa, and the problem is, if you add something to bytes in flight and then don't you know, caused it to send an acknowledgment in a relatively timely fashion. You will never remove it from bytes in flight and then you will get deadlocked and that will go badly. I mean it might eventually fix itself, but it's going to take a very long time.

H

So so it like unlinking those two things is very scary, and if we someone wants to do that, that's like a research project and a very questionable idea can I have one more slide Christian, but I will first. Is there a clarifying question about this one?

H

Okay, so therefore, you need an acknowledgement to remove a packet from from bytes in flight next slide, so option one remove ping because it's redundant, but that means you still couldn't add padding to all acally packets option. Two is make it so padding does not instigate an acknowledgment and does not count towards bytes in flight.

H

So that means you could send having only or padding plus AK they wouldn't count towards bytes in flight. At congestion. Control, however, is hard and adding padding to acts makes the bigger and it could potentially make at congestion control, actually important a post you now where we hope it's unimportant, so that would be the probably the largest negative and questions and helmets go for it. Hello,.

K

Yeah Christiane Rita mom I've, been discussing that I've been supply. I mean really surprised when this idea of acting bad came in I mean I'm still not that impasse in my improvisation but I think this business of connection of causation control is video. Red herring.

K

Congestion control is something which is pretty much selective and selected by the sender. The sender knows what kind of connection control strategy they apply. They do that in order to make sure that they are sending the right amount of packet and on server. So if a sender's connection control congestion control strategy requires that whatever padding they added, we act it's extremely simple for them to, instead of ahead of adding 12 and 56 pads to add one ping and 12:55 pads.

K

So the sender as if you have the dissension in big and bad the sender that requires value that requires congestion, control acknowledgment can Canada ping, it's an implementation issue and we could specify that. But at the same time, if you have a pure part, you can use it in arcs to basically hide your traffic, so I'd like some scene at option to with it, with a caveat that, if you, if your partition control, requires that you are well just better ping.

L

So I think the only observation I want to make on this slide is that, if the purpose of the paddy nurse, the sometimes purpose of the padding is for cover traffic and it does not impact the congestion control, that would seem to be observable based upon the congestion controllers behavior, and you can probably just manage to subtract out the pattern without decoding the packets, which makes it not very useful as a tumblr truck.

D

Patrick, we can't hear you up here because the speakers all face that wave is.

L

Everyone yeah everyone's really loud when I was sitting over there, okay. So the observation I I said was that if the titular notion of padding is that it's cover traffic and that if it does not participate in the congestion control, that's probably visible in the congestion control behavior of the sender, and you can do a lot to determine how much is padding and how much is traffic and therefore its use as cover traffic, is probably fairly minor.

H

One note on that is I, think and I could be wrong. I think the idea is that when you send an acknowledgement, it would always be a fixed size, like you'd always said, 40 bytes of payload, and it would be a mixture of a cross pattern and so.

M

D

That it's the data sending bit that leaks, the information.

N

Gen-I and god I just want to repeat for the record that Christian V Thomas said condition: control is a red herring.

N

O

We we fell flat. This.

N

Is a transport.

P

N

I'm, actually not going to respond to something I that that that Christine suggested, which is to add a a ping bite, there's a problem in doing that as a policy, if you, if receiver of data, wants to pad acknowledgement, packets, always and also counted towards condition, control and therefore adds a ping frame in there as well, both if both sites do that as a policy, then you're screwed, because now you only if you have acts going back and forth all the time, it's tricky to get this right, that's sort of the gist of it.

N

If you want to count this towards congestion control, it becomes really hard to get this right. So I.

H

Would kind of, in my mind, like restate another way of saying some of the things that Christian was saying and seeing like that resonates with people which is by making padding not count towards bytes in flight? That means that having in paying do become different, and it gives the sender the maximum amount of different of flexibility in how they want to decide which packets should be acknowledged in which package should not be acknowledged.

H

So, in some sense, like gives the sender more options than they have today, which current with their options today, they just can't can't achieve.

Q

You could have been even so: I I.

P

Do agree that padding should probably not be.

Q

Part of control, because you have to take into account that you should probably only use padding when you don't have any other data to say so, your data sent should be your data range should be really low. Anyway, you don't want to send like a huge amount of padding data. What you probably need is to take more a take the recommendation. We usually have for low bandwidth. Udp traffic put a rate limit in there.

H

You know we we could I would be happy to it's possible that if we do that, we should do that as a addendum to this and and but it's a good suggestion.

K

I propose I, do not propose to not count padding as bad but in flight I do count the padding bytes as bytes in flight. It does not follow that I have to acknowledge each and every packet that has apart I mean in order to meet your requirements. You have to make sure that when I act a lie some time to time, but it doesn't look like otherwise, then you could not be on it on just an arcology.

H

Yeah, that makes me pretty uneasy as a recommendation I'm not saying an implementation.

K

H

K

That implementations are trying to do something crazy in order to screw the guy. There are 25 different ways of doing that: I completely.

D

Agree so we get we gotta cut the line after journal.

K

So basically I would say the flexibility and clear stuff is good and I have some trust in the implementation. That's all.

R

Their problem, so I guess it probably just will be understand what padding is so the thing padding is absolutely necessary for is to pad out the CH into the initial packet, so I can make 1200. Now. You might also think padding was for whisper making pact aside for fading traffic analysis and that's what we thought we didn't tell us 1/3 um the the when.

P

R

The reason we did it that way was because we thought might need a facility. There was a generic facility, but that way under application control, because the conclusion was.

P

R

Possible to generate plausible looking, you know, covered traffic or packet size patterns without the application being very involved, and so and 1:30 like we had to like. Only one. Only only one.

P

R

Do this, which is basically like all we had ways like this all we had was like the stupid. You know um you.

P

Know the padding.

R

On the ends and crypto um so I guess so, I guess the question is what is padding for here? It really is for cover traffic, then it's probably better thought of as a favor that, through transport is doing to the application, in which case you don't want to be in which is really already counters. Bytes and I want to be just like a frame type that basically just sits there and like it's like, as if the application would wanna know every operation have them that their own way of adding account right.

R

But this is a netbook. It's a really, not a transport issue, the application issue at the end of the day, and if we need.

P

To have to some kinds of padding one for.

R

Like the CH one for the application that you guys, have you fine if, for some reason it's confusing, though I don't think it probably is, but.

S

Again, I guess my.

R

My basic thesis is: this is really like another application daily message, it's much more like that better than anything else. So.

I

Mountain Thomson I came to the same sort of conclusion that Patrick did about the size of acknowledgments.

I

The concern with the second one is that we start sending lots of acknowledgments and they're really really big and they actually congest the network, but we're not accounting for the public. That's the real risk here and to Mary's point I think we can probably avoid that by simply saying that we can just not send them as often there is. There is potentially value in hiding what acknowledgments.

P

I

Hiding well so it's actually more difficult hiding. What acknowledgments you have is impossible, potentially from someone doing trapping analysis, but hiding the distinction between an acknowledgement. Only packet and a packet that contains real data is extremely difficult because of what Patrick was pointing out with respect to the fact that you can observe the rates of packets that are sent in the fact.

I

The fact that this is the last packet that someone sends in some cases is often quite revealing this, the some patterns, where it's it's potentially plausible, that this would this work out, but not so much so. The actual value we get from padding is pretty long and I.

I

Don't I, don't know what about the same movement into at this point. Acts aren't that interesting, because in in theory, the person doing traffic analysis has seen the packets that you got and seeing the packets that you didn't get and can make some sort of assumptions about they're all sort of acknowledgments you generated so.

H

It's about anger, I tend to agree with Patrick's and our needs characterization that, like I, think hiding the difference between acts and real data. It seems like I, don't know whether that's not useful, but it seems if the purpose of padding is to hide like real data transfers and introduce shadow traffic, then maybe we can characterize padding is more like meaningful in the context in which it's used. For example, it's used in an a call, a package. It is considered to be like you're trying.

P

H

A crime, so it must be treated as if it was not without congestion control, whereas if you're sending batting only packets are sending padding inside stream data data with returns mobile frames, then it must be counted towards congestion, control and act as if the rules same rules that you use for first stream data. And if you get an act, you should use, treat the padding as if it was act as if it was pure act data and so that I think that seems to provide the most value for me.

H

So you're so interesting, like a a which is a cross. Padding does not count towards congestion control, but everything else does right, so change a cross padding as Burak. So.

D

I want to inject the stupid that you have you, so you could include redundant ACK information and ACK only packets to make them bigger right, and that would not count towards congestion control and it would not be padding problem is that the current act format does not allow us to include.

D

Well, you could send it multiple copies of the same act, block.

N

Denying got I'm I think this there's actually I'm coming around to seeing or Kristina's trying to point out, I think it's it's. It seems reasonable to count padding towards bytes implied, but not require an acknowledgement for them, because a center that chooses to count that does count them to us. If the sender is all counted towards bytes in flight, a sender that chooses to send actress padding frames can also choose to send an additional packet periodically to evoke an act from the peer that gives it enough information to keep moving the bytes in flight forward.

N

That's generally adequate for a center. That's choosing to do that. What this tells me also is that all we want to do is allow for this flexibility to remain at the center, not have to specify it ourselves. I. Don't think that we should I, don't have a strong desire to do this, but it seems to me that padding ought to count towards by simply just because of the nature of what it is all that we choose not to count loads bytes in flight again, because the nature of what they are.

N

They don't fundamentally evoke acts and they they have a size limit, the padding can be used arbitrarily and you could have a packet. That's ten! That's 9/10, padding in just 1/10 actual information, so it seems reasonable to counter towards bytes in flight, but to leave it open about and not to instigate an ACK and allow for the sender to send theoretically a window update or a ping to get an act to open up its bytes in flight. So.

H

To be clear, you're I mean I'm, gonna, say right now that that is possible, but that's a lot more complex than I would like to recommend for, like most users and everybody.

N

Should recommend if.

K

A sender wants.

N

To do this sure a sender will have to deal with that complexity. Yes, now you have to deal.

H

With it in the spec okay, as long as that's that's, my big point is like in the recovery document. I need to write text that I think, like the vast majority of population should be using and so like. We need to make sure yeah the.

N

Vast majority of the population- really, we can suggest you know by adding an ACK frame by adding a packet. That's actually will have complexity in this sort, but we don't need with that complexity. In this document, that's I think adequate for us to say so. We.

M

Don't have to deal with the complexity.

N

Of what happens in.

C

Question the mic alone was closed. Can you keep it really brief? Yes,.

K

I just want to point to that. We are also claims that are not act like to pass challenges. For example, that's art: how can you the text said? The patronage is not acknowledged. You are sending.

P

K

Fast response inside I.

C

Think we need to move on we're getting overtime thanks.

H

Oh wait: there's there one more issue.

C

No, that's the end of the deck did-did-did.

H

We want to have a Hummer, something like I sure I I want to write something up here and like the current status of is like, but.

I

So can you formulate the questions? I'm gonna, formulate the questions. We have option one. We have option two and we now have an option three and the option. Three. Is that that having frames count toward bytes in flight but do not elicit an acknowledgment which violates the principle that Ian articulated earlier, but we will. We will put a fence around that and say that if you, if you embark into this territory, you you're.

H

On your own, we're.

I

Not hoping you're.

H

Engaging in research does.

I

That sound like a reasonable formulation for those I.

H

Think those are the three options except I. Think savute also mentioned option 2a or four, which is two, but only make it so act padding by itself still countered spikes in flight AK and padding it's like special. So why not.

D

Ask you guys, with preparing one slide, that we're gonna show at a later point that spells out the options and then we're doing the hum later, rather than doing it on the trail. I know.

I

My my plate of people involved in this and who have an opinion is, is to think about this and think which ones you could not possibly live with and I. Think that's probably some resolution should use to draw the line rather than anything else, I'm, not hearing any strong views on things that are completely bad. So if, if people want to think about that, we can make a decision eka.

C

And now I've Chris gonna demonstrate his typography skills to us.

D

It makes the contents you're so friendly.

C

It's a cheap knockoff for stomachs and Google's fault.

R

huh Ronnie's Google is Google, it's come at Google sense right, so I guess yeah I sort of dropped the bomb on a list. A few weeks ago, I'm gonna try to tell the story and what seems like a logical order, which is probably not what's not the true historical order, but maybe isn't more, is a more reasonable order for understanding situation.

R

R

So as a Saeta logical order, um so I was gonna talk about like how things are currently structured and a brief survey of like some of the things that are making us sad about the way things are currently structured, a little bit of root, cause analysis and then a discussion of the sort of crypto scheme proposal that a bunch of us sort of worked on for a while and then finally discussion of like layering and DTLS.

R

So as a this is like quite the logical order, but it like helps understand sort of like the state of the option. Space neck slide so like this is that my version of like the quick recognition diagram, which we have anybody else's version. But it's how I think about it.

R

Like a my implementation, like at the bottom, there, quick packets, and on top of that, there's like the streams engine whose job it is to like make sure things get delivered and like on top of that, like sort of jointly sit like the TLS handshake, hasn't, got a special case application and then the application and the rest applications. And so this arrows supposed to be that, like, unfortunately, the TLS handshake has to like talk to like the quick packet engine, quite a bit flight stall.

R

Things like you know, you can send data, and here are the keys and that kind of crap, so I think like I mean that's like them, who implemented I've. Seen kind of look like this, although I understand suppose, is like much more cool. So next slide.

R

Unfortunately, so like the thing is that on the TLS stream, like just uses like the special stream stream zero- and this is like um kind of like turned out to be like a huge hassle that is made of a bunch of a super sad. So it's got a bunch of annoying properties, all of which kind of have the dual of it. Being this special snowflake and I, like the in slide, is like string 0, its special. So first of all, it's like there's really no particular order, but um I tried to group them.

R

The first slide is supposed to be things about, like date and the second size movie, things about acts but, like frankly, they're all kinda intertwined. um So first of all, sometimes true. Zero was like encrypted and signs it's not encrypted. So like everything up like the NST is encrypted. But then the entity is like um it's not encrypting the nasties encrypted. So like hey. This is just dumb and be like. It causes real problems.

R

When you want to retransmit because say, like the say like say, like the UM the you know, the s Finn gets lost right, I'm, David implementation, which sends s Finn and St concurrently, which is totally legal and like the S fing gets lost, but you've already cut over into like in in the like writing mode. And so now, when you need to retransmit, you need to retransmit the S Finn in the clear with the NS t encrypted. So that's kind of a hassle.

R

um It's a hassle, Edition wise, also hassle, because it means like a special like a Fordham to the TLS stack that like says. Listen these bytes by the way are like in the clear and these bytes are encrypted, which is like not a stack that not thing saying. The stack normally wants to give you um and you can't see it by inspection by the way, because at this point we so cleverly hid like the content types that you dislike them crap like encrypt the data. So um that leads me.

R

The second point which is like this requires like an incredibly tight amount of coupling with a TLS stack or the TLS deck like basically like it's like TCP or it's easy put a list over TCP is like really restate forward, like basically you like bring up TLS and like at some point, the stack says, you're ready to write, and you start writing.

R

That's not true here, because um because if the problem is you're also like sending things at the same time, and so you need to know like where's the boundary from the flight's exactly what stated the stack in depending on your doing, HRR, there are multiple round trips, and so, like you need to know, for instance, is the first thing that comes out of the server's mouth. Is that a server holo or is an HRR?

R

Or maybe it's a stateful hrrm a it's, the stateless HRR and all these things you have to know and make sense to the system? um Users also goofy in that you're like exempt from flow control during the handshake. You want the hint you to finish, but then you're not exempt later, and so now you can like you can like overflow, the could the flow control window now you're like a negative territory which is shitty.

R

um This is sort of like a trivial thing but like nevertheless, if he's of annoyance to me, like TL s13, his own notion of like when the zero RTT boundary is when you're like sending like Zeta until at some point, there's directive T. But although we sends the RTT data, we don't send it until s130, RG c we're sending quick cor TT and so, like the t, oz stack like sends the smack stream data thing, which says how much zero T tau can send.

R

But the way it works is this is us an infinite amount of zero, our Chi Chi data and then there's some other thing where, like you tell the or you tell the quick stack, how much data you can actually send um and oh by the way, till I'm three also has this thing. This is I'm done, sending 0 TT and like the next thing will be. You know. The next thing will be like handshake packets.

R

You still have to send that because that's the only way to make sense of the things in the TLS layer, but it's like only doing that because we're not setting any zero T TD. Actually so that's kind of stupid. um Another minor thing you can't like bundle encrypted and unencrypted eight in the same packet, which is really annoying. If you want to do like zero duty, because you want to send CH and then whatever was going in like in like zero to T, um you don't want to do that. You can't um now.

R

The good news is maybe like the saving grace that I guess is. Maybe you have our like cruddy m to use your like 1200, so it'll help that much um you know, select a bundle fin and other things too, um and it's like all. This is me and by the way like. Not only did it like know, a lot about the TLS stack is doing. You need a like a lot about crypto like a pretty substantial fraction, like the TLS record layers like recapitulated in, like the quick implementation.

R

I'm like just the other day, like I, had like copy out the hkt of expand function from Ming from mint and put it in mink, so I could like uqh KDF expand. So I mean again this isn't like a nightmare, but it's kind of pretty yes um and that's like so.

R

The AK rules are just like baffling, you know, sometimes it's but never supposed to act, something like never supposed to act. Anything at a higher tier of encryption than you currently are. But again it's put you in a position where you're like trying to send after in the handshake and like something seems: no parasites are encrypted.

R

So it's confusing when you can somewhat um Christian point at this nice attack where, because you're, showing sequence number space in AK space, it's possible to get in a situation where the attacker sends you a unencrypted packet that is in the stream space that the client, if your the client would have been sending for a cipher text. And then you lacked that in the unencrypted packet and at this point the client thinks you send it.

R

But you haven't gotten it because, because you told you that encrypted so um that's a mess you can also- um and you know it's also really easy to have situations happen where you get contradictions between the acts and the handshake state. So the easiest version of this right is the client send CH and the server sends SH and for some reason the server does not give you an act for a knack for the CH.

R

Now you know for a fact that, like that the server got the CH, you wouldn't accentuate SH otherwise, but like you're still like retransmitting, this CH madly, until until the accent- and this is a real problem with this- with the C fin, where this actually comes a real issue, um so you can get um Soniya, so you can get in these kind of a canary states and finding.

R

This is a problem that I think Martin seaman raised where the C fin reliability is a problem because they again it's because of the various crypto tiers, where you're supposed to be ignoring data is unencrypted. But if the act for the C thing gets lost, then he's retransmitting to you. We just drop this down on the floor. Cuz, it's the wrong level encryption and now you can tack it properly. So um this again, this is kind of like a pain in the ass um and find. The next slide is like extreme.

R

Zero is like in people's code, like everyone's code is like littered with these special case situations where you have to handle stream. Zero Martin likes ears laying from Packers code um from moss quick, but it's not just like moss quick. um You know, I, like Martin, rewrote like the mink.

R

um You know, string handling code, there's probably like there's like an explicit value in like the connection function, called stream zero, don't like he's constantly referring to and then like all the other places where you want to iterate of the streams or it's like exceptions erode under that.

T

R

So which, by the way, has been made much worse by euni-unni by died because, like you need streams, zero, it's like totally that's a totally valid. um Okay. um Next slide. So, like you know, we're kind of like like I had this lie, which I didn't put in. There was like this, the shame spiral of like what happens, which is like you know. We like we. You know we find some problem and they were like.

R

Oh well, just special cases problem and will like me, another affordance like looking Els stack and then you feel shame and then you can, over the shame like when the next thing happens, but I mean the real source.

R

The problem is this: we're trying to set up a reliable transport so that we can like carry TLS which depends on a reliable transport, but the reliable transport itself partly depends on TLS and so like these things are independent and it's like, as long as that happens, you're consciously enough problems and I think there's general agreement on that point, and now what we do at that, like a different question, but like there's general agree that your walking is worse, the problem so next lied so I mean so the the general structure break the dependency cycle is to somehow separate the transport.

R

The crypto is using enough from the transport the applications using that the trip the crypto transport can function properly, even while the application transport is completely spun up and like this question mark question, mark question mark is precisely the source, the problem that we now have but like. Hopefully, if we do those things, we have profit so neck side.

R

So um so this is the part where I'm like telling the story in like the natural order, run the true order, which is like that I, like said like well, why don't we do some really radical thing and then we and then a bunch of us um with Ian I, think being this together this, but a bunch of us sat down and tried to like think about what so, like the less radical thing that would work, um and so um there's been a bunch of discussions of this or general idea, um which we I think I'm gonna like to say like what we call it window they're calling this or we not how to call it that I got a call that okay, do it well, okay, so um so the idea, the idea goes under the name of like um crypto streams and crypto ax, which is you can imagine, immediately became cream and cracks.

R

So we probably will be calling that if we.

K

P

R

God yeah, that's great! Thank you. So um so general idea is like pretty straightforward, which is that you stop having like you, get rid of streams or overcomes a regular stream, and you have like. Essentially, you replicate the streams or frames into like crypto streams frames and like different frame ID, and they probably do have a stream ID in them.

R

Otherwise are basically the same, and you replicate the AK frames in the crypto accra track frames and then, basically, as you can see from this diagram, like everything, goes in like the TLS handshake like uses that crap and everything that goes in the application handshake these other extreme stuff, even though the otherwise basically identical, um and so this lets you separate out, of least in theory. um You know the data um and also the acts.

R

um um You still need this goofy, like you know, this can figure out on the side um and one of the things I think we had. We had not consensus about, but has been.

R

Also, imploded is separating out the Crypt actually having two crypto streams and I guess, maybe to corrupt relax, I'm, not sure because of the post handshake data, which has to be it has to be sent encrypted, and so um you know yeah you're, not that over the boundary is, but you could you could either have you know one equipped or even cut it over? You can have two crypto streams and that made the boundary clearer, so that was also flows a.

S

Clarifying question: if, if you were going to say in the mailing list, you you were going to send a PR and how this would work if we stayed within the the current framework? Is this your idea here on slide nine of what that that PR would be represented as visually yeah.

R

Well, I mean you know, we asked you are obviously but yeah I think I think what I would say is that this design, plus a couple other things you floated, is probably the strongest design we have for staying roughly within the current structure, but trying to address to may the problems we can, but.

S

Okay, then I I think maybe we want to make a larger distinction between the kinds of streams that you're going to use to create crypto because you're, what you're fundamentally doing is saying that the crypto stream is a special case of a reliable stream, which is now part of quick and there may be other uses for that underlying reliable stream. That want to behave this way, even though there are other ways of creating reliability and regular stream. I'm.

R

Gonna need you to scroll back 30 seconds said again: Ted I'm, sorry! So.

S

I think what you've done is to say that these crypto streams have a fundamental property of reliability, which was the problem you had before bootstrapping a TLS on top of something is unreliable and I think that fundamental property of reliability has applications outside of the one you're using it for, and we might want to generalize it so that you can use this form of reliable stream in certain other cases. Okay, so I think everybody else hates this idea, but I write.

R

Well, I guess I would say about that is right, I guess what I would say about that is that the is true they have the minimum property reliability, but the other property they have is exemptions from a whole bunch of other rules that quick actually imposes those do otherwise, and- and so it's dangerous for application should not be using them. I, guess or I would say, and they are.

S

Set from full control.

R

S

You're going to tie the fundamental properties of old-style TTP reliability to always unencrypted, then I agree with you. You never want to use them for anything else, but I think that you're you're creating a different marriage of convenience that is not required by the fundamental underlying so problem.

C

That you're trying to see it seems like we're moving on to discussion. China is your question clarifying.

N

I think that I think of the descriptive stream frames other than captive streams. I, don't know if that's what you meant to say or if you were deliberate in saying crypto streams by.

R

Not sure I appreciate the difference.

N

The difference being that people, then then it's basically, this is just I want to avoid the question of. Is it? Is this just stream 0 again, because it's not a crypto stream, we're talking about really the that's an well nation question of how exactly you deal with those frames that are arriving well.

R

I think I think the relevant point is that who mate? What makes them differ. I guess the relevant point. Drivers are the naismith stream like. Is that the someone's responsible for assembling the frames back into a coherent looking correlating.

C

Of sequence, data yeah.

N

C

So that was a clarifying proposal, not question. Okay,.

R

Okay next slide, so um it's like, as I sort of said. This is probably like the minimal change that does much of anything at all, um so I think it's all the following problems, I think reasonably well, it sells the flow control problem because you just like exempt thing from stream zero and you don't have to like process. It washes it. It provides some cost back clip um query button to encrypt in.

R

What's not the cost of that, as I said, easy makes it's like even more invasive, like widening of the Thomas interface solves the whole sort encrypted packets, because you would just basically say if we ever receive a a crypto stream. Ak, sorry, a regular if you ever receive a crypto stream AK for a packet that was sent and on the crypto stream. You freak out and so that'll cost connection information, as opposed to as opposed to holes.

R

But we already know how lucky we are to determine a detection as a man on the side, and it makes the acronyms more straightforward again because basically, things that come in the crypto stream yeah, the crypto AK and things that came in the regulation- graphing regular rack, um so you tagged right- um and this has some similarities. Obviously, with like the detail: SF bak ax, which cut out the same property there's other problems like I had a long list this, all some of them as I, said um I.

R

Think there's there's some discussion of of solution for the sea fin um reliability problem. It was called handshake done. um The reason I have it like a second bucket is a cos, a cos. It's like a different situation in B I, don't like it as much so his other problems. I, guess um you know we could here try to solve or we could live with them.

R

I guess one thing one thing I should say before I like show my next couple, slides is like I am not in any way saying one could not build a version of quick without like doing any of this crap. Like. Obviously you could we have like working implementations. We can just keep banging on it long enough, like we can make it work right. um What I'm saying is that um we're making a budget we're doing a bunch of special anointing special case saying this regime spiral?

R

I was talking about and it'd be nice to get out of that. Shame spiral before, like you know, for weeks with the product, not that, like not not that this is like um of these things. All right deal breaking things we could not possibly protocol about fixing.

R

um So my agreement isn't that so if people think it is and I retract that um next slide, so um this is like the slide you saw before, but like all, it has is like a big box around like new things right and so I guess the into which so like it came to me at 4:00 in the morning.

R

I was thinking how to talk about this that um this morning, by the way so like that's, why I'm I I'm, probably more destroy than usual like how do we get into the state and the way you get into this state is and so, and so the problem is like I said the very bidding we have like the transport, and we have. We have the transport train. You set up the crypto, we have a crypto itself right and um and the in order to make that work properly. The crypto transport needs a lot of knowledge.

R

Birth through car through crypto is doing, and so they have to like really have this bear hug and so like. Basically, that's why I put on the box like this, and so basically the you know what this crypto strings for fastings guys is basically rip out. The parts of like like remove take the parts are quick that, like responsible for doing the transport, the minimal transport you needed and like clone them over and bear hug them. The TLS and I should have.

R

The table listing things about each other right, and so so that's this is so so like this is what you have to do to make this to meet, does not suck so somewhere. This has to be super wide boundaries, so, like the other way to make us have right balance. So when we grind boundaries like clone off at the Creek parks and like make that boundary porous the other part of the baton, we're ready to do it next slide. It's like. Oh, haha it's like it's like isolate a lot crap into his own thing.

R

Hence like DTLS right um so um so, like the blue parts. Obviously are things that are new.

U

Some people took some you times that please take a bit more yeah.

R

So um I said this in the list, so I don't think explaining. What's like what I'm suggesting is particularly difficult, what I'm suggesting is take the parts of quick that involve crypto, throw them away and like run the project with and vote transported, run over TLS DTLS and that's like basically what I'm proposing um so in this slide at least, and so the primary signal you need now is this arrow ready that says like you can now write data? That's basically that's!

R

Basically the major signal you need next slide, so I mean this is like obviously a much much bigger change. The good news is like mostly deletion. This like went through, and it's like involves like ripping it like the leading a bunch of code like all pretty much all quick, TLS and modest chunks of crude transport on it does revert. Some of this isn't earlier and Ian points out to me that we previously talked about having crypto at least somewhat so to flow control, and now, of course, we totally understand full control.

R

um That's not really a big deer, not gonna, send very much data anyway, but it's a decision. um You wouldn't need um some small change. The details 1.3, which I can talk about a little bit, um I think the primary issue here is: we spend a lot of time, hacking on the quick pack of structures and in some ways, they're better than the defect structures and was there worse um and so um and and there's a more advanced, connector ID structure, though actually kind of got borrowed from DC law societies.

R

So um so, basically, like uh you know, we would have to figure how to how to do with that problem by probably got that crap and into DT LS, which are mostly the matter of copying and pasting. um The good news is like essentially every problem over on the first three slides like this addresses. Maybe some really new problems you don't know about but addresses all those problems um next slide. um So, oh, this is I meant to show, but it's like roughly it's the same anyway.

R

So that's the good news and it says see if what I don't understand, I told you it's 4 a.m. um and the other thing I should mention is like like we now have like several partial implementations of this and I. Can in like the cases I'm aware of in every case is amended, I can evolve like it's bleeding a crap kind of code, though I think in fairness.

R

One could say some of that code are using the DC LS tax or it's not like you know it's not the code just went away, but it like went somewhere else and I think I think on average probably want to wait um next slide. Where's the other blue sheet.

D

We somebody else brought it up here, I think it's isn't lying there. That's the.

C

First, one there's another one: we.

R

Have two people come up anyway, so this so this slide might be might be called like things that are like less they've made. People less happy, though um so obviously, like DTLS, woke up become too quick on wire image. um We have a lot of flexibility in that, um because I sort of stuck my foot in the door of DTI last night before went out the door so um right before they closed it.

R

So um you know ultimately um I think we could graft, essentially all the quick wire formats on to detail ice if we so wished, um probably not exactly but like it would get very, very close. um There's um if you don't do that, there's, maybe a small amount of packet expansion. If you do do that, there's none um the UM I making the I just said. I said the interface between detail lesson: quick was very thin. It's not quite it's there's one more thing.

R

Besides the arrows, which is you need to have access to these details, packet number, because you want to use them in the in the axe, and so that requires basically being able to ask the question: what's the nest packet you're gonna send out and what was the packet was the sequence ember the pack of the Cambridge came in um that's like very trivial, um it doesn't very little changes and, of course, you also need to screw with the axe a little bit to carry the detail has a pock um separately in the AK.

R

um That's actually now, if not not so different from having the separate act frames, you have to do to make crypto a quirk um and I think the other thing that, like obviously, is true so I should just say it is like the details spec and like the implantation or like less mature than duty law, 7.3 spec in applications right. So that's certainly true. um Next slide right, so I think, like so two things. First of all, like everybody, you can't even talk about the one I'm going to talk about.

R

If you start they want to talk about. But what I like to talk about is like not layering but architecture and like what's the right architecture going forward and um and like how do we make the decision? How do you think about that decision properly in a sensible way and like um so you know if people think this is like folding architecture I'm, like totally like you know, I'm like happy to hear that from them right, um I think I've tried to make the best case I can for, like.

R

You know, first of the various options we have, or they some inaccurate case. I can um so I guess, but also I. Think, like the optics of me, standing up here, pitching like one thing like kind of shitty. um So you know Ian did a really good job, I. Think of helping us build a consensus on some other options, so I was hoping he would come up and likely to stand here together like we talked about the obviously rational people and, like worst case all that clock really.

C

You're telegraphing your strategy here.

R

H

So I want to give my my take. I've talked about that cur. What about about this proposal over time and I?

H

Think my take is number one I think you pointed out some issues that when I went back and looked our code, we're definitely issues that, like could be improved upon like having the unencrypted our streaming zero behalf, unencrypted and half encrypted is totally annoying and the flow control change is totally annoying and some of the issues that were pointed out are just new issues that I hadn't really fully considered the complexity of so I do think that we we really should like do something and I think there's the status quo is, as Decker said, like workable, but probably not optimal and I.

H

Think we can. We can do better. So you know on a personal level, I'm not like at all up for swallowing the entire, like. You know, DTLS proposal, all all at once, as I said in the list, but I think something like of the form of these like cryptic screen frame, crypto akram, pretty much solves all the issues that are outstanding and there's a pretty plausible. At least concept I will say that, based on my experience with the quick working group, I think almost anything. We do there's certainly a a larger change.

H

We make the more the quick working group will just beat it back into the shape of whatever the quick working group seems to want. So I don't know, but we seem to like one slide. It was like. Oh, we could just take DTLS here. On top of the crypt, are the quick framing layer, yeah and and I was like well all the quick working group is gonna.

H

Do is be detail us into the exact shape of like whatever the crypto stream for impulse like crypto AK was or something right, I mean so I do think that there's a certain sense in which you know protecting the system. A lot will actually just end up being a lot more changes in the long run because won't perturb it a lot and like move back I, don't know, that's my take on like how the group has tended to work so I, don't I'm, not a big fan of like massive perturbations, but I do think.

H

We need to need to do some work here and I also, don't actually think we're going to solve this today, but because.

D

I think we're good working group feedback and guys on the microphone also be brief, because I expect the lines to Google and English before quickly.

R

Yeah um I mean so like when they offer to say, is you're doing. This is like one way to think about like actually, this sort of earlier diagram, with crypto streams, is like replicating the DTLS reliability. Machinery like we replicated eg, less reliable machinery over TLS right and so like I, said sorry what you just said right.

H

Whereas I was thinking of it as I already have these reliable streams and so I'm gonna reuse, the code I have instead of like implementing GDLs as well. Right so I mean part of the perspective is like. If you only have quick than like, bringing in DTLS is actually bringing in a net amount of code and adding like more complexity. But if you already have DTLS that nature seems simpler to do the opposite. So, okay,.

C

So we have a half an hour to discuss this I think that's enough time, but please keep it brief. Phil.

V

Han Baker I, like this architecture, I think it is the right architecture for my problem.

V

My problem may not be quick, though, in that my interest is web services and quick seems to me to be very much aimed at HTTP type things, and it may be that we could apply this approach to the web services problem, see what it looks like there and then see if it makes sense to apply what is learned from there onto quick in that at the moment, when I look at quick and look at running web services over it, it is really a high barrier to entrance right now, it's difficult to understand what the drafts are doing or how I would implement it.

V

The DTLS approach looks a lot cleaner to me.

H

J

Brian Trammell, so I was before I saw these slides I had a kind of this screen. Zero is kind of a key feeling. The screen zero is really.

H

Really really icky right, it's it's it's bad, um so we have to do something and it's gonna look something like this. Like so I think this when we started quick in the IETF, we had this idea that we were gonna have sort of a c-shaped architecture where there's quick above quick below they're connected to each other and there's TLS in the middle that was kind of the research iasts idea. We had and I think what we're finding is. That's not working, so we need an architecture where we essentially do have.

H

We explicitly acknowledge that we've got two different transports running right. Whether one of them looks more like quick or is DTLS is I. Think an orthogonal question I'll point out that, if we're going to go with this, it's probably a little strange to how the only non encrypted stream Xanax be called the crypto streams and ax. But that's a a you.

J

J

Maybe maybe not one question uh-huh. It's.

W

J

One question I would have with.

H

Respect to I also think that, like so in general, I think the idea that DTLS is the encrypted wire image for future transports encapsulated over UDP also makes a lot of sense to me. If there's not a lot of appetite for jumping into that right now is the. Is there a way to make sure we can get there right like? So?

H

If we do to this, do this TLS handshake grip has dreamcourt or acting on top of quick packets there a way that we can make the verge negotiation with respect to this work, so that we could move over to a completely detail as wire image in the future.

H

The do TLS type bytes are I mean we we'd have to work. That out, I mean.

J

H

Question another question is: does this make coexistence with G quick, easier or harder.

H

Things you don't have to answer that right now, yeah.

P

I don't know, I haven't actually.

H

Thought through that yeah all right yeah that that should be so so there's there's two wire images on the table. Right now we might be putting three wire images on the table. We need to make sure that we can move among.

R

H

I think so, and that's a longer discussion and there's a lot of people online, so we'll continue on the list. Thanks.

X

Mike Bishop Akamai, so I wanted to comment. This is way too low. Okay, so we part of our goals per virtual negotiation were that we would be able to flexibly move between lots of choices that we might make in the future that we don't know. Now we want to diverge from our current plans and one of those is that aversion implies your crypto protocol and we have agreed that for a version, one its TLS 1.3 or its possible successors.

X

If we change the wire format to be DTLS, we have committed all future versions of quick to using DTLS or something that pretends to be v. Tls and I. Think that would be a pity. So.

R

I think that's sort of true I mean so I mean it's true in some sort of trivial sense. But let me push back on that. Sorry. That was that you mean that way. um Like I mean so so I mean we've, so we've committed basically um a president.

R

We've basically committed that, like all future, things have to look like the current, quick framing ticket or whether in variants that are very, very narrow, right and so I think you would do the same, but cut you would do the same thing with GCLs, namely you just you just take what the DC awesome variants are, which are not to someone with a quickening variance and call those the invariance in this debt, and you would clearly encrypt the encrypt the initial handshake packet. So you'd have it.

R

So you have so you protect those as well Tom's, I, think I, think I mean I, think you would I mean yeah. Yes, if we truth, it be impersonating that invariant, but I think I mean, and you can call that I'm posting DTLS, but it's it's sort of not exactly.

H

Thank you, one, nice perks of the the quick version is it's like very close to the front of the packet. My understanding is that DT Ellis doesn't have that property. Well,.

R

Okay, so there's a think about that: take a step back.

H

Something like five bytes I can determine like.

R

Okay, so the quick short version, of course, there's no, however, has no Persian Gulf the um so on this thing, I guess I wish I wish I wish I'd caught into a spirit of full disclosure on that currently the DTLS um details.

R

Initial negotiation is in the clear not encrypted the first two, the first two frames are on are in the clear, and so obviously we decided to office get those, and so we need to have an office keishon format for those which we've just lift essentially directly from quick, and so that would have the have. The version number is right there, but that would be a new work. My point says new work, so that's why I meant by full disclosure one.

D

Quick observation is that the queue is still growing right, so.

H

D

Speed up, if you have any chance that anybody.

H

We're not draining the Quixote appropriate rate on that occur. What what I think echo saying is in some sense I would make that possibly could allow ETLs to fit in a future version of what to encompass DTLS inside of it, because we would essentially still be using the quick version to do first negotiation, and we could still maybe use that first bit.

R

Yeah, in fact, I mean we talked about saying that that several I think like like I, think certainly like, if, if the two sent to which the objection concerns are about the wire image like I, think it's a lot of flexibility around wire image. If we need to do at on like like I, know the people, let's working group but I'm, pretty sure we can impose whatever yrm as you want, as long as it's sane on them, but I mean, and that may I may about the issue. I no idea, but and.

X

Then my second observation is that it it feels like special casing stream: ID equals zero and special casing stream frame. Is this type of this type bite or this type bite, is semantically equivalent and really it's the differences between them? That solve a lot of those problems like it's. A stream. Zero is only ever since in under handshake I.

R

Think it's some love us true, but I. Think if you look at people's code, it's absolutely full of like special casing. The stream ID space so like I mean, if I had to make one change of one change only. It would be to merely take streams that are out of the stream ID space and call stream zero, because even that, like we I mean like like I, didn't like only one change that would that wouldn't make any authority. Actually she said he better be the code awesome or we're.

D

Gonna cut the cue soon yeah there was a plus one from Martin Duke to will Mike second point and and please be concise at the microphone. Okay.

Y

Mr. Dawkins speaking is the responsible lady for quick I. Don't have any questions, I have four things: I need to say really quickly. They are all once women's long. First I picked the chairs for this working group for a reason, knowing that there would be days like this you're welcome.

Y

Second I expect the working group to make an informed decision and recommend doing the right thing. Third I believe coming off. Tls 1.3 is a recharter, because the Charter is extremely explicit about that. That's not fatal, but we're not talking about Dorking with milestone dates, anymore.

Y

Number, four speaking as Spencer now I follow this working group more closely than I follow any of the other transport working groups. Sorry, other transport, chairs and I. Don't have a good feeling about version negotiation today and I. Don't have a good feeling about the working group. Remember expectations for how often we would roll version numbers I, think I've seen mailing lists traffic that went in both directions. Annette, you know like why not and will be on one for five years and that kind of that thread kind of dropped.

Y

That's the one thing I'm really curious about on all this, so I'm going what Brian said and now I'll stop talking, but I'm here all week, just.

C

Just to that last point, my impression from talking to folks is the intent is of most. Is that we're not going to wait twenty years or ten years or even five years for quickly I? Don't think that's controversial.

G

D

I got Victor after question that was roughly when he popped up Chris.

T

Moon I just wanted to second answers. Second comment, which is that we definitely need to make an informed decision. I think and experimentation is definitely a key to that Iker saying that some people are sort of working on this particular detail s architecture in it. I would like to convince more time myself to you, know, experiment and see what is the right approach? It's not entirely clear to me just by looking at this particular diagram or the.

T

What is you know that the cleaner is designed, but considering that we have a lot of flexibility with details right now to change the wire image if we need to decide size, but you kill use case there.

T

Certainly, if people can spare the cycles an opportunity to get the architecture right, hopefully without affecting the schedule too much and I don't want to comment on that, because that's kind of outside my wheelhouse but I would think this is something we should definitely be pushing for to make sure that the architecture is not, we don't short short cut, make any shortcuts with respect to that architecture. Strictly because of you know, scheduling reasons or whatever.

N

um July and go have I, think three points: I'm gonna be I'm. Gonna, try to be quick first point is I was thinking about what other. So this is the devil. We have the one in this picture and the other. The next picture is.

R

N

N

P

N

Devil we have in the devil. We don't. You know the arguments that you already state of that. So thank you for doing by the way. Thank you for doing this whole presentation. This was excellent. I think it was very useful and the exercise is very useful as well. The I it just occurred to me that one one thing that hadn't showed up anywhere is that packetization. If it's going to sit in DTLS right now, the quick short header has three packet types and that's based on the size of the packet number.

N

The packet number size uses the be de the the center uses, the PDP to determine how large a packet number to use, and so that's another bit of interface that will have to change. If we want to retain that efficiency. If we choose to discard it, that's fine but I'll remind folks that quick, a lot of quick is about efficiencies and losing. That would not really be valuable.

N

That's point one yeah.

R

So we spent we spend a bunch of time on the on the GTA loss, record format and I. Think like may some optimizations, which may or may not be enough right, optimizations um and so I think like like I uh I, think that the the front and frankly you know this is an area where I think there's working, probably nurses, a problem better.

R

The details, working group, if like people, thought that, like you know that og TLS has a essentially has essentially two header formats for the for the group, two header, one like a long long, long, sequence, number one, the short sequence number and has the only things to scott and the short sequence number was shorter and the long sequence number was longer, and so, if you'll think that's the wrong, does I it really says I enjoy stays, that's like saying, which is like totally like I, don't know like.

R

Maybe we should fix it right, I mean I, mean and honestly like I guess. What I would say is if people feel someone's design choices, even if they think the rest of this stuff's. A terrible idea. Please come to tell us and tell us there was the design choices we fix it right. Yes,.

N

We're started I'd be cuter pseudonym. What about the do? Do this design choice for the packet number say because I'd like to know how it's decided, but that's a separate matter, I'm just trying to point out that there are issues here that we that occurred to me now as I'm sitting here at the desk, and that's basically the the first point I wanted to make so there there are likely issues there, the one difference, those are those are probably about efficiency, not about correctness. That may be an important distinction to make.

N

The second point I wanted to make was that you were talking about the shame spiral. The shame spiral starts a little bit further before, and you know this because we were in the same conversations early on about how to replace quick, crypto with TLS or repls and, at the time and I'll remind folks again that quick, Kryptos different from both TLS and ETLs, in that it was very intertwined with quick. It was different from TLS. In there it wasn't a puri stream-based.

N

It didn't assume a stream based model. It had this tight connection with quick in that quick knew about the packets and quick Loney about it as well, and so there was a type integration. We chose to let go of the tight integration and try to replace it with TLS. That's where the shame spiral starts in DB. Ellis was, of course, not at the same place as it is now at the time.

R

Just if I can I mean, like I, was part of the conversations and I agree with this direction for a number of reasons, including the ones you're listing and partly cuz TT Ellis was like a lot less baked so like like, like yes, absolutely I. Take some blame here to the question. Well,.

N

I'm not going to pin blame on you and say what the bleep but I'm just moving.

C

N

C

Need to keep it moving. Sorry.

N

D

Behind you, we need to keep it moving. The.

N

Last point: I'll make it very quickly. You asked the question: what what's the right architecture? I, don't know that that is one I will point out that what we all care about here is modularity I, don't know that that's necessarily solved by thinking about this as layering or not I. Think what we're looking for here is the the porous boundary there you're talking about is the API and we are trying to nail down the right API and that ties to the fact that we've never used TLS in this particular way in the past.

N

I think it's a worthy exercise, because I think having a reliable transport running on top of UDP is something that's not going to end with quick. So working through this is going to be a valuable process here. The queue is now cut. Ushion.

K

We demo hi I, listened to your presentation, Eric and our bunch of things that I do agree with men. In particular, we have a problem that we have the same sequence number space in the handshake and in the data exchange and a two-shot is actually one of the root cause of the problems.

K

I I am very interested with this midterm evolution to propose, because one of the thing I like about it is that we can do incremental evolutions without losing the implementation momentum that we have, because, yes, they are forum that also about a dozen implementation interworking, so the phone are not unsolvable, so I would rather take an incremental approach in which we plug the good thing from these proposals and keep the momentum, but I have not actually seen the details of these with those twin proposal. Nobody has, as.

P

K

That should be the next step that we actually document that and see how it works right. That.

D

Victor was next and then you.

Z

Can you hear me yes,.

D

Z

Right so I wanted to make the two points in the main point I wanted to make. Is that so there are three pieces of infrastructure would have here. There is the crypto handshake, there is crypto transport and since race, yeah I'm, sorry very quick. There is the crypto framing and then doris transport and actively we accepted that they want to duplicate one, and initially we decided to duplicate crypto framing because it was easier.

Z

So fundamentally, I believe this is the right choice, because I worked a lot on blow framing and on transport and at some point I try to implement it stretch and in practice transport always requires a lot of fine-tuning. But specifically I want to point out. Is that Oh?

Z

The reason I would like us to invest more into that idea of just fixing the problem. Quick. As with a steel s, layering is because I believe we should not duplicate the transport.

Z

So I think that the current of threats, encrypt of X, is one good approach. But fundamentally what you want is you want same transport, but you want two different transport contexts. So I believe we should experiment. Look into the ideas where we somehow just have two connections for.

Z

One for krypter and one for the data and there's proposing mailing list and I think like and if you think about it, it makes a lot of sense because we already have different connection ideas for to can change and for the short header, so we bifurcate them even further set would not be that bad, but I've never heard any reaction to that idea on the mailing list. That's my first point and the second point I wanted to make, which is sure to make that vector.

C

Gate we're a very time constraint, so please make okay.

Z

Understood I will stop up. First point said: okay, thank you. Ted.

S

Already very quickly, I think mark linzer's principle applies here. You've identified a very clear problem, and now we ask ourselves the questions was the simplest possible thing that would make it work.

S

I think you came to the conclusion that the simplest possible thing that could make it work as a ship to DTLS, but I think that the proposal that's come out and for which we're still hoping capr is actually simpler for a variety of reasons, for one thing in part, because we don't then have to go and impose new changes on DTLS all the work and stay here and I believe it actually by separating the stream ID frame and the packet type successfully creates the architecture you want within.

S

The control of this working group give us a PR I'm ready for that. I. Don't want to go details so.

R

I think yeah I think they I think I agree. This is, as I said, it's a simple thing that could possibly work. I think that it it we really worth exploring whether it can in fact possibly work properly. That's like we're snowing right now happy to happy to collaborate with Ian and whoever else wants to collaborate on trying to work. The details like I, think I agree. That's an important next up, Patrick.

L

Okay, so from a code point of view, I want to kind of echo what Brian said a little bit earlier and refine that where he said like you know, he started out with you and I was like mega ooh I started out being like yeah. You know I got streams. You have figured out it's there like. We heard this on the mailing list and I actually hacked up this DTLS implementation, which is by canoe, which we'll get to and I, was like honestly surprised.

L

Looking at my own code base with clean eyes like how much of an impact it made, it removed four times as much code as it added without question, which was really pretty interesting. So point number twos I do have a hacked up version of this that runs DTLS on draft. Oh nine, TLS, 23,.

L

Right so Gordon a with me, like, probably better next week and if you're looking to do a little experimenting like down that front, but I think the core question like I'm, you know I like the stream separation. It solves a few of our problems. It's certainly cleaner.

L

My favorite thing I like about is we can't, should be clear about like what's in a protected State in an unprotected straight state for what's on screen zero, which is the source of a whole bunch of problems right now, but the core architectural question I've got is you know, do we want this narrow API or this wide API? So I feel, like you know, historically, almost a little lied to as a developer. Here, if I go back to my days, reading these drafts I got stream zero.

L

It abstracts away when I need to know about TLS I got to carry it around. I should be snacks, I can carry TLS around get good, get bytes in and out, but it turns out, like I need to know an extensive amount of information about what is happening exactly when and that's no longer a byte stream. But almost every interface to TLS I've ever seen, because the API is a byte right, I need like events for session tickets and hrs and blah blah blahs after right, Martin email.

L

It says what is this bite that's appearing when I don't expect any data to be on that stream and what protection do I send it under and how do I akan and so on? And the more I've learned actually recently about some particular cases with security and the finish dates of the handshake. I am actually ready for someone make a pretty big security error because of difficulties in that.

L

So I don't love the way this is currently reconciled um and I think it would be good to talk about that as the focus of kinda how we move forward. When you say that you mean what's on screen, you said that the the width of the TLS API and what we need out of it in order to serve the requirements of quick, okay.

H

Suppose anger when I Kirk said I have a better diagram of this I. Definitely do it's like much cooler.

H

But architecture I think that we've been talking about the layering and stuff uh that are actually for me.

H

The most important thing is that really who controls the bytes that are you dressed on the wire, as we've seen with the discussions that we've had and that you end the quick mailing lists, like everything from packet number encryption to public flags that we control every single and spin bit or whatever I, don't want to bring that up right now, but it's for a later time, but ever having control of every single that is the egress in the wire is incredibly valuable because we provide additional properties, and so hence transport owning.

H

Those bits is like the more interesting layer in question to be who owns those final layer of bits, and so architectural II I think that the way that is currently designed is DLS is a service. He also went through the service and quick doing the one. That's egressing device transport during the one c crossing the bytes I think.

H

That's that's the right way to do things I, although I think that stream zero, as initially when we came up with stream zero and will like forget about DLS and- and it was completely facetious like decision I- think was a wrong in in hindsight, but I think it's fixable in a way that and I think the spectrum of solutions here to fix it, where one of the spectrums is keep stream zero and like just go with it, and this the other spectrum is literally like have an API between the TLS layer and transport layer which is like on on client, hello, and that is a frame in itself.

H

A client follows a frame in itself and it is also a stream frame which can be terminated. A server hello, it's dukedom, so TLS quick understands every single message that the TLS layer is sending to it and so in the middle of those two are this crypto streams API, so I think that there is a architectural e. This is like. The original decision of using TLS service is the right way to go. We said to find the right middle ground between those two extremes.

E

Hi Colin Perkins I have two somewhat contradictory points.

E

The first is that this approach, with the crypto streams in crypto acts, looks like it will probably have a very small, conceptually small, practical difference to the implementations, but will be a great conceptual simplification to the specification and more conceptually modulized things things quite a lot. I think that will be a very good feature going forward, especially when we look at some of the things being proposed for quick version 2 and beyond, such as his hesitates say the world of multicast.

E

It makes it easier conceptually to change the keying and so on, because we've separated it out from the streams in stream, 0, so I think that will potentially be useful going forward.

E

My contradictory point is that we've had a bunch of discussions about multiplexing things like WebRTC and those already used ETLs. So if we're using DTLS, we solve, we simplify some other problems. There.

AA

Andrey pop of Microsoft, so I'm grateful to Eric for bringing up this discussion, because I think the issue of a complex API between the transport MPLS does exist and quick right, so I think it's an existing issue and if we can come out of this discussion with a better API between the chillest act and the transport stack with less coupling, perhaps that would be a great result. The other thing that this discussion highlights I think is that a lot of people are not happy with the DTLS transfer services or the transfer services.

AA

Dts provides in terms even even to the handshake right and if we can come out with this again with improve DTLS with better framing, for example, for little s, I think that would be a very positive result as well. So let's.

P

M

S

Presenting this.

P

I, theoretically, like the video support but I, do have a concern, and that is about the condition. Control using DDS well mean that we cannot easily see the information that should have been gathered during the handshake phase to the congestion control, quick. So after the handshake, you'll be less than ideal in the normal case or too much data. If there was a loss. I think that is one of the examples that and that you know that belongs to the nature of having two transports and there could be others I'm, not sure what excuse.

R

Oh yeah, that's a real concern. I think can somewhat be ameliorated by having racking the shame spiral, a wider API that basically gives you know it gives it gives the calling application information about exactly what happened, because the DZ Alice does have acts, and so they do give it much name information, though it's slightly less precise, um so that would help some but I agree you're going to maybe some there may be some compromise, sir.

AB

Not able to negative Microsoft so thanks I prefer for this presentation. The beginning of this session. The entire session was all very nice diagram about all the latest advances and interoperability great chart by the interoperating. All that sort of stuff replacing or using the deep t-dub extreme DTLS proposal would basically throw that obey or go back several months. I. Don't think we want to do that, I, don't think we need to do that.

AB

So I would really caution against it seriously. Considering the the full detail also also because it may not be echoing with something that Christians said on the list- may not actually be the right architecture if we think about functional decomposition approaches to development.

AB

So having said that, I think there's definitely issues with trim zero and proposals and ideas from this document have Druce. For example, like the Crimson screen circuit practice might be things we want to consider, but definitely not go the full length of.

D

Martin, thank you for defending the end of the line there twice.

F

AC

Polly Apple so yeah. Thank you for bringing this up. Definitely the the streams or architecture issues you've mentioned are very much felt in the implementation. I do have concerns about coupling this with DTLS as DTLS for issues that have been brought up already as relying on the DTLS spec adjusting there may be other details, use cases that will not want to adjust to this.

AC

If we go to the next slide, when the DTLS architecture I would be curious to see what would happen if we essentially, we tried to imitate this architecture because it is very clean for the implementation look rather than putting DTLS there. Just have quick running the TLS handshake there. So, essentially just does don't call it.

AC

D TLS, keep it the quick wire apartment, because if we want to turn detail s wire format into quicks wire format, that's essentially what we're doing anyway, and if we have to come to this, let's think about in this clean architecture, with more of the layering rather than the weird C interlocking thing we had before, keep them separated out, but let quick as a transports still run the thing. So, let's think of it as a quick handshake, then gating the rest of the quick transport on that I.

AC

Don't think it would actually end up with that much wire format difference, but it would be an architectural code right clean up. So I'm not sure if this is what you're talking about part.

R

Can you go forward to slides so I started to keep going into you see on our diagram right? So we floated this when you and I were talking, um which is basically to essentially cut the details record layer off and replace it with a place with a cracker layer which sorry, which would be to cut the details record layer off.

R

So you keep exactly the quick record layer and then everything that we would everything that detail had excellent rate on the wire you just mark it as a special kind of quick framing is the only one can appear in the record. So it looks like on the water or call.

AC

That your crypto streaming crypto act yeah. Essentially that's that yeah like it's so give it architecture you down below yeah.

R

So anyway, it's other possibility. Yeah.

H

And this kind of goes back to my point of liking. If we did something like this, this, we would end up immediately like beating it back into something that looked a little more like quit, but maybe not as much like quick toes today, but not to say that's a bad thing. I'm. Just saying, like you know, cuz DTLS our streams in say this yeah.

I

Thompson, just to summarize how she talked about that with the API and I think: that's actually a point of disagreement that we have for some people. This is a feature and for a number of us this is a bug.

I

Victor talked about duplication of various capabilities that we we have. The the record protection was one was seen early on as being one that we could have safely. Duplicate turns out it's the same code. It's just got different constants in it. For the most part, there are problems with the current key schedule that I don't think I could talk, talked about with respect to forward forward secrecy and post compromised security.

I

Those sorts of things that digitalized might address, but I don't think that when you duplicate the mechanisms, you necessarily have to duplicate the code, and that was kind of a fallacy in that in that sort of argument, if you go back to the the picture that everyone has sort of been gravitating towards- and this starts looking a lot more like putting like the last diagram, if you think about it from a certain from a certain perspective and the difference there is that the crypto axe would look look different in the other one to this one.

I

But if you think about this as quick packets containing DTLS records, then you actually end up in a in a space. That's very very similar to this. You use different encodings for offsets and lengths and things like that in side, each one of these things, whether it be a cream framework or not. It's essentially the same thing and you can drive these things in in very similar ways. The question is: who owns the the packet numbers or the?

I

Although the record sequence numbers and that's you know, doesn't really matter, even you can pick one or the other. It seems like. We have a bit of an attachment issue, perhaps to some of the work that we've done, but I'd also remind people that there is such a thing as a sunk cost fallacy, and we should be aware of that.

I

If we can make it if we can make a change that makes things better for us, then we should do them I'm very, very sensitive to the amount of time that this is going to take us to do. But I, don't think that any of these changes take any more time than any any of the others. It's just a matter of addressing all of the the architectural concerns or the the differences.

C

Of opinion that.

I

C

Thanks, did you guys want to wrap up.

R

Yes, so I feel like I'd like the next step is that we definitely have to explore this some more as it's only interest in, and we should see like like, like we. Only kind of came was like three days ago so, um like so like what I suggest is um you know like, but like we can form a Coalition of the Willing, which I think is gonna have to include me and other people who want to be involved. I'd ask the chairs to help us, keep it small, because we could make progress.

R

I, don't want to be that one incest, goofy and work on this some more in parallel, I'm gonna, try to get some people and flesh out some of the try, some other stuff. In case we have a backup as well mm-hm.

P

R

Like them and then I think one much clearer sure why she stuff like where this actually is a viable solution to the streams, your problems right.

C

And when we first talked about this, you know the guidance I gave you was I, don't care if well I care, but it's not the end of the world. If we decide to do this and it takes time to implement it, but we can't have be spinning our wheels deciding right from what I've heard here, I'm a lot more comfortable that I don't hear and- and please give them I can correct me if I'm wrong I, don't hear anybody saying no! This is crazy.

C

Talk let's, you know just stay on course, I hear a lot of interest in exploration, I hear to push back at the full DTLS solution, I think you're. Hearing that too, that was.

R

C

Are a lot of potential midpoints there so.

R

I think I'd like to I'd like to try to come up with like at least one and maybe two Foley pressure puzzles and we can and we can try to nail it down hard mushy stuff. Do.

C

You think you'll have any implementation. Even rough. Oh yeah,.

R

Yeah I already I already have a referral mutation Patrick, probably in Iraq, okay, and we can I mean have to do it, but the duration of yes right. That's right! That's.

C

Actually think we're for the blind. The awkward part of all of this is that we gave ourselves a high priority to finish the invariants soon, so this is potentially going to stall. That I appreciate that okay.

S

Actually, that was the clarifying question I was going to ask: was it sounded like your direction? Was the the PR? That's the unnumbered slide. Nine here was going to be the starting point and if that's the case, it seems like the quick packet format and all of the applications and streams that don't relate to the handshake can go forward without the presumption that they're going to be any change to a DTLS record format or otherwise uptake of DTLS.

S

If that's the case, I think I understand where you're going in and it's clear, but if there's going to be a range rather than a point solution, I think it's it's much harder to know. What's going on so I would suggest, rather than multiple that you and your Coalition of the Willing come up with a single proposal and we go from there. Okay,.

P

Sure it would help gives.

S

Us a much cleaner way of avoiding the delay that Martin doesn't believe we'll have yes.

R

I guess I I have some sympathy for that position. um Martin. Yes,.

I

I was gonna suggest that if we explore this one and something closer to the one that you had me back up slides neither of those change, the invariance that we're talking about here. That's.

P

Actually, actually, one.

I

Of the points that I think we could probably relatively quickly come to consensus on, which is the invariants that we have a fine move on and if that's the case, then I mean, if no one's willing to back the fall DTLS option. We don't need to worry about variance, slipping right.

C

I

C

Not a surplus, so then the question of the group then is: are we comfortable with commissioning you to explore this with the design team to report in Stockholm with the constraint that it doesn't break the invariance as we defy them so.

S

I, just I just have a you wish.

C

S

A question: is there anybody who is interested in determining which of the two this one or the slide, nine version of it who wouldn't be part of the Coalition of the Willing? Because if the answer is everybody, who's going to be interested in the distinction between those two which are very similar in many ways, is going to be part of the Coalition of the Willing. Let them decide and move on, and don't you know it's it's both a way of implementing that that slide 9. This is a subset of slide 9 in my which.

R

One is nine: the.

S

Nine is one with: did you make me draw that's.

C

Why I write that the.

S

Tls handshake is different, so you're right right, but I think that deciding between those two is is critical to making real progress. Well,.

R

I guess I I would I mean I, think the reason she's hearing hesitation for me Ted, is on those two things. First of all, I roll admit I'm, having trouble giving up on the GLS record format, but if half do fine but um but like ignoring that for the moment, um like I, think it's reasonably likely that we know we'll have a discussion and we're like these. Are the pluses and minuses these things but, like we ultimately like, like you know like there's a lot of people in to working group.

R

I, don't feel comfortable deciding for everything working group like which, which of two I'm not totally different earlier. These similar right so can.

C

Can we get a show of hands of who is willing or interested in actively participating in this design team.

W

C

That's probably too many people.

R

C

If you're interested please email, Lars and Ming, okay.

S

C

S

I strongly encourage you as chairs, when you put this together, to be very, very clear about how whether it's doing this or this +1 or or what because I think the smaller that number is and I think one is the ideal number faster we're gonna move, how.

D

Can I greed is so personal, so one thing I might've brought up at the end, but so, if you look at our milestones, which be moved by six months, which caused us to get a lot of email from implementers, but they're calling for us to ship our FCS to the isg in November this year, right if we are now basically giving ourselves from now until June, it seems unlikely that we're going to make November if the implementers are okay with that we're. Okay with that right.

D

But but so um let's be clear, this is very likely. Gonna move the milestones which is as I said. It's fine. If that's what people feel is a good decision right, if you, rather we architect this this bit of quick and and maybe may explain it in simpler format and make it easier to implement correctly or trade it off against the slipping timeline which might set. For other reasons right.

D

This is not the only thing that that's still floating around, um but but it's it's a sort of it's a choice that we we you know need to make, and we need to be aware that that you know this is not a. um This is not a decision that that won't have an impact that isn't to say that sticking with the current design that is arguably harder to implement and understand, isn't going to cause implementers to take longer either right.

D

So this is not clear that this is necessarily gonna cause more delays than what we currently have, but any amount of change potentially disrupt their military activities right. So we would especially sort of maybe you don't wanna come to microphone. But if implementers are concerned with this change and the impact and they have on their roadmaps, we would love to hear that um if you don't want to go to the microphones and email to mark and me if you're implemented at the leaves.

D

This is the thing you want to do and and you're you know happy with with refactorings be doing this way. We also want to hear that that would be good to know and yeah.

C

I say I think if, for whatever reason, the design team isn't able to come to some sort of proposal by Stockholm we'd need to re-evaluate all this again, the default is always to leave it as it is so.

H

I want to make a comment on that, so I mean recently. We we have a had a connection, ID design team, which you know I, think we've managed to kick out the door pretty quickly. Yeah.

P

H

I think that should be a model for like what we're trying to do with this right. I mean we basically went between an interim and before the next idea. If we had a PR landed.

D

It was also arguably a smaller problem. It.

H

Is a smaller problem but I I think if we really try, we can engage in fix things. Okay and I think we need to try to do it in that sort of time for not like three four months, all right.

C

We think we've done through the Ramon script. Oh great, thank you both very much we'll take that to the list. Martin.

R

Very epically I just want to thank people for indulging me on this, and thank especially in the rest of people and Jonathan's people who met like like for really being always hitha seriously. I know. I, know, I played this point the last minute and people really dug and I appreciate it.

C

Okay, so we have the 15 minutes left. We had more time scheduled for this. If we don't get to the end, we can always bump the remainder to Thursday, even though that's yeah so part.

I

Of the point of this discussion, we were having was so that we could do risk one of the more important parts of the protocol, which is those parts of the protocol that are going to change over time. So if it is the outcome of this discussion, the previous discussion that we are not going to change the packet layup, which I think we're gravitating towards there's only one other thing left that we have to change in the invariance Draft. And that is this thing.

I

In fact, it's already changed so I'm just going to go over it very quickly. Next next place. So there's a connection idea. Protocol long headers have two connection IDs. The first one is for the recipient of that packet.

I

The other one is the sender's expression of what they want the other side to use so, basically, once for routing and one for the routing on the reverse path, their variable length with a very short range of potential values, and importantly, when you send short headers, there's only the packet, the connection ID for the recipient, we use the the pair of connection IDs during the handshake in order to essentially negotiate what connection idea is going to be used later on. But, ultimately, all you really need is the the connection.

I

Id that's going to be used to route the packet or the other one. So next is an overview of the process. So when you send an initial packet as a client, you choose a randomized destination connection ID because you don't haven't talked to this particular server before so you don't know what it actually wants. You just pick something at random and part of the reason we have this initial packet is so that we can especially distinguish these from other packets that maybe get different, different sorts of routing our treatment.

I

Then, if you get a version negotiation, those let's just get echo, but they get flipped so that the destination connection ID is, can be used to route the packet correctly to the client.

I

Again, on the on the on a retrial round, the client uses the randomized one that it used previously and the server says: hey here's, your connection, ID and the destination, but the the retry packet contains connection idea that the server would like the client to use thereafter. Of course, when the server sends a handshake, it can change its mind.

I

So, if you think about the case where you have multiple server instances and one of them wants to share some load stateless lis, it picks a connection ID that it uses its current knowledge of the current topology of the of the cluster and the loads that it has. But that might change over time and so the server that that receives that that next handshake, maybe it's not the one that maybe you think they can pick a more precisely targeted connection ID for this final se ID.

I

That's all in the draft. It's pretty straightforward! There's a lot of moving parts in this particular diagram, but that's every single moving part that we have you'll notice at the end of the short headers, only one pretty straightforward next, so the old invariants looked like this, the relatively straightforward you had a bit and if you had the bit, then you had a connection ID there and a version, and you always had a connection ID next slide.

I

The new and variants are a little more complicated and a little bit more complicated because they're two connection IDs and they're variable lengths, and we do some interesting bit packing for the lengths in the octet that follows the version. You know also note that we moved the version, the advantage of that being that now version is in the same place in every one of the long packets.

I

When you have variable length, connection IDs ahead of the version that if you need to be jumping around all the time and that's kind of suboptimal, so we we moved it. One of the reasons we have the connection ID up front before was so that would remain in the same place. But as soon as you put a length in front of it, it was no longer in the same place, so forget that next slide, please now the short header is almost identical to how it used to be, except for one thing we removed the bit.

I

That said whether the connection idea was there or not, because one of the things we can do with this particular design is say that the connection ID is zero length and voila. Now you have no connection ID, you don't need to have a bit you just as a server, for instance, when you saved it to the client use this particular particular connection. Id. If you don't want them to have a connection ID, you tell them it's zero length and that works out pretty nicely.

I

Next I think we're almost there ah yes, so this is really the main cost of this design so for clients that were in general endpoints that rely on having a connection ID for routing the packet toward them find themselves in a bit of a bind, because the peer that receives it receives a packet can generate a stateless reset based on the design that we have, but it won't be able to generate the correct connection ID to put on that packet such that it will get back to the client that sent it.

I

It doesn't know where it came from in the the vast cluster on the other side that that is potentially being used by the, for instance, the client. So what we do now is we advise simply setting a random connection ID and acknowledge that this might have some problems. It might be that stateless reset is now recognizable as as a stateless reset, because suddenly this this particular flow has a new connection ID appearing on it.

I

That's not such a so much of a problem if people use new connection ID with some frequency, but it's still a potential exposure, but probably the big one is that the stateless reset might not arrive at the right clamp, and the suggestion here is that well, stateless reset is only an optimization if you're forced to use connection IDs for routing on your end, then don't expect to be receiving stateless resets and just deal with it. :.

E

So it had a comments on the previous, so I can wait. Alright,.

I

I think we're almost at the end. Maybe we go to the end and we'll we'll see okay, so the PR which has been merged. Actually, all the peers have been merged, create the connection of easement diversion negotiation version field version, negotiation, changes of work as well, but it's just using the same long header format. So now not really a fundamental change.

I

It's still still just a long packet with the version number of 0 there's a little bit of a gotcha in terms of return route ability checks when you do a retry and the server requires a zero length connection ID. But but that's not the big problem, because you had validation on a previous round trip. So the text covers all of this I. Don't think, there's been any anyone pushed back on any of these changes.

I

The question that we have is: is this good enough for now and Colin's going to tell me that he wants to do some Demark stuff most likely, and we can talk about that for some.

E

Colin Perkins, so what I was going to say was for the short Heather packets, the invariants, don't guarantee that you can do max done. If we are ever going to run Petofi, we even need to be able to debug stun or reinvent it within quick, correct.

I

The invariants do not guarantee that there may be properties of individual versions that we can use to guarantee that that particular version will do max would spot words done, but the the invariants don't provide that guarantee. Correct I. Think I.

E

Think if we can, that would be useful guarantees of revoked.

I

Previously, we had sort of been operating under the assumption that it was acceptable for folks who wanted to do some of the real-time applications that we're talking about to know what versions were being negotiated. It's not it's.

E

Not so much for the real-time applications, it's if we ever want to run quick hit appear. We need natural Vasseur, which means we even need stun or we need to reinvent it.

I

But the the assumption there was that there was some form of signaling in those applications and that you could use that signaling to to negotiate versions that were compatible with these sort of natural that you were employing in those in those applications. Yes,.

E

Yes, and we can do it, we can make it quick version, specifically ones. Yes, it would be cleaner in some ways if we could make you understood. Yes,.

D

Though I think we go for clean clothes, the line on this after ROI and if there's more need to discuss it, we're going to do two discussion on Thursday, because we have two lightning talks that are previewing talks that are given elsewhere later in the week that we want to get to. But one so um I mean.

R

While as a tactical theoretical matter, this is not guarantee ability to DMS was done as a practical matter. It's not as the fingerprint and therefore you can D much was done so I doesn't require a first Newhouse I'm. You worry about that um I mean I, guess, there's a warning. You know 1 & 2 to the 128th chance that, like you're gonna, have a problem but seems like pretty well um it's much worse than that, because it's done has fingerprints yeah.

I

And integrity checks and also.

U

I

Into the 2d system.

R

Like um so, of course, if we do Collins, don't let me different, but the next thing I wanted to say um definitely double check with you. Is we discussed on the mailing list adopting um the version negotiation scheme that I suggested for DTLS in and quick where the court version is negotiated in the primary conversion is negotiated by offer answer rather than by rather than by a certain project. I, don't think that breaks the variance, but we need sure doesn't it.

I

As far as I'm aware, it doesn't, but we can go through the details. What what the? What that changes is that you're, the version field that you see in the clear determines the packet obfuscation, great.

P

I

And the means by which you do version negotiation inside yeah.

R

I mean so I think that the failure case, if there was one, would be that the outgoing packet came with quick version X. But then, when you internally negotiated, you turn might return version. Why haven't decided which rule that is and.

P

R

Something which we might want to be careful about, I mean I, guess we could just all the problem by saying the invariant is not guarantee the facts about the Russians, the same version and then the problem will go away. I mean.

I

I think we can I think we can do that. Okay, yeah I, think we can do that I'll. Let people think about that for a moment, because that's tricky but ya know that's good. That's a good good addition! I'm.

M

Sorry fielding: do we have working group consensus that the version is 32 bits would.

I

You like to challenge that that, because.

M

I

Was assumed I think no one, no one said anything about it. No one suggested otherwise. I know that there's a bunch of people who really really want 32, but you know you which color. Would you like to paint that bike shed? Because I did put that warning on the front of the presentation.

M

Editorially editorially.

I

B

Is enough for anyone.

I

It has been 40 less as a practical point, but I think there's there's a number of people who want far more room to move I, don't know what they're going to do with them, but so.

D

C

You've already landed these right. This.

I

Is a landed right as far as I'm concerned as long as we don't decide to rock the boat too much with the changes to the stream, zero stuff sure this is done so the.

C

Intent is to as I understand it is to do a working group last call on this. Yes, go through that process, conclude that process and then park it until we ship the rest of the documents. I think.

I

That it's a semantics: that if.

C

We we can change it later on, but it's a fairly high bar to do so. We're intending not to break our work with this. Is that what we've, where we're at yep, but can.

D

We start sweating rip.

C

Last call now sorry, because we can't predict the future and.

I

And, and because until someone okay, so so I'm gonna repeat, Jonah's question is Jonah would like to know why we're parking it rather than publishing it and so mark suggests we. We don't know what the future is.

I

Obviously anything we do with this document after publication, whenever with that publication date is, is still subject to the same sort of we don't know if we can't predict the future and and maybe we made the wrong decisions and whatnot but I think the the key point here is that well, while the the patient is on the table, things might go in and out that cause us to regret our decision to publish an invariance document right, and there is no version of quick that depends on those invariants um to a published version once everything there's not really that much of an advantage, but also as.

G

I

To the the invariance here and have some sort of commitment to them, that's really what you're looking for you're looking for people that nail these down, such that they they don't move around and that's what's been, concerning people with like being in particular who's trying to you know, move a good chunk of the internet traffic onto this. This new invariance gamer's is finding particularly distressing, so we need to give in some certainty also if we publish a series.

C

Of documents called invariants that change people may not believe us after a while.

F

C

Okay, so last question: do you think we're ready for work last call I? Would.

I

Like to fix Akers comment, which I think is a very minor one, if it okay and that'll, be up in a pull request and I. Imagine.

C

I

C

We can do the whole, then we'll start the process giving yeah.

I

Let's do then next week or plan check that next week in treasure, but.

D

The two guys with thought and talks come on up.

C

Two minutes max two.

D

And a half that on the agenda, so yeah Yanis first.

D

No, the other one, the wild chewed on that one start.

O

Talking, okay,.

D

O

Young, so if you're interested in how quick is in deployed in the wild already be sure to be here tomorrow in the same room at the RG research group, and you will hear how you can enumerate quick hosts in ipv4, I mean websites there that already I deploy it on capable infrastructure and how many you can actually use.

O

Furthermore, we money towards actual Internet traffic in a major European to one in a mobile network and an attack speed as well as in an open, trace and we'll show how much quick there's. If you don't have time you can read, our paper can get on that URL and ya see the rest. Thank you. Thank you.

W

Oh, we have a draft in TS vwg, which is packetization layer path, empty discovery for diagram transports, we're trying to layout standard algorithms for doing diagram path, MTU discovery and we've. We set this up for SUV SP over DT, LS, UDP and tunnels. We'd love to have quick involved next slide, and for this we require that path. Layers can signal their MSS, send pro packets process, packs big messages and have some way to do reception feedback, so they can work our it ICMP black calls and I'm.

W

With these none of the students blue expose anything to the path. So it's it's friendly with quick, next slide and yeah, and this we just have some quick questions for you and we would love to have conversations about people who have data on path M to use, and we would like to speak to anybody within quick working group who wants to work with us on Datagram path, layer, path, MTU discovery, and if you want to know more about this, we have our presentation on Thursday afternoon, TS vwg. Thank you. Thank.

D

You thank you one time. Fantastic.

C

So see everyone on Thursday, we'll move the UCAN discussion to Thursday, yes and we'll also discuss the spin bit.

AD

D

Up inside the blue sheet, if you haven't signed it yet.