Internet Engineering Task Force Interim Meetings, 19 Sep 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-TSVWG-20230919-1400

Description

TSVWG interim meeting session
2023/09/19 1400

https://datatracker.ietf.org/group/tsvwg/meetings/

A

A

Which will take notes for the meeting I, don't know if anybody who's on the call wants to volunteer to type into this I have a copy open here, so we'll try and maintain a live set of notes for the meeting, please log into the note tool, if you're able and contribute to it.

A

A

So this this is the September 2023 interim for tsvwg.

A

um There are two co-chairs for the group uh me gory and Martin, who unfortunately can't be present today, he's in another meeting somewhere else.

A

This, like all other ITF meetings, is covered by the standard ietf note. Well, you must deal with the ITF policies, even if this is an online meeting and you must um observe the rules for submitting materials and contributing via email on discussion in the interim meeting for details, see them not well.

A

We do need a knock Taker and we will take notes in the Hedge dock associated with the meeting.

B

Gary I can take some notes if you, if you want.

A

Please do please type into the notes tool or send me notes. That's so wonderful! That's how this is it yeah, yeah, excellent.

A

It's good to have notes to know what we did um right next slide: uh we're going to use meteca, so you know to use the hand tool um if you can't use the chat and we will try and follow both and get people in the queue to discuss things.

A

I've only got one status aside, because um most of the status is not relevant to this particular interim, and neither is this, but it's useful to know what's happening. We are about to do a final review for the ecn, encapsulation and shim drafts.

A

um Our main goal of that activity is to make sure these drafts are correct, with the more recently published l4s specs, and then we will be submitting those to the IES G4 review director. So that should all happen in the next couple of weeks.

A

We are going to talk about UDP options and that's complete its first working group last call there's been a lot of discussions since still a lot of things to finalize, but we're making good progress here and hopefully we'll talk about that more at the end of the meeting today.

A

So the agenda looks like this: we have been through the agenda and not well. Does anybody have anything else that they think we should be talking about at this meeting.

A

Apart from the fact that Magnus can't hear me, which is going to be annoying because he's the first speaker.

A

um The we've we've completed our liaison update to and from 3gpp which I'm hoping Magnus will go through.

A

um This is with 3gpp, sa3 and round three, and it relates to the extensions for dtls with sctp, which brings our first topic on the agenda. Ctp and dtls.

A

uh We'll talk about the proposed Milestone updates all the documents associated with this work item and we've got a presentation from Michael Tucson, which is also related to this area. Finally, we'll look at UDP options. I will go through the issues list.

A

We are using an issue tracker for this um and, although Joe can't be present, we do have his inputs into our issue tracker, so we'll quickly quickly review those to see if we can continue to make good progress.

A

Excuse me: I've got a bad cough. um Finally, we will use any remaining time to look forward to the next tsv WG session and I. Think that's the agenda that we currently have. Does anybody have anything they think should be added to this agenda.

A

Then I'd like to turn the floor over to Magnus and perhaps we can introduce the.

A

Liaison and the progress with that and then proceed onto the various items. uh Magnus, yes,.

C

I hope you hear me now.

A

We do excellent good.

C

So- and you maybe see me also- um let's see how do you upload these slides or.

A

Yeah, the slides are loaded, so you should just be able to you want me to share them.

C

Let's see, uh let's see.

C

If I remember how we do this.

A

I think I just clicked that.

C

Button yes and I find the slides yes, so now I have control. Thank you.

C

So the TLs for HTTP is the topic here.

C

Let's see if my headset can keep them and not mute, but um so uh I'm Magnus Westland um and we're talking about the two different set of drafts here, and we will uh a little bit high level here.

C

My primary goal here really is to yes, my headset's turning off uh so consider understanding requirements here understand the different trade-offs between the two solutions we have and be able to enable a consensus call on the direction. That's really where I want this to be at the end of this meeting, so yeah.

C

So uh there are IPR declarations here: I have a verbal state, let's see I think I'm gonna have to switch speakers so but one moment so uh there's one set of IPR disclosures on details over HTTP Biz draft is known. The exclosures on currently on this will be crypto chunk and there's one two sets of disclosures on sap crypto detail less.

C

C

Yes, we're coming to the license statements. They are next in this slide. I want to just preface this with uh this ipodic relations, because I think they're, the relevant and I have them here. I can go back if you want to talk about the lasones first, but they coming next, uh but I want to make one verbal statement here, which is Israel.

C

I'm gonna have to switch this, but Ericsson on it's gonna make uh ensure that we have. We don't need a license to implement the kernel parts of crypto dtls so to be able to.

A

Magnus, you appear to be disappearing in your audio.

B

Yeah I I want to get that correct in the in.

D

The minutes uh I didn't know. Can you hear me now.

C

A

Yeah, can you rewind and give the IPR disclosure again, so we so we know uh what's a minute. Yes,.

C

So Ericsson will make a new IPR disclosure with the goal of ensuring that there's no need for a license to implement the HTTP crypto details solution for no license needed for the parts of an ssdp implementation that needs to be reside in internal foreign. Http implementation in the kernel.

C

The actual disclosures is underway, but it's going to take a while before we have finished all the details of it, but we foresee it's being available before the next ITF meeting.

A

Thanks I think this will be a great help to have some clarity on the um where we can go on how far the IPR will reach I see. Michael is in the line. Can we take a question now from Michael Yes.

E

So I think it's good to have something: I can Implement in the kernel without IPR things, but uh uh both Solutions, no matter what we we finally do um requires a detailed attend, Shake in New, Zealand, I guess, um which means I can Implement stuff in the kernel, but I'm not able to test it. That is not very helpful.

E

C

So I so uh yeah, but that's that's the situation.

C

All right, saying I think you can test it, but you can't release the test code in that case. Maybe, but that's I think there are ways around that. But yes for you actually testing. But yes, it's it's when you're actually needing a license, Etc! That's when you would run into the problems.

E

I mean at least I would need a an API to the kernel part which I can test against and I can say. Okay, this, the API should behave like this. It's I can test this, but I can never test, but it actually works.

C

But okay go ahead, yeah so but that's at least where so you will. The airport is also will show up later so that you will actually get the exact wording in place for what it's, what it says so.

A

Yeah, thank you very much for doing that. um That'll be a useful thing to have carry on like this. Yes,.

C

Now we get into the layers on statements so uh and I think we can rapidly go through. This is backgrounds from the previous license statements and at the end of of the uh this is what we sent out afterwards. After the meeting uh the last day, death meeting sent out a number requests. We sent out the statement with a number of questions to the groups Etc, and we have received two answers: one from essay three and one from round three, and if you need to look at the details, I would recommend that you go.

C

If you haven't done it yet go to the data track and look after the analysis. So, but let's first look at the response from essay 3.

C

So this uh is you see the link there, um so they answered on the first question: is the IDF tsvw's interpretation, architectural security requirements correct and that's what was listed in the last in the license statement is sent and they answered that from essay Free's perspective. Tsv. Is this interpretation of all the security audience is correct. Your generic best practice of a security protocol.

C

uh So that, but one answer they gave, the other was does sc3 have any additional concerns with implementation either of the candidate Solutions, and the answer is solution. One which is details over http require change in existing HTTP satpo of Standards implementation and details, Library the Air Force solution, two. Once implementation effort appears to be higher than solution. Two and two is detail, as in crypto chunk and on question. Three, which are the two candidate Solutions are preferable to sc3.

C

They said acid prefers solution to details encrypted chunk due to the answer of the previous question. So that's kind of what the answer statements they have for the full statement. Go read the link any comments on this.

C

E

um Do they for for the comparisons they made? Are they looking for the crypto chunk? Are they looking in the pure user length implementation or are they you? Are they considering because from in My View From? That's that's a major difference in in the implementation effort.

C

Yeah I can't answer that the detail uh I think this is kind of a summary of The Views, that those made statements in the sf3 working group is what went into.

B

E

C

Okay, so uh ready.

F

From Nokia uh I was looking at the implementation of Nokia and we are using satp for several interfaces like you have analyzen statement, but it's all currently open source. So uh we are more looking into uh if it's possible right I mean we're looking for a solution that could be done in open source itself, so it makes it uh quite easy to do the transition from satp to secure ictp. So that's what I hear from uh several teams, which have been involved at Nokia, who are currently using http.

C

C

Yeah and you Charles, do you want to make any more say anything more about your? Yes, false? Go ahead, yeah.

D

Let's see um yeah I just wanted.

G

D

A

D

The discussion State more up with uh uh kind of the requirements level really didn't get uh into the the details of the implementations, either in an essay three or from what I can see from from the Rand group. Either uh we probably need to fight with her essay we'd, probably need to go to a corresponding CT group. That would then work on whatever essay 3 ends up putting in the specifications there'd be a correspondent would be ct1 or ct4 would probably have to go off and and figure out.

D

You know more of the implementation details, so um you know that discussion wasn't really. uh You know the kernel Space versus user space and the the impacts on on one.

F

Versus the other.

D

Wasn't really a topic of discussion.

A

So Charles, which group were you referring to in 3gpp,.

D

uh That was in the.

A

D

Group I was in that meeting when it was yesterday. Okay,.

A

C

Okay, so I guess that was the sc3. Let's go to the Run freeze response, um okay, robot, anything more on sc3 store.

F

Okay, I I hear the same uh response from some of the delegates who attend the sa3 and what I heard from them was. They have not done any Deep dive uh discussions on the solutions, both solution and solution to uh uh from. If maybe the answer is from an implementation effort, but there was no Deep dive discussion on comparisons of the pros and cons deployability and then uh uh the threat vectors or any such analysis was done so I I couldn't hear any such receive any data from the sa3 delegates.

F

So that's the latest information I got from them. So if there is anything else that you have, you can please share.

C

Yeah no I I, don't have anything additional I just want this. So.

H

I

Yeah uh 3D people very seldom discusses implementation. Details like kernel or user space I think that would differ between different companies in in 3dp I know. Some companies will like to implement this purely inducer space. Other might do other things, um yeah I think also, there's often not any detail. Discussions in 3dp companies read up this. um Sometimes it's very little time and companies are expected to read act beforehand.

I

You know one of our company competitors had a very strong preference for solution to when they came to the meeting. um So I don't know if we are not sure we will get any of these things from 3dpp.

E

Myself, PPP doesn't look into these implementations in detail. We just should not use a comparison made by them um as a basis for our decision, because, from my view, what is simpler depends heavily on which implementations you're using and so on.

C

Yeah I agree, there's difference especially on this implementation. Etc I think we I think it's reasonable here to look, make our own assessments and then base it. Take justice. Take this into account. What they're stating so.

C

D

Just the one request I would have I.

I

D

F

D

That with making our own assessment I think that's probably the right thing to do. But if that assessment leads to doing something other than what what sa3 kind of just gave their preference. But.

F

Then, as long as we describe.

D

That back it liaison and why we went that way. I think that would be completely fine. um It wasn't like it it's not like a mandate or anything like old option. Two I think that was they were asked the question and they tried to provide an answer based on you know the knowledge and research of people who are in the room, and so if we feel we need to go a different way, I think that's totally. Fine I would just want to see lays on back to them as to why we did that.

D

So they know it. Wasn't us asking and then ignoring their input.

C

Yep I think that's very reasonable. So let's go on to this review. What they run three Ellis said about the core response was so they on the question about confirming whatever implementation was built in both New Zealand and current implementation visit be required for a solution and with any additional concerns, did you implement either solution as perceived? They basically said, no we're not discussing it, usually not discussing it and they haven't discussed it in this case either. It's my conclusion, but um on the other thing here, it's a confirm.

C

The interpretation requirements is correct, in which satp message would be required to be supported, in other words, a theoretical maximum message. Size mentioned about relevant to be supported, or would it be sufficient that the smaller message is supported and round? Three would like to confirm our previous answer. We don't do not expect to limit the maximum message size of application protocols. For this reason, any solution will be the limit of the message.

C

Sites will not meet around three requirements so which means that they they want to have the possibility to make even larger messes than what was reported. What we've wrote in the previous and previously in this slide sets Etc where we had identified, uh it's actually I think of the next slide. Yes, these 142 kilobytes and 500 kilobytes, so even large message, and that is expected to be supported.

E

C

Okay, so that was the status of the LSS at least so I had I think it helps a little bit to knowing that on the message sites that answers one question at least so.

C

So should we go on then into some discussion Etc about the two solutions and in comparison and see if there's any, have a discussion and an answer try to answer any questions. If there are anyone around these two proposals, so we can get.

A

Towards we shouldn't yeah, that's what we should be doing, Mike, let's go ahead and yeah.

C

C

So uh there's two proposals, so detail is over CTP. This is described in details of satp base and it's also has a dependency on an updated, SSB, auth document. That's why at least is the tax in tsp RFC 4895 bits, and this is an apple, a protocol, an adaptation, labor details, STP layer and sap stacked with satp auth embedded in it, and that the push down Keys into the authentication layer and the user message gets fragmented into fragments.

C

That's small enough that detailers can protect them in each record, and then you are put them together to protect the user message that you then transmit, and you rely on sdp oauth to ensure that there's no injection of or reordering of the details records in protected user messages.

C

uh It uses uh parallel details, connections for keying, so you have one details, connection up when you want Reiki, while maintaining it. First, you create a new one handshakes, the keys start, pushing down start using those keys, and when you know that all messages with using the old Keys has been received and decrypted on the receiver side, then you can terminate the first details connection and completed. One reaching sequence I would note that the draft text in the current detail is our satp draft might not correctly reflect all those vulnerabilities.

C

We recently discussed Etc the last period of time Etc so, um but I think this. This correctly reflected in this presentation. We come to this.

C

um So that's the core of this solution, and then we have the other proposal. Detail is in crypto chunk.

C

So that's two two drafts one is the say, crypto shock, which is implemented inside the sctp stack and then there's a protection engine specification which defines how the crypto Shank encapsulates will help a protection engine securely each set of satp Shanks that goes into N1 sdb packet. So this is a mechanism on packet level.

C

C

Been some changes, but we kind of agreed on getting towards the when you're gonna do the key uh handling the detailers handshakes Etc you're doing that over a datashank. You send this user data with its own ppid to identify those messages, so you can and that's the arrow that goes through the stack.

C

That's uh handshake message going over to the pier from the protection ending Key Management part, and then you can have a part which is more, for example, integrated into kernel where you do the record processing and you have any private keys and a record specific protection specification like and for detailers. We're using the details. Record layer would then be handled in that layer.

C

You use a very similar mechanism for re-keying that you establish a new detail as handshake when the handshake is completed.

C

You start using the new new keys and and the crypto chunk itself identify the uh key epochs or, as in the connection, that's been used, uh which means that you end up with, um can identify it and, as this is per packet level for each satp packet that gets protected.

C

Your details is basically working on per in the transmission order of satp Stack, while in the previous Solutions, you have some aspects of this being on how the messages is arriving into the stack and being processed rather than how they transmitted, which is relevant for some of the future questions we can discuss and in this in details in crypto shank, all the fragmentation is used in satp's normal message message handling because it's fragmented into Data chunks, which is then protected after it and being fragmented, which gives you protection of all the satps shank types inside the packets.

C

So after the handshake gets completed.

C

So so that's the overview, any question and overview, and otherwise I'll go into the comparisons.

C

So so one aspect to this, which is fairly significant, is to regain your robustness, so the TLs in satp chunks, when it's necessary to re-key, either periodical or when you reach some data limits. You initiate the new detail, as handshakes as estimate message with its own ppid.

C

When you completed the detail as handshake, you derive the keys and for the transport protection, install them and have the related uh connection, identification field in the crypto chunk flag field, and as soon as your handshake has complete, you can start using the new keys because it's you know it's in place.

C

In the other end, you can leave the old case in place to drain the network of any sap packet protected in Old Key and because these packets, basically last use the keys until they will arrive, is on the order of what it takes to trans gets across the network. Etc reordering any things like that. So here you could Implement a very simple solution on when you can terminate the old and like a two minute.

C

Timer will be clearly sufficient for having any packet being received if or being dropped by this network and then you're close to old and if you would actually close it as soon as you just get the handshake, you would only result to some packet loss yeah in details of satp. uh The process is similar, but here you're doing you have two layers that interacts. You have the satp auth, because, with the right keys from the to the sound check for the satp oauth, you start using the new keys and here's some problems.

C

For example, if you're using an API like the ones described in 6458, you can't switch the sdb auth keys in the middle of a message uh you could in in general. uh You would should be able to do the. If you have another eight value, you should be able to do that, there's, no, nothing preventing the protocol or receiver to figure out which case is used.

C

uh The challenge here is to figure out when all details records being protected by this uh pack by this, the old key has been received and decrypted before we remove it and which means that you probably need to you need to have either more deep API into the sdb stack and track all the datagrams uh one moment. I must finish this um I go. uh You will understand when so that's one one way of doing it tracking all of this or you could also basically drain the connection thing or the association.

C

If you stop sending wait until the session is empty, which also is very fairly easy to figure out, then you can stop. You would know that you have received a little thing and can actually drop the ALT key. So Michael.

E

Why do I need to know that it's decrypted by the peer, so the the sap authentication they are already takes care of?

E

um When is a message protected by an off-key uh act in a non-regnitable way? So that means yes, I never have to retransmit it I think I can I can CL I can remove the key once that is done. Yes,.

C

So that's a assumption that you would decrypt the detailer's record as being reconstructed in a timely fashion.

C

So if you close the details, connection and remove the keys on the details, connection before the crypto details record, it will screw up, but uh assuming that you, as soon as you get the full record decrypted in a timely fashion, the non-renewable way is probably good indication of when it could have been decrypted but they're still they're, actually not the form formal synchronization between these two layers, because it's happening in the adaptation layer after the sdp stack has delivered data to the adaptation layer.

C

So that's the challenge here.

E

Okay, I mean so you mean. When do you need to have I mean you need to distinguish the sending and receiving side? Yes,.

C

E

Job of the sender is just to make sure all data is at the pier and when the then the peer has everything it can decrypt and so on. So um um the sender can remove its state. The receiver needs to drain that all the key. All the all messages using that auth have been protest in New Zealand. Then it can um free the the connection.

C

So if it's yes so I mean the I think this is do not if you, yes, this robust in your implementation when it comes to details connection, is that, okay, before you close the connection, let that just verify that you actually have processed all the records, because at least time you would have it in your your receiver, buffer, yep yeah. It's you. You would avoid the problem so yeah, so harness.

B

um Yeah I was I was wondering like like this in general, um this sort of re-keying operations are, of course, uh always a little bit annoying, uh but it's not uh it's not the end of the world. It's like like we are. We need to describe uh the timing of when you can discard keys and and when you switch it's uh like also implementation, wise.

B

It's it's not a drama like this is standard business in a in a key management protocol, so I think if the with the words you're using like training sounds like uh we are having a flat here or so, but in fact this is a sort of routine operation.

C

Yeah, but it does I mean if you do training you actually have to impacting the uh higher layer, the upper layer protocol, because you basically have to stop sending until you confirm that all the data has been delivered that you had a outstanding before you stop sending again, so that.

F

C

Canada's latency implications on on the application protocol and in this case, because of the layering uh I, should actually go back to. Let me see uh so. The problem here is that you're draining down in the sctp stack here, while your trans, your scheduling of sending of these fragments, is not the same as the transmission order on sdp layer.

C

If you have multiple concurrent streams or use the message being sent necessarily and if you get packet losses and wait for repair Etc, you get things out the Border here and that's the extra complication that in for this details, ostp stack, yeah, I,.

B

C

B

Making problems here that actually don't exist, but.

C

It's the problem is having a very firm understand is, is knowing, when you deliver the data and being certain that it's been delivered, so that you can close the audience connection yeah.

B

Well, how having like working on implementations, uh would obviously provide us some insight, but uh on on some of that, but there's with the prior work in the group on on details over sctp there's already some experience, but.

C

Yes, but that didn't have retaying at all so already saying if it used to require draining that's what the 683 specifies it. Com requires the drain if you're doing a reading, renegotiation, basically yeah.

B

I would avoid talking about draining uh all together, because it has this sort of dramatic uh sort of that's.

C

The word that's used in the previous specification I.

D

C

So it's it's! It's! What's in the satp API. Also, this.

E

Is nothing Magnus says choose, and so um that's true, um we drain on renegotiation, and the reason is that we, when we switched on the dtls level, to a new Epoch at that point of time. We want also so you get rid of the old details keys and, at the same point of time we wanted to get rid of the details, the the sap auth keys. If it's we discussed this, this seems to be.

E

um It seems to be okay, to keep the keys around for a bit longer at the HTTP layer, and that would mean you can avoid the screening but um yeah.

E

The RFC as it is today uses training and that's why we were very strict on on getting rid of the case, but this can be worked on.

C

J

C

It's it's just that it's it's a fairly complex process requiring potentially ID, tracking or Etc, because the problem here is that if you get this wrong, you basically have to board. This is sap Association.

C

So that's just the kind of warning fact why this matters so but yep.

C

Okay but I think that's that's the situation here with when it comes to re-keying at least so then we have satp replay protection so.

F

Another question on the previous slide uh right: I I see you have brought up several issues with the details over sdb right. So are these problems more like uh that can be solved by implementations or is it like? The protocol itself is issues that can't be fixed right, I mean uh uh uh I see. Some of these issues are mostly related to the way it gets implemented and it has to be done in the right way, but from a protocol perspective, do you see any issues that needs to be fixed as part of this month?.

C

So I think we arrived at the process that works. It's just that you have to be as a sender. You have to be very careful about understanding when you fully deliver the data and there's different way of reaching that step, but it's it's. It's either need good integration with sap stack or you can drain the whole stack. You have options, but that's basically those you have so so.

F

E

So this works. This work was done at a point of time where we could influence the software API RFC. So the socket API specifies the level of interaction you need for the satp stack to implement details over a CDP. There are no special hooks needed or something else, but Magnus is right.

E

um You're programming against this API and if your stack has a bug, the consequence might be that you lose the connection, but this can happen always.

C

G

All right, no hats, but um maybe this is a silly question but like while we're here messing with the protocol like. Would it be possible to instead like create a way to re-key STP off of in the context of a connection, and why does that not work.

C

So Michael you go.

E

Ahead, so the sap authentication supports 64k keys in parallel and they can be changed during the lifetime as often as you want. Yeah.

C

But it's two layers here: I think which is it's the integration between the detailers layer on top of the stack and the satp auth keys in the stack and knowing how these keys interconnect Etc I mean the sap was case that failure to authenticate your packet would mean a packet loss from the sap sender perspective.

C

But it's the Lucy details record is is a really bad event, because the sender believes you have delivered it and you have. It has delivered it and there's no way of dealing with that. But there's it's yeah.

E

So your stuff is I mean the ROC is implemented in openssl and runs on Linux and previously two kernel implementations supporting the circle API. So this is doable and it's available.

C

So replay protection, uh so here we also have some differences. uh Detail is in crypto chunk uh here we can actually re use the detail as replay protection that exists in.

D

C

To avoid replay of older satp packets, so, uh and and that's because they are transmitted basically in the order. Satp is transmitting. The packets detail is the sequence numbering them and using that for its replay protection.

C

It's replay window yeah only needs to be as big as the reordering expected between the paths, because it's going to be across all the paths um and it provides a strong protection against availability attacks because replaying, an old packet here will not work at all because it will basically just be dropped by by the details encrypted Sean clear when the package comes in and it's out the window in detail.

C

So satp uh sdb of doesn't have any replay protection, but you have some interaction between the knowing that the packet is authenticated and the datashank processing, for example, for a data level and data replay, can only occur after TSN wrap, which means that is after 2 2 to 32 data chunks.

C

So if you re-key at least once there is 252 data chunks, you can prevent the replay from happening and the entering data into the high layers.

C

So the only real, significant difference, if you're doing that type of raking are often enough, is that you have no General protection against this, and this is for STP chunks that doesn't have sequence, numbers, etc.

C

Those you really contract in in those cases, so it comes down to how robust your stack is getting and you replayed control checks, Michael.

E

So when designing a CTP, we were definitely aware of attackers might replay packets for whatever reason, so. The procedures in the protocol are there to deal with it, um and even if you don't want to rely on this stuff, you can always use off to um to protect against this stuff.

C

Well, you not protect against replaying previously sent packets even really not.

E

Anything. Okay but but I mean it's. You got the packet once you can get it twice. It's like packet, duplication happening in the network and that's right. Yes, that can happen all days and and I think HTTP should protect its I mean I would expect an satp implementation to protect itself against it. There is no need for some for for another.

C

Yes, so this is noting that there are difference here, there's, especially if you have a deliberate attack that you delay a packet significantly more than what you expect from a application or anything to happen if you get in two errors after each other in in a short time. Okay, that was duplication. It's about. If you would get an error message that was from 30 minutes ago, being replayed, you might might react to it and say that it's that type of thing since, like yes, it.

E

Looks like yes robust to um so that's perfectly valid to replay a packet from yesterday and I would expect the protocol to deal with it. So can you come up with a with a with an example where such a replay would have any impact.

C

Not in a well well implemented stack, no I, don't think so. If there were no super obvious big holes here, if you have implemented this correctly, it's it's down.

E

To yeah it can we distinguish between the protocol and implementations, so I think the protocol is fine with it, implementations may have any bugs yeah yeah. Well, we I think we should focus on the protocol.

C

Yeah sure I asked note in the difference here is that on the left, you even have a protection against implementation bugs from replays, so foreign.

E

Tations but I'm not aware of the back where this kind of stuff, which would be critical but okay, go ahead. Yeah.

C

C

Okay, uh let's see.

C

So on performance and okay, tiru.

F

Hey Microsoft I have the follow-up question: did you see this bug in any of the existing implementations that uh raise the alarm uh or light any of the open source HTTP implementations uh where you notice this kind of vulnerability and that needs to be fixed, or this is uh more of like a theoretical assumption or or something that you tested, and you figured that hey. This is a common vulnerability that you saw in multiple stacks.

C

No, we don't know, we don't know about the common name carrying it. The only we went through the protocol noted places where at least you had some potential for confusing information, because you couldn't separate if it's replayed or not Etc, but it's basically on the level saying it's informational message arriving out of expected time, windows or its sequences. Basically, that's the thing. That's Concur and it's limited to a few particular messages which is positive, informational type. That's what we noted it's.

C

We don't have concrete expert examples of of this of any particular implementation, or something like that. That has a vulnerability.

F

C

Okay, so uh when detail is in crypto chunk, it performs a single set of Cipher operations on each record and it's going to depend on the cipher, that's being used by the protection engine.

C

Detail is over a CTP. It first performs a detailed Cipher operation on the content of the data, thanks on each fragment and then for each sdp packet. You send you send you perform an sctp or protection of the sdp packet using hmac shot 256..

C

This is a slightly different overheads. The detail is in crypto. Chunk will have a smaller overhead because of the sap offs large tag. Basically, even if it's the details record is per packet, so Michael.

E

And just a question since I've been out of the um being working for a vendor for for almost 20 years, so um the notes this protocol or one of this protocol will be deployed. um Are they running on CPU limits? I mean are they uh are they is? Is this CPU performance critical I mean I'm always for saving CPU Cycles, but is it something like uh you need additional Hardware if the CPU cost goes up 10 or is it uh so I have no feeling whether these are saturated.

C

E

C

It's I think it's actually no, not from processing requirements for the ciphering I. Don't think that's the primary it's it's there's the difference, of course, because you're doing two levels here, but for the details of sdp, but it's I, don't think from our perspective. It's that's uh yes, noting that they are a difference here and it's there's some byte overheads, that's larger on the Nutella so versus the B2.

E

So but it's not critical from an operational point of view.

C

No I mean the tasted 3dp usages in control in signaling protocols in the control protocol parts. So so.

E

Yeah, that's what it works. Thank you.

C

C

C

I mean there's a general trust in detail as there's a good and living living and maintained protocol, which is good for both sides.

C

But uh I would say the sdb auth I mean based on the file found security bugs Etc. They haven't been out. It's not as well studied uh they're, fewer implementations and and Etc. So sdb off here is a little bit more uncertain from, in general trust perspective, I think from knowledge about any weaknesses in the protocols.

C

D

B

um Yeah price one could argue that the crypto chunk is not widely implemented either. No.

C

But that's I mean that's true for the uh details.

C

Layer walls, details layer on top of sdp, which is gonna, do the key management and those process too. So, yes, we in both cases we're introducing a certain set of new procedures. Etc around these protocols and that's.

B

True for both I think the what I was pointing out the arguments applied to both sides here on this on this on these extra extensions.

C

Yes, those extensions extra, yes,.

D

E

Michael so yeah, so so I think one of the things we should uh which which we should consider is that I think which solution we choose. uh It doesn't matter. We, it should be possible to look at the implementations. Look at the I mean look at the protocol study. The protocol allow review on the protocol and also on the implementation level. That's a good thing in both cases.

E

C

So I mean that's part of why I want to make it uh so saying, try to get as soon as possible to your decision towards Direction here, so we can focus on getting through and review it properly.

C

What we're doing here and getting yeah prototype or get implementations Etc experience too so, okay, but let's uh get go on so when it comes to message, size limits for details in crypto chunks, there's no limits ex the same as in normal http, and we just how do I manage to not fix this okay detail is over HTTP uh with a good satp, API and tracking. There was no limitations.

C

If you would have uh the 6458 API, you might have a limit, but it's really really large messages. It's the time how long it takes to transmit the message can be no longer the time it takes to until the next three keying.

C

Basically so so you can have a reasonable way of sending very big messages with both Solutions and I. Think that's they've, both in from that perspective, fulfills the requirements Gary.

A

Now I was just going to ask um so both seem to pass this and I think what you said. Isn't it.

C

Yeah, exactly so I think both if these 3D people's requirements, so what's up.

C

So implementing these details encryption so that requires implementing the crypto Chunk in the SCT stack and if you have a kernel, satp implementation. That means you have a kernel impact.

C

You need the details, protection and your wrapping of the detailers. So that's some code around that and fitting it to the crypto chunk, uh especially for user lands tax. We really expect available DTS and details implementation to work and be easy to integrate for the kernel implementation of the dealers record protection. That means you have to have some type of split details: implementation. You need to take the details record processing into connected that to the chunk processing in the kernel and likely a new API for the crypto context. For that.

C

So I see here there are difference depending on where you implement it, for details of HTTP there's an update of the sdb auth uh required for the sap stack to implement whatever the new specification is that solves the directionality and and Etc so we'll have some kernel impact on the. If you have a kernel, sdp implementation, you have to consider if you need to have STP tracking of delivered data, and if that means that you need some new additional API surfaces to your sap stack.

C

uh And you need a detail as implementation that might require extension or updates to support necessary features, because we have a need for either a details, connection ID the need for the details, connection ID, as well as an RFC 8449 support or support for 16, 384, maximum side, byte records or some other limit. We've set this. You must support these size of Records we're going to use as well as so saying, the wrapping Logic for the adaptation layer in above the sdb stack between the ulp and the sdp stack.

C

So that kind of the impact for these two proposals, Michael.

E

Why do we need 16, 384 record sizes? So what is RFC 8449.

C

It's the details, record size, negotiation mechanism.

E

So, where you can reduce this yes.

C

Yes, the kind of the interesting for on this my understanding here is that the details, stacked mostly being deployed, may not actually support full maximum size, detailers record sizes, necessarily uh it probably it might be a test because their deployment has been focused on using them to protect like UDP payloads, which has like they're gonna, fit in ipmtus Etc, so, okay, I'm on yeah and and and sure you just need to ensure that, if you're an easy way of dealing with this is saying yes you're requiring for details, recipe of a maximum record size, details implementation, you just need to show that you have one so I can just maybe have some input on this.

C

B

Yeah I I worked on the implementation in the empathy LS on on this, um so the it's in some sense. It's just a parameter.

B

um As you know, it has different uh a different lens that is negotiated and the issue is that, like how much memory do you allocate before those extensions, it was difficult to downscale, uh which was an issue for iot devices, so they had to sort of like allocate the maximum buffer size, which was a challenge. uh So that's that's why the the extension was introduced, but um as.

D

I didn't check all.

C

The stacks, and as you can no not so I mean our understanding is based on trying to review the specific saying apis. Etc was described about some Stacks, that's available and and that's why we're saying that there might be some issue here around that size limit, but it probably is in buying a very minor issue, but it might exist you're just trying to be happy.

B

To look uh happy to look around with you and see what the status is. It's obviously interesting to know like how the developments implementation deployments have catched up yeah.

C

We're getting too bit to the detailers level here and which is uh so so far. We have been looking at supporting both details, 1.2 and 1.3, for both Solutions and the reasons here is because of the lack of mature details, 1.3 stats, um and we also have some inherent to the Limit as to the details, connection ID requirements, so details encrypted chunks as I said, needs no connection ID, but the teleservice.

C

When it comes to replay protection, you may use it and I think actually recommend using it details, crypto chunk, so for details or HTTP. You need to turn it off because of the potential for significant reordering making. The data that arrive out of order, Etc yeah, can cause problems with the details, records being not processed and lost. So therefore, you must turn it off.

C

You have the key in in interaction with key updates, because it's happening on packet level in details encrypted Shank.

C

So um uh so it may be used, but the same like the other re-keying problems, we have the philosophy. All that applies also for key updates on details level because of the unexpected, the large uh potential time distribution between the last between different uh lost, the first usage or everything last uses of keys uh details record sizes that we expect to see is for details in crypto. Chunk is really just to be packet, MTU that you're using and as we've discussed for details of sdp, it's 16, 384, bytes and so uh honest.

C

uh Do you have any the.

C

um You say that openssl is to add detail as 1.3. Okay, do you have any more details.

B

C

That's just uh yeah I.

B

Have to look it up, but uh we asked the open SSL team. What their plans on is that it's ongoing work. Someone has secured.

K

B

To to do that type of work, um the I did the implementation of dtls 1.3 in mpet TLs, but it's all as part of all this work on on producing sort of a production quality version I had to remove that code and so I could I can ask my more formal colleagues on what the status is there as well.

D

C

But yeah I think the current situation is that they are long you you can expect to be able to transition to 1.3, but uh yeah yeah.

B

C

Currently, I've read the available open source. Implementations might be limited well.

B

It's uh like, obviously it it's uh always a huge effort to implement any security protocol like at the production quality performant level. So uh so it's not like a student project kind of thing, um but I expect that likewise with DLS 1.3 uh people are moving to to version 1.3 so um and of course, the dtls 103 specification was released much after the DLS 1.3, so um that of course introduced the time delay.

J

B

Since you guys are also adding extensions to TLS 1.3 who are proposing uh and and so yeah help is appreciative, like contributing code to this open source project is, is obviously up to anyone.

B

C

Okay, thank you so, but that's on detailers and requirements uh when it comes there's. One interesting aspect here around the STP Association restart around these. um So in details, the crypto draft current disguise sap restart for two cases: either you maintain your protection and in crypto context across the restart, and you could do like an init protected by the crypto chunk or at least a later message that we can be discussed, how it's exactly done, which would maintain the security or you do a plain text in it.

C

We notice this has opens up for availability attack on the sdb association um and, if an attacker forces- yes, it will be restart, then the details handshake will expect it to be failed, because the attacker has no way of responding with the right identity and it will terminate the highly accessory session. So um so Michael.

E

Yeah, um since this is on the slot in the slides, um uh I'm, not sure if this uh uh restart using the crypto Chung actually works because um uh HTTP wants the verification take of zero to be used. If and only if, there's a single image Chunk in the packet and firewalls might might enforce this.

E

um So when you yeah, when you put your crypto you're in it, showing after I mean it's a payload of a crypto time, the question is um which verification tag you would use so.

A

If you would use zero.

E

Then the firewall would drop the packet because it's an illegal verification tag. If it's non-zero and you process the init, the stack has to throw it away because it has to enforce that the yeah.

F

Maybe you're looking at the second one.

E

The the attack Vector is something you wrote, so the attacker must be able to read packets in both directions and must be able to.

J

E

A packet so isn't this? uh Isn't this a man in the middle I.

C

Mean it's yeah, I ordered a competent attacker, maybe better word for using it. But it's yes, you need to be highly competent attack or have an access is a certain levels here to be able to perform.

E

This one, so if an attacker can do this, uh why can't the attacker just drop packets.

C

To perform this attack, you just need to be able to uh get the cop attacker needs to be able to speak back yes and be able to read packets. That's this I.

E

I understand this: when we, when we design a CTP, we protect it against blind attackers yeah. But we said if we have some on-path attacker, there is no need to protect against uh denial of service things, because an attacker who is capable to read these packets um is most likely also capable to be able to drop packets. So you can just drop the packets off the association and you have the denial of service.

E

Is that not true anymore I?.

C

Think I think there's actually a significant difference between actually be able to ensure that the package is dropped versus being able to get a copy of a packet.

C

So that's just my personal view.

E

Right here this means, but this means protocols like TCP and sap are broken because against I mean we have to accept the TCP or nctp are broken against these attackers, because they can do they read on the on-path traffic and you can they can bring down the association anyway, foreign.

C

E

Need to protect against I mean: do we have a threat? I mean I would like to see a a threat model which says this is what we want to protect against, and this is what we can live with.

C

Yeah, so I I think we I think this is something we could continue discussion later. It's just that this exists, because I think you want to get towards this issue, but it's it's something we're gonna have to deal with uh in some sense and and exactly what is the acceptable layer. Potentially, this is something you could have a policy flag, saying: okay, I, don't believe in this attack can happens or it's it's not bad enough. So therefore, I enable this. uh Knowing what stick is so gory.

A

Yeah I'm I'm confused by whether this attack is more severe than just seeing every sctp packets and dropping the ones that you think are the most destructive.

C

Yeah, but it's the difference here is, is that you only need spoofing and reading capability versus dropping capabilities, but.

K

E

And how do and how do you protect against the same attacker just doing this? Initially so I mean it's a it's a denial of service attack right. So just do this before the handshake happens and you're done. Yeah yeah.

K

E

Crypto without crypto I just started I just start talking to you over playing a CTP, you associate with me and then I, keep you in the state. So I can do this. I can do this without crypto and I'm, not sure if this is actually I mean, let's, let's focus on the threat model and then see. What's what threats we have to the which we can handle and which one we accept.

C

Yeah, let's take I think this is, is the thing uh for further future development, because, yes, it just noted it because it's actually and there's uh sdp oauth has requires this to be off and having maintained in the crypto context authenticated for restart to work. uh It's just don't think that, and here is the satp in Philippe. There's specification 38 Forum 12, which requires this to be a social, restart, I think. Yes, we probably maybe need to communicate to three people that they might want to review this in a later lesson status, so yep so.

C

um So, uh to conclude, what we see as the kind of Summer of differences.

C

So uh we have on the details, implementation availability uh on wreaking robustness, message sizes is not really a difference unless you uh so there's both very large Etc fulfilling requirements.

C

um You have some difference in if you encrypt the stb control chunks, where details encrypted shank to encrypt them versus they're, only being authenticated in details or satp, and that's also related to the replay protection discussed, harness.

B

Yeah I'm still I'm like in details of HTTP, you say implementation ability is poor. It's it's 100 times better than a proposal that is not implemented at all. Like you already have some features with uh um it's.

C

Just for the detail stack and it's based on the requirement on connection ID I, think the connection ID is the long tooth for the details, implementation of details or sdp.

C

That's the problem. There's not that many stacks that support of the data's implementations for either 1.2 or 1.3, that supports connections.

B

I think you are comparing apples and oranges, because you're basically saying that I have one feature that I have to implement uh births and that's why it's totally fine to implement everything from scratch. It.

C

Almost sounds but every from scratch, so there's several layers of implementation. That's why I talked through this in the implementations practice saying this is just talking about. What's required of the details, implementation itself, you ask the details implementations. Then you have the different wrapping layers Etc around it and yes, that those are different.

B

Yeah I don't agree with your assessment, but it's of course it's a different perception.

C

I

I think it's a big difference to make for a company to win and make changes in the detail as Library implementation and to to make changes around the details. Implementation you at least Ericsson as a company, would like to very quickly apply security patches. If you have done any proprietary changes, you cannot do that without any additional work, and you also risk risk that you have messed up something else in the ddls implementation. I think a lot of people rather build things outside of detail. Yeah well,.

B

I

D

B

That logic uh I think you you. It makes no sense to me that in other groups you are proposing to add new features to TLS, then uh like, but oh yeah. There are some inconsistencies.

E

So if you have patches against libraries- and you want to uh simplify your life when you apply security, fixes Upstream your changes.

J

I

Yeah, that might be sometimes it might be hard for company policies and require a lot to work to get approved and also all open source might not want patches, for example, openssl I think for a couple years ago they stated very clearly that dtls 1.3 was not the priority and would not happen for several years and yeah I, don't know. If somebody tried to push that, but I know people try to push a quick API that the light- and that was very much denied, because management want to do things another way.

I

So it's not always that you can. Even if you implement it you it's not sure you can push it to some open source project and it will be accepted.

C

C

uh Let's see and uh crypto passes on data, its detail is only for in in the crypto chunk and over STP, its first detail as 1080p worth on different granularities uh implementation impact detail is encrypted shank for user space implementation. We is some so for some value of medium. While we consider it much higher for current implementation. Did you acknowledge that uh it's similarly a medium to high to do details or STP, depending on on looking at both the details?

C

Implementation, if you, depending on how much changes need to do that and and how difficult is to get this to be off changes in place for your current sap stack?

C

So so it's it's I think a lot depends on which tax you're using Etc but Etc. So it's it's not only our considerations here, it was saying. Ericsson might have one view, we're very much supporting details in crypto chunks, for one reasons, for several reasons, among them before looking like it's simpler, more straightforward, with key management and uh and and and provides Better Properties for it protecting the whole protocol.

C

C

uh I understand we have different views here and therefore I want to see if there's some additional question Etc, because we know we're getting very close to the end here and how would we want to see.

C

Wait: Wave 4 we want to choose and I want to see a direction here, at least some clear indication or saying what else is it that we need to really understand because I think still, there's gonna be a year from Direction chosen until we finalized in Spec at least and I would like to go towards the Hub so um and I I would like to us get to consensus called fairly soon after the interview meeting here.

C

So uh I would and then I think so any more comments, questions discussions.

K

A

I think I'm interested in knowing um who thinks they have enough information or if they don't have enough information. What do they want? So please think about going to the queue and talking about that, if you can talk about what else you would like to know or whether you think you have enough information to be able to make this decision and then I'll, let people clear the queue so zahad. First.

J

Can you hear me.

C

J

Okay, so jahid with no hats on I think this has been a good discussion, uh good email discussions and we have a lot of information. One.

F

Thing that I was.

J

Thinking, like might be really important because, as today we have heard like there are lots of implementation considerations. There's the attack thing going on there's like a need for what's going to happen in the kernel space user space. All these things I think it would be very important for this working group to actually do some kind of testing on intro thing or like to actually consider the implementation aspects. Also, even though, like at magical Michael said like, maybe we should focus on the protocol part but I.

J

Think important, as this is kind of like really touching up on different security things and different, a different.

F

J

I think that would be really interesting to see some sort of like the interrupt or implementation experience. Shared I don't know if anybody can share that right now, but yeah. That would be my expectation and I think it would be really good to actually consider uh those things as well. That's it.

C

Yeah when it comes to implementation, we did an implementation of details over satp, a prototype where we fail to our usual detailers stack, uh didn't have connection IDs, so we couldn't implement it full out and it's supposed to be a bit of a mess to say lightly.

C

F

Yeah I think it was a good discussion today uh with regard to both the proposals and uh seems like some of the issues that Magnus has raised can be addressed in uh also HTTP, but but I think the I think we need much more deeper analysis to understand and figure out.

F

The clear winner and probably some sort of running code or interop would help us to make that decision, but I I feel it's too early to go one way or the other with without looking into uh more understanding of which is more uh feasible to implement and deploy in on open source. At least that is the interest for Nokia Michael.

E

Yeah I mean we I already said it's whatever solution we choose, it would be very good if people can look at the code, people can look at the the implementations. People can look at the protocol and play with it. um So the real issue for me is the iprs on the table. So I mean it looks like there is the possibility of Eric's moving.

E

uh So maybe they can consider that if it's somehow, they can somehow choose a license which allows open source documentations to implement the complete solution, not only part of it.

A

A

Please go ahead.

K

Cool um so Shino and I here are the Linus turn up three maintainers for the CTP stack implementation and yes, I can see all the differences between the two implementations but at the same time one critical information that I'm missing is what is our goal here, because one solution protects and, let's say, hides more information from the protocol than the other for from pretty nice, and is this uh like a requirement is?

K

Is it a goal to protect from it or just add, crypto and protect the payloads, but there were papers that people uh serving traffic and like infer which movie you are watching just from pocket headers. So is it a worry here?

K

C

I'm not certainly understood what you're really asking for you're saying why.

K

uh I'm asking what is our motivation here uh to add detail? Yes, over http.

C

John I think you might be better to answer this.

I

uh Yeah, the motivation is to I think right now, some one of the solutions, ipsec Hope by hope. um Pretty people wants to have and to end encryption over intermediaries, and then they specified RFC, 6083 I. Think as the tree at that moment, dressed with 5G, probably believed it was. Dtl has provided everything and it was done and now it cannot be deployed. I think for a 3dp perspective.

I

Dtls over sctp is good enough. The definitely needs to be encryption also inside the core Network. That's like not the question, uh but I think that's probably good enough. But if you decide something, if you decide something new, you should try to hide as much as possible and that's what we try to do in in dtls in in SCT, with the crypto Shank.

K

A

I started a poll in the background to start some questions. If this one very general, would you support progression of one of these methods and then, of course, I'm going to ask for the individual ones and see what we can learn?

A

Obviously, this is only a small group of the tsvwg, so it would be good to get a sense of what people thought after that detailed discussion and feel free to take part or not take part depending on where you feel you lie in this discussion at the moment, carry on talking, though, at the mic I'll leave this open for a while.

G

C

G

Not sure I guess I'm next, yes, okay, I have um okay. First of all, no hats, I'm, not an sdb expert by any means, but um a few comments so like I, feel a little bit torn here about about these two Alternatives I agree with Michael that if, if the IPR encumbrances are such that we cannot get the kernel bits in the kernel, that seems like a non-starter um for the uh crypto chunk deal.

B

G

Not saying that's the case, but if that is the case, I think it's a non-starter um for what it's worth. I think this. This crypto chunk idea is probably a little bit architecturally cleaner and um the uh and I do think that implementation shortfalls are a bigger deals than STP implementation. Shortfalls like in this community can fix problems with the CTV information much easier.

G

We can fix problems with details from this you're just given the specialized um skill set needed for dtls, um and the final thing I would say is that I don't object to more data but I, but I also don't want this to become um just sort of bring me a rock um looking for the magic thing that's going to I I. Let me put that a different way.

G

I think we need this person to Define what information we need and and like ask someone to do that, rather than just sort of hope that doing a little more work will make the answer become obvious to everybody, because I, don't I, don't think. That's where we're I, don't think it's a productive way to move forward.

J

On uh so my understanding, actually this is a really important problem to solve from the 3gp point of view, but I I do see like this is not the most critical one I mean when I look at the the implementation or deployment of Iran.

F

J

In in the mobile networks, I think this is still uh far away from deploying details over a centipedes, so we do have time to actually um do some more analysis and make a good decision. As you said, I I do agree with the things there has been saved by um by you. Martin like one is.

F

J

Conceptually and um and in the from the architecture, contributes, are more simple. Another is like you need more detail kind of like discussions between this working group and TLS working group and other things so yeah I mean I think it would be good to actually do some more kind of like uh analysis before we go for one or another way, um and also wait for Ericsson's disclosure of like like the licensing, because, if that is that lets everybody to implement it in open source, the.

F

Full solution there.

J

Might be is just simply will go from that one of those things. Having said that, I think I need to attend some pool here.

A

Yeah um I'm, just in just quickly commenting on the poll. The poll is not asking the question of which direction do we choose, but it's trying to get to a place where we can actually make that choice based on inputs from the group, so I'm asking really for people who would actually be willing to commit time or help Define this in a more clear way, perhaps talking to the TLs people as well, and that very much follows what um zahid was saying so.

J

So so gory just.

A

A clarification.

J

I mean: do you have like an thought in head like there might be a design team looking into these things and come up with some requirement and potential Way Forward I. Think.

A

Yes, I think so. I I think this is. This is what I'm now thinking of that we've we've made good progress here.

A

I'm, not sure this level of in-depth discussion is great for a tsv, WG plenary and I'm, not sure 100 people voting on which one's the best method is going to be the right way of doing it, so I think probably a design for you to come up with the requirements for this spec And, to clarify some of these things and perhaps take this to TLS as well and find out what they think about the security aspects sounds great and quickly, because um this is only to decide what we're going to do, and you know we should be able to make this decision fast.

C

F

Yeah, we have seen design teams which are like meeting every week, and we can make quick progress with with a dedicated set of people who have a stake in this and wants to make this uh quick decisions on this. In addition to requirements, I think uh the design team should also look into the threat analysis to see where the threat actors are, what kind of attacks are possible right and and and and that mandatory set of requirements optional set of requirements would really help evolve.

F

These protocols tend to uh really weigh which one is Meeting those requirements and then pick one of them in addition to the IPR and other open source uh implementation. So that seems like a good step forward to make some progress.

A

I'm right with you on the idea of getting the the threats identified more clearly, so we can make sure that we have a very clear message to our Security Experts Magnus.

A

um Do you think there's another question we can ask I'm not sure I can actually ask on the direction at this moment.

C

Now I understand that, but I I hope that we I really think we need to be able to do that very soon after the next ITF meeting uh that question, because I don't think we can delay much more. So if you're gonna have something like the same thing like like the meetings.

F

Etc I think that's.

C

Then it needs to be spun up immediately to make progress up towards the ideas meeting and to discuss these things. So in that case,.

A

Okay, if you're on this call and you're interested, then make sure uh we know um that you're interested in part of this activity, developing these technical specs uh for requirements and security threats. So you need to talk to Magnus or me, and we will try and set up something like this.

A

Is that a suitable way forward for the group? Anybody got any other comments on this proposal for it so activity before the November ATF.

B

Yeah I should should I write. uh You will created a sign team. Is that sort of uh uh what should I write.

A

You were right: I shall speak to my ad about creating a design team and people interested should contact me or one of the proponents. So we know their names.

A

Okay, I also have a slide deck from Michael and Hannis, which I think we can share I'd like to keep um 15 minutes or 10 minutes for the end of the session to discuss the UDP options. Work probably only takes 10 minutes, so you have um 15 minutes to talk about that slide deck. If you think that's useful, is that something you want to do at this stage.

E

Yeah I think it makes sense. So how can I bring up the slides if I click on meeting things I see no slides available.

A

Yeah yeah well.

C

You click on the ask to share slides then you're gonna. When you get the steps and from the shares you will get the list of the slides. That's been uploaded. Oh.

E

E

G

E

B

Thank you again.

E

Now I control, Magna, slides, yeah.

A

E

Know I can do change. Okay, yeah.

J

E

Okay, so this is about um RC 6083 piss, so it's about um updating s uh dtls over sctp, um not in a way I mean not with the with the intention to um fulfill the three gpp requirements, but to um update the spec and get as much as possible without uh uh using iprs, which I think Ericsson um has so.

E

um The first thing is pretty simple details over HTTP this one, all the one from from Magnus depends on sap authentication and there are generic things which need to be fixed and modernized and I. Don't think, there's a disagreement about this, so this is something generic.

E

This generic work, which has to be done anyway,.

E

The next thing is regressions from the original specifications. So when we wrote the details over HTTP specification, we were assuming that future versions of dtls provide the same services and we were wrong. So the first thing is that a new mechanism, key updates was introduced, and so the RC 6083 does not describe um what to do in this case. So this must be specified and the the the typical way to do is to update the sap off Keys um detail. The details 1.0 allows arbitrary long Communications by allowing an unlimited number of renegotiations.

E

This has been dropped in dtls 1.2 to 2, to the power of 16 minus one and in dtls 1.3 to the power of 64 minus on. So um yes, there is a limit, but using dtls 1.3 seems to be good enough for every practical application. So that's why we focus here on details, 1.3 and um details 1.0, you can get forward secrecy when you do renegotiation, but um this is not possible anymore in the dtls 1.3, when you do key updates- and um that means you can't do this for arbitrary long detail.

E

Dtls connections, no matter, no matter whether they run over HTTP or over UDP or anything yeah. So this is a generic issue which should be addressed in the TLs working group or can be addressed and materials working group to allow arbitrary down Communications.

E

um There are some limitations in Roc 6083, which can be relaxed. One is the the draining we were talking about earlier during when updating an e-park, and you can, by using a different procedure and allowing older keys to stay a bit longer in the sdp layer. You can.

E

um You can mitigate this effects of needing to drain. um What is uh how do you think? Is the user message type, so it's easy to bump them from 16k to 64k by uh using RFC 858449 in combination with the flex extension, where you say we want to make the message limit higher, and this basically keeps the mapping of a single user message goes into a single dtls record and a single DTS record goes into a user message. If you want to um relax that that's ivr protected by Ericsson.

E

So that's why we can't go to bed is larger than 64k, and the motivation here is that we think it's it's. We need a way to seek your HTTP user data um in a way that is implementable in open source.

E

um As you see here, the dependencies the required ones are generic ones, so it should be done anyway. um It's it's not specific to this. um The sapr stuff can be done in tsbwg. The dtls key update, updated key procedure would be done in the tsv working group if necessary, um optional. It's the the bumping of the user message limit. If you want to support larger messages, so that's that's how far you can get without using um the ipls. We think Erickson has.

E

Comments, questions.

A

Yep any comments, any questions.

F

I think, are you saying that you're going to bring in the TLs 1.2 Rene acquisition back I mean I thought it was deprecated because of security concerns, lack of use and complexities, probably uh I, I I. Think, though, I recollect some of the discussions that happens sometime back, but uh what is it that you're planning to bring back with regard to are planning to bring back what was Prior in the prior TLS versions?.

E

So I have no right now. I have no concrete suggestion. The point is it's: it's a regression, so something has um some feature which was there um has been removed. So I would work with hannes to see um how to deal with this so um to provide forward secrecy. When you do a key update.

F

E

But I have not I've right now. I have no um specific suggestion.

F

And why is the the record size increase that you're, suggesting with the TLs Flags I mean that doesn't seem mandatory with regard to the requirement that you could still fragment the messages and send them across right? So that does not look like a mandatory requirement to be supported, at least for the lies on statement that came from Mac. So why is that feature critical.

E

The message size of 16k is not good enough, and what we can do here is we can bump the message size from 16k to 64k, but not larger, because we want to keep the mapping of a single dtls record in the single HTTP message and a single dtls record can only have 64k you can do. You can fragment your user message in multiple Parts each part in a in its own dtls record and send all these details records in a single sap user message.

E

That's doable, but IPR protected, and the focus of this version was void. Iprs.

F

A

C

Yes, so um yes, I worked up before when we had a discussion about the application of 68 saying and replacing S63, which is tell us over HTTP base or not Etc I think it's. We shouldn't leave 60 to free alive, so we need something to either replace it or kill it. So, from that perspective, I think it's reasonable to at least take this work into working group and continue working on it. In parallel with with the figure solution that fulfills 3D people's requirements.

A

A

I guess we'll talk about that in in the IHF in November. Can somebody tell me what the TLs Flags workers in the TLs working group? Is that um something with momentum, something that's going to be finished soon?

A

B

A

B

Asking the TLs Flex extension: yes, yeah, that's uh I believe that's completed, work! uh It's for implementation. It's essentially it's an optimization uh that one can use to reduce the the size of the payloads. uh In this case, it's convenient instead of encoding a specific value. You can basically set one flag and then see if I want to Pump It Up.

A

Okay, that's what I want to hear? Okay, well, I! Think the feedback to Michael is.

A

Please ask on the list: if you see people wanting to progress this.

A

And we can do a call at the next meeting.

B

A

And everybody on the call, please, please have a look at it because the more people we have who have opinions, the better our decisions are okay, um I think that's the end of our currently scheduled sctp work. um I think it would be useful to look at the slides on UDP options just for those people who are following that piece of work. So we understand where we are going.

A

So if I can share that side, deck I will.

A

So um these slides are, on behalf of the UDP options, draft uh Joe's working to revise this draft he's currently responding to issues that are raised in the GitHub and therefore I think he's probably worthwhile running quickly through the list of GitHub issues.

A

But um do look on GitHub if you prefer Joe's plans will be to produce a new rev of the draft. In short time, rev24 is already being assembled based on the discussions here. For some reason, my slides go from top bottom to top, but maybe that's just for amusement.

A

A

I'm not sure uh we I think if anybody's got comments on these, please add them to the GitHub or please comment now at the mic. um We think the issue one might be closed. We think that issue two might be closed on issue three might be closed and these are all comments from the GitHub. So I am going to suggest that we close these. If nobody provides additional feedback, do you then have a bunch of design decisions we're talking about, um some of which have progressed more than others?

A

I think we need to discuss and decide the final shape of the authentication and encryption work and we are hoping to see that appear in a in a version very soon.

A

um Does anybody have any comments on these particular set of issues.

A

H

Yes, uh I have I have to agree with you that I think one two and three uh should just be closed. Of course, uh um I'm biased Joe took the basically took all the text I offered to fix those.

A

I'm sure Jill didn't take any tests without thinking about it seriously, so good, okay, so after this slide that's being presented, we will adjust the status of the ones which are closed right. We now have a group of items which are less complete.

A

We need to decide on what we're going to say about the what some people have called on the list: exposure of of information which can be used to exploit privacy exploits by an attacker or Observer that for other people they say well, it's just a protocol, header and all UDP headers are in the clear so somewhere between one extreme on the other.

A

We need to agree on some text for this issue, which is currently issue eight and if people with more security clear than me, want to help weigh in on that one, then that is okay as well. So a quick call out that um this item eight is to add a paragraph to the security considerations that says something about the fact that you're adding an encapsulation around a packet and therefore you're, possibly changing its security um characteristics, because you've added some plain text around it.

A

um Issue, nine is I, think no resolve uh good feedback comments on this. Go ahead.

H

I was resolved looking at the comments this morning, um I think we have just a little bit more text to get to go on that online.

A

Okay, um please make sure the GitHub says that.

A

um Issue 10 um yeah, okay issue: 10 is being debated by multiple people in multiple ways, but certainly the pseudo chord is not useful. The way it is so we need to decide whether we want um this level of complexity on how we write it and I think we can do that by discussion.

A

um I think Issue 11 is now closed or will be go ahead.

H

A

Good ah um I am not at all sure what I feel the issue 12 has reached, which is a design decision. So if anybody wants to chime in on this, please do.

H

I think your characterization is correct. We still, we still have people arguing about that. um You and I may be on opposite sides of this one.

A

That's okay as well, because I I can I can review my arguments.

A

Is it helpful to talk about it? No.

H

I'm not sure I added uh some things to the GitHub this morning before I hopped on the meeting. So maybe, let's just take the discussion there sure.

A

That's okay, I mean the OCS. Discussion comes from several different perspectives.

A

um One of them is whether we should just um keep this really simple, uh because making things optional, causes code, branches and the people who Implement things, don't like the possibilities of having to check things and then check whether the chord Branch was right or appropriate. There are other people who want it. There want an OCS to be always there because they see it as a way of checking the sanity of the option space and then there's an argument that um there are certain cases where the OCS adds little value and does outcome, processing complexity.

A

So, in these specific cases we might not need it. Is that reasonable summary of the three ways we're being pulled.

H

I'd, concur with that um with um one addition there that um if we wish to use this, uh you use this in tunnels without checksums. You really want the OCS off if you're, using UDP fragmentation in that tunnel, because the the OCS in that case is is uh essentially covering everything, but the UDP header.

A

Which shows yes,.

H

On each fragment and that, if, if you're, um if, if you are using UDP with frag with UDP fragmentation in a tunnel where you wish to have the checksums turned off for performance reasons or others, you would want to have have it both the UDP header checksum and the fragment OCS turned off for that application. That use case, if it's a real use case.

A

Yeah, okay, yep I, actually agree with you on that one, but other people might not. So um let's carry that one on the list. Thank you and then we have the last batch. So for those of you who are hoping for more, there are currently only 18 issues, active of which one has been deleted. Very recently, um Issue 13 I think can be closed.

H

A

Issue 14 said more clarification needed, but I think we might be very close to closing it. um Do you think we can close that one now with the text.

H

um There did seem to be some ongoing discussion, but we were pretty close to being closed, I think if I remember correctly, my comment that I posted this morning was that I thought it was good, as is.

A

um I, concur with that and I suspect um the other people have commented on the list on that. So and oh I don't know.

A

Okay number 15 uh I'd, like help with, because I think the statement in 15 is true, but I think Joe doesn't want to comment on how anything uses UDP options he wants to leave that to the application to decide. So maybe this is like one sentence: I'd added somewhere in to call it out very clearly is. Is that what we're talking about.

H

um If I understood correctly the discussion, um actually, this one was the one that I added comment to uh Joe was not wishing to have in the UDP options, spec a statement that only uh dlpmtud could use these uh options and I kind of agree with him. On that.

A

ah But that wasn't this yeah, okay and everyone agrees with him on that one. But I think the question was can't yeah. The comment was from another person in the working group who reviewed it in the last call who said that uh you can only return a res option when the socket is bound, which I think is now part of dplp mtud.

H

um They they're they're uh two ways to look at this. One is that you have a library that uh implements uh dlpmtud and you you uh attack you bury that in in the socket options and another is that it's more raw, but- and in that case the decision is with the application layer. That's seeing these resin req options. In any case, the UDP itself does not uh uh transmit a response uh without being told to do so that that was I thought. The really important part of that right.

A

Okay, so we concur I think we can I, think okay, fine, good uh clarification, um icmp messages were kind of discussing, but that will work its way out.

A

um 17 was choosing the right way to say that these aren't and naughty middle boxes do silly things with our packets um yeah, we'll figure that one out and Joe was going to add some of the design principles he'd already presented, which I presume will become text. So my and yeah go.

H

A

H

This morning, which was a typo and a really small typo in in the latest draft I, uh it should be trivial and uncontroversial to fix, but it's important to make sure it does get fixed. Okay, something snows, there's a missing knot that should makes it say the wrong thing.

A

Nips always dangerous, okay! Well thanks um my purpose in just spending 10 minutes going through. These is just to Bubble this up, so people can see that we are using GitHub to try and close the issues which other people have raised.

A

um We are, as a group, totally open to people commenting on GitHub or on the mailing list about these issues. They are by no means sorted out. Are they are no by no means finalized, but um they are being carefully checked by Joe, and most of these will be addressed in Rev 24., with the intention that then the draft can proceed to a final working group last call to confirm its publication.

A

So that is the plan. Anybody got any comments on the plan.

A

So, with one minute to go, my final task is to wish you all a pleasant, September and October. Please keep in mind that the working group is trying to finish some documents before the next meeting and and to also come up with some very clear guidance for the sctp and dtls work.

A

uh Please um try and read comments on drafts and come along to our meeting in the ietf in November we will have some new work to show I believe there are people asking for uh new work to be brought to the group, so we will have some new items also.

A

We have a set of notes prepared by Hollis uh and anyone else who contributed I see a number of people joined in online. If you want to go and check those that would be very useful and then we'll upload those to the proceedings as well. So thanks ever so much for spending two hours of your time. Talking about tsvwg issues.

A