Internet Engineering Task Force 110, 8 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF110-EMU-20210308-1200

Description

EMU meeting session at IETF110
2021/03/08 1200

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

A

At our scheduled start time, uh welcome to the emu working group meeting at ietf, 110, I'm joe salloway and mohit is also here. As a co-chair. I want to thank everybody for attending this meeting in whatever time zone you happen to be in first thing: we'll do we'll spend just a few short moments on the note. Well, I think most people are probably aware of it, but we'll leave it here, so you can take a look at it to understand the ipr policies of the ietf.

A

um Today we have a reasonably full agenda, but I think we'll be able to get through most of it. uh During this meeting.

A

So we do have uh some volunteers for minutes if people could also monitor the jabber uh room just in case uh the chairs can't uh get to it in time, and let us know if somebody has a question that needs to be put to the mic um blue sheets since you've signed in uh through the data tracker, everybody should be signed in and there shouldn't be any need to have any additional blue sheet tracking.

A

When you get to the mic, please state your name and always keep it professional um so for the agenda today, uh we'll start out with a little bit about the document status of our current working group documents. Then we'll have a update from the hackathon from allen the and then we'll have.

A

Iptls 1.3 discussion, which has probably been the most active on the list. Another discussion on tls base, eat methods and then a discussion on rfc 3748 bits. Did anybody have any other items they wanted to discuss.

A

I think roman do I need to do something here. Oops go ahead.

B

Yeah, if we have a little bit of time at the end which it looks like we will, could we review the milestones I believe all of them are in the past, so we can give a better sense to the community where we are with things.

C

I think that's a good idea.

A

I hopefully will have time.

A

All right, um I think our next uh topic will be uh update from the hackathon from allen.

D

uh Should we go through the document status? Oh.

A

Documentary. Thank you good idea.

D

I think it was just on the next next slide.

A

Yeah now I gotta get back to where I.

A

Was sorry all right.

A

All right document status, so we have in the rfc editor queue the large uh using epls large certificates draft. um We have requested publication for eep noob um for eep aka prime. I believe we're waiting on some 3gpp coordination. Do you have an update on that mohit that.

D

Yeah for yuri.

E

Yeah- maybe I can so so. Some discussion has been going on on some specific issues. If beza is on the call, he might actually be able to give a more detailed summary if we want to go in the details. But but the short summary is that discussion has been ongoing and some things have been fixed on their side and our side, and they have also wanted to have a call to discuss this on march 17th, and we can send some of the call parameters to the list after this call.

E

Yeah, I think that's that's roughly the status, so hopefully this is going to be done soon.

A

Great, thank you.

A

um Then. The other news is eptls. We've brought that back into the working group uh to finish uh discussion and uh finalize uh the remaining issues in that document. Along with that, we have uh tls based eep types.

A

uh That is a ongoing, very related document, that's in the working group um and then there's also aka pfs, which hopefully will be able to pick up as some of the other items complete.

A

Any questions or additional.

A

A

All right, then, let's go to the implementation report. Ellen are you on the line? I thought I saw you.

F

um Okay, so if we go to the next slide,.

F

um Officially speaking, the major implementers are involved. That being said, um there's some caveats. I'll get into later. um Testing is based on dash 13, for the simple reason that that's what the initial tests were based on november december.

F

And the desire to make sure that any new participants test existing code- and we don't have disagreement about what's done, where um the implementations tested at the end were client, microsoft and wp, supplicant and server free radius and host ip. So if we go to the next slide,.

F

We tested eeptls peep ttls.

F

The short summary is, it should be pretty straightforward to add. Tls 1.3 support with minimal code changes, um presuming that the tls layer is already abstracted out. So for the free radio side it was no more than 100 line, 200 lines of code just to tweak some things. The main issue is eep, tls is relatively straightforward.

F

Peep and ttls have a lot more issues.

F

It is essentially impossible to control the open, ssl state machine. um You sort of throw things into it and stuff happens, and you hope for the best, it's very difficult to say. This is what I want to have happen now.

F

There are some apis which are only available in openssl 3, which is not yet publicly released, and those apis would help us control the tls 1.3 stuff, a lot more so things like um in some cases, even though there's application data ready for some reason it doesn't come out of tls, and then these tls handshakes go back and forth after the session has been initialized and the initialization steps have been finished, but before the application data comes out, and so this confuses the various state machines which expect one thing to lead into the other right, because in tls 1.2 the assumption was that once the tls finished message comes out that all the tls negotiation is done, and this is no longer true with tls 1.3.

F

So I either have to update the implementations to control tls more or be more flexible about what's coming in the packets.

F

So if we go to the next slide, so things like, especially in open ssl, a lot of the api calls are configuration allow this versus. Do it now, um so you it is basically impossible in open, ssl one to actually send a new session ticket. When you want to send it, you can just say: allow zero one, two, three whatever and open ssl at some point, perhaps when it decides we'll send those session tickets.

F

um So, as a result, um tls 1.3 can't really be deployed with openssl 1 right now. Unless we do a fair amount, more interoperability, testing and tweaking of the various apis, it might not be possible with openssl 1..

F

We still have to go figure that in so interoperability mostly works, but there are corner cases which are unpleasant and still have to be worked out.

F

Next slide, yeah, um so for peep and ttls, we see these session tickets coming from the server all alone in a packet after the tls finished before the application data, and so the hope is to fix that my personal preference is, I don't want to see the clients updated to allow this kind of behavior because it seems unfriendly like if application data is ready, just send the application data.

F

But, as I was saying earlier, it's not clear that this is possible with openssl one, so we might have to work on that description a bit in in the standards um next slide yeah. The implementations currently will send and store one session ticket.

F

um It's not clear whether or not more than one is necessary, or why and then in terms of other implementers.

F

I've been in touch with the apple team, both at the higher layer network architecture and the implementation team, um zero feedback from them cisco's looking at it in more detail in the coming weeks and should have more feedback.

F

So the the hope is before we get this published that more than a couple of implementers um look at this and sign off on it. I'm not sure what tls library apple's using historically it was open ssl. I think they swapped to their own one, so that may come with more implementation issues as with cisco uh next slide, so we tested both the close notify and one application, octet data or one octane application data. um So these are client and server configurable flags.

F

The application data is preferred. um It generally seems to be not just easier to implement as noted here, but it seems to fit the the state machine model better right, overloading tls signals to mean eep state seems a little imperfect. I guess, and the feedback from the tls working group was that using the application data to signify tls state changes was also wrong, but if we're instead using the application data to signal beep state, that seems more in line with everyone's concerns, so the key exporters are still dash 13.

F

Nobody really cares what those are whether they're dash 13-14 or something else. It's a small amount of code.

F

But as noted here for the close notify, it seems difficult to convince the tls layer to send this closed, notify and so there's also some spelunking to do in tls application, interaction for peep and ttls.

F

F

I think that's it is that the last slide yeah so in. In short, it it mostly sort of works. um I I I don't think anyone's confident enough in anything other than tls, to say that it's it's production ready, so eeptls with the application data um seems to be pretty robust.

F

On a similar note, peat and ttls, at least for resumption, are robust, but peep and ttls and other methods are a little more um up in the air. I guess in terms of production status,.

D

Thanks alan, so maybe I can ask uh so some questions, so thanks. First for this excellent summary um and some of these things, we'll probably discuss again when john john is going through the tls 1.3 updates.

D

So one thing I guess, as a working group we need to, I guess, consider our answer is: how much do we want to tie up to open ssl, because I think that is definitely the predominant library used by most implementations out there.

D

But at least in some cases, openssl provides features which other libraries currently don't and I'm not even sure if they are planning to add them in the future- uh and I know like wps applicant, for example, provides some way of using wolf, ssl ins instead of open ssl. Obviously it doesn't have all the features so, for example, on this number of session tickets- uh one worry I have is I I actually agree with you that in most cases, just issuing one ticket makes sense.

D

uh It's more like for the web scenario, where you'd want to issue more tickets. But it's it's something that I'm afraid some libraries don't even allow. So, at least on the github issue that we are discussing in iftls, which is issue 48, I posted a link to boring ssl, for example, where the library has hard-coded two tickets.

D

uh Obviously you could change that to one and recompile the library, but it takes some effort so and- and we can come back to the exact uh exact wording, but maybe something along the lines of should uh issue one session ticket or and and not going with, must might make sense. I don't know, what's your opinion on that.

F

um Sure I mean you know in the principle of um be conservative, in what you send and and liberal in what you expect.

F

um It really is a hard question to figure out exactly where that boundary is between implementation support and theoretical behavior. Practically speaking, openssl 3 won't be released for a while, even when it is released. I don't expect many of the open source operating systems to upgrade to it, because it has api changes. It's mostly compatible, but it has api changes um and require requires additional application work so, realistically speaking, we're stuck with openssl one for the foreseeable future.

F

um If we can get everything working with openssl one, that's great, if not we're gonna have to add note saying by the way some libraries are broken and you just have to put up with it.

G

Yeah, I was thinking about the session tickers. I think one reason why you would like to send several session tickets in epls would be to remove one round trip during resumption.

G

You could send several in the initial handshake and then skip sending tickets in the resumption.

G

Not saying that you must do that, but I think it might be good to allow the flexibility.

F

Sure I mean it's one of these things, what whatever works? um The other question is, um and this is more policy but is related. What do you do about resumption across different media? So if you have um wi-fi and wired both configured for eep, should you be allowed to resume across? That should be you'd be allowed to use the same session ticket um everything, including 5216, and everything else in eep is, is completely silent on this topic um and that is related to the number of session tickets.

F

If you do wi-fi and then presume that you will be resuming on wi-fi and perhaps also on ethernet there, you may want two session.

F

D

So I guess maybe the summary here is that we need to like say that in most cases one ticket is enough, but there might be cases where you might send more than one session ticket, whether it's to save the round trip during resumption or because of limitations of apis in some tls libraries uh and and then then you need to make appropriate provisions on the client side either either to ignore the extra that you get or then have a database where you can store several and save uh during resumption.

D

What would that make sure sure.

F

Yeah and the the related issue is, you know, because the application is not really in control of when those session tickets get sent, um there may be early session tickets sent before the tls finished, which are then not usable and they're. Only implicitly, not usable, there's, no explicit hey by the way the session ticket I sent. You doesn't work so now you have to add more code to the client side, saying: oh, I got a session ticket before the tls finished.

F

Therefore I have to throw it away and only use a session ticket which came after that, and it's not even clear that the client gets notified of this right, because that is an ordering which is in the tls stream, but not necessarily available via the tls api to the client.

G

I think that session tickets and with the finish can be valid.

G

I don't see a strict reason why I know I wrongly said that such tickets was not valid before on the list, but that I think, is wrong.

G

I think there's no direct reason why such tickets would be invalid anymore.

G

F

Yeah, the the main thing for me is I'm not a tls one. Three expert and eight four four six seems to be less than clear as to um when those session tickets come out um after the tls finished. You know the session tickets do depend on that, um but are there earlier ones?

F

Possibly I don't know, but this is something you know before we put it into production.

F

We need a definitive answer from somewhere either this state will not happen or um you have to be aware of this state and work around it on on the client side.

D

Okay, george george.

H

Hi, I'm the implementer from microsoft. I think um the the main issue that alan is speaking about with early session tickets is mainly before the client certificate is validated by the server. So any session tickets sent before that are valid in tls, but you would not want to actually accept those if the eep negotiation is failing, because the client certificate is rejected, and so both clients and servers need to have some awareness that that can happen.

F

Yeah- and this was a source of issues in the past- is one of these. No, I can't help but feel at least partially responsible for the software. I wrote where openssl would cache these session tickets by default, um send them out whenever and then it was possible using eeptls or peep for the client to start the tls session not send the password get the session ticket hang up and then resume that session, because of that internal tls cache in openssl.

F

So as an application using openssl, we have to jump through all kinds of hoops to say: oh no, no openssl! Don't do that and then there's all kinds of ordering issues of you know. Openssl wants to do something and we have to catch it and stop it and cash in our internal cash for later so yeah it's. It is definitely an issue.

A

um I just wanted to check so we have seen implementation send session tickets early with the server finished.

A

Is that something we've seen ellen or.

F

Other implementations- I I haven't seen it I'll I'll. Let george speak, I don't think he's seen it either, but it does seem to be at least in our our interop testing. It does seem to be allowed and the um open ssl code is not at all clear. So what openssl does is something that I tend to run away from.

A

George or george, do you prefer jorge or george.

H

I prefer jorge, but either is fine. Thank you. um I don't think we we saw it with eptls, but it was.

H

This scenario was something we we did see in the peep and ttls testing, so um we had difficulty as alan was mentioning controlling open, ssl's behavior uh long before peep was finished, openness of wanting to send session tickets, and so we were fighting with it too, to prevent it from doing that or try to prevent it from doing that, I don't think we saw it with with the tls.

F

Pls was pls is rather a lot simpler and straightforward, um and this is you know to reference rory's comments about fighting with with opens to sell um yeah, it's impossible to say: please send a session ticket now um you can either send zero tickets. One tickets two three four, but you have absolutely no control over when they're sent, and you would hope that if you said hey, please don't send any session tickets. Oh now the session is established.

F

Please send one that somewhere in the open, ssl state machine, but realize that I could send them. That does not appear to be the case, so there were patches from ben for open, ssl 3, where an application could say send it now.

F

But, as I was saying earlier, that is not in open ssl, one which is effectively what we have to live with for the first for the foreseeable future um and to address john's commentary. Sorry mo he's coming to think about host ap yeah. They have three or four tls implementations, open, ssl, wolf ssl. They have their own internal tls implementation, but the functionality there is relatively limited.

F

um So again, it's one of these we're not sure that the requirements we would like um are possible to implement without substantial changes.

A

Okay, watson.

A

Oh, we still, we don't uh have your audio yet.

I

Hello uh watson lad cloudflare all right, it looks like it went through great. um I just wanna comment if you are building around openssl specifically and changing your standard modified, please don't because what's happening here is the terrible design of openssl is influencing these standard choices and ends up restricting what tls can do and then slowing the adoption just bad for the whole ecosystem.

I

Openssl was bad for the whole ecosystem. Please I'm! You know.

G

I

Someone who works a lot with tls, please make it possible for us to evolve tls independently of a saying I get sad every time I have to look at its code.

I

F

um My my point from a practical standpoint is we're stuck with it. um You know there are huge swaths of the ecosystem that will not be upgrading to open ssl 3 for quite a while.

F

So the the decision here is how little can we change the standard or the recommendations to allow the standard to be implemented with openssl one without breaking things too much? Some of this may be as simple as recommending that you know you just write more code to work through all these other states and say that all these other states are possible. Wave your hands due to tls library issues um and tls. 1.3 is a, as I was saying earlier, is a substantial change from tls 1.2, and so it may just be hey.

F

If you get something keep the tls conversation going, even if you get a packet, even if you get tls finished, you act that you get a session ticket all alone. When you expect application data, it's still negotiating. You should still continue sorry about this. It really shouldn't happen, but that's it same thing with um you know the number of session tickets. If you can't control when they get sent out, you know pick one that comes out after the client. Certificate has been verified as jorge was noticing or noting, throw the rest away.

F

um If you get more than one, if you can use them great, if not pick one um yeah, I I I hear this pain and open ssl is something I've been fighting with for 20 years. For you know, eep tls and various implementations.

F

um I I do not recommend breaking standard in order to work with openssl. I do recommend making sure that there's enough information in the standard that implementers can work with both openssl and other implementers who choose to use openssl without going through all kinds of code spelunking into internals.

A

Okay, I saw elliot there briefly, but it looks like uh you may have had his question answered.

A

All right, um so if we have any other implementers on the call, it would be great to get more participation as much as we can in uh implemented, implement interop events. So we can work out issues like these with other tlf libraries as well. I think it'll be good for obviously for epls community and I think it'll be helpful for the tls community as well.

A

So if there aren't any other comments, we'll move on to uh the next.

G

Presentation yeah: how do we process with the application data versus close notify?

G

There was a consensus call with no official conclusion. I think yet.

A

Yeah, so I think we well: let's um is this something that's part of your uh tls 1.3 uh epls 1.3 presentation which we'll move to next, so you cover that in one year.

G

Very protect the result indicate, but not the choice really is not so much included, but.

A

Okay, um well, let's uh make sure we cover it during that section, um and I think we can take a consensus call here, as well as as finished wrap that up on the list.

A

G

Good, so this is a presentation. This summarizes all the changes made since version 12, which was the version that existed at the last idf and then it goes through all the pull requests and issues on github, as well as alan's comments on the list the last week.

G

My hope is that we can hopefully reach see that there is rough consensus on some of these things, and then we can close these issues and maybe submit the version 15, which might not be the final version, but at least we have something submitted to work, and then we can agree what we don't have consensus and what needs more work yeah. So next slide.

G

So most of the changes since version 12 to 14 are clarifications. There might be some normative text change, but then it's mostly that comments from people that this goes a little bit against tls 1.3 and it should be changed. There's a quite a lot of clarifications.

G

There's security clarifications. There is clarification that the message flows are specific to tls1.3. It's clarification that errors are always.

G

Fatal um clarifications on this ticket lifetime clarification of ucsb status.

G

um A better example encrypted usernames, um I don't know- hopefully I I assume this or there's consensus regarding these- um will not go through them very much more. So unless there is any comments we go to the next slide.

G

So here are the major technical changes that was suggested by the idf last call directorates and mainly iesd and ben's. Discuss and ben's discusses was partly based on input from the tls working group. So major change was change from application data to close notify suggestion to update the key duration to be more modern with different labels, as well as using type code appended to the labels instead of in the context, and these changes may or may not have working group consensus at this part of the consensus call that you started.

A

um Would it be a good time to is this the only time you discuss these particular changes.

G

uh No, I think the key derivation will be this guy. The label, the con use of context or label will be discussed on the next slide, the other two things I don't have any specific slides for so this would be the case to discuss the use of labels more labels at all and the application data versus close notified.

A

D

So I think, having separate labels for msk and emsk instead of using the key and then splitting them into mske msk is better unless someone objects. I I think this at least. Hopefully we have some consensus of using separate labels for msk and emsk yeah.

A

Yeah yeah, based on this discussion discussion, I haven't uh heard anybody object to separating out the emsk and msk labels.

A

um But if there is I'd like to just hear if anybody on the call has any objection to the part of the key derivation which separates out the emsk and the msk, not necessarily uh how the type code is incorporated, but at least in using a separate label for.

A

A

Okay, um well, I think what I would like to do is maybe, since it's a little bit bigger discussion, probably um move the closed, notify discussion to the end, and then we can bring the other um ones up as they come up in your slides.

G

Yeah sounds good. Okay, then next slide, so I will go through them in there's no particular order, but the ones in the beginning are related to the isg discussion. So first issue issue number 32 on github is the use of context was raised by you, for example, on the list of the dynasty discussions.

G

So discussion is: does it make sense to have uh have the old where the type code goes into the context or the zero 14 version where it goes, is appended to the um labels and and no context context is mixed up here should be the opposite order. There was also a recent comment by alan on the on the list that is uh pre, adding things to the labels or going against the ayanna register, and that this should be consulted with tls.

G

I personally agree with alan that this is a bit strange, but, on the other hand, is I think this change was made based on feedback from people in the tls working group.

G

A

Yeah, as far as the you know, I I think it is a little bit problematic to include them in the label for the inr registry. I think for epls you would you could easily specify that the type code would be. I think you say it's a heck so 0d or something like that, and that would be the label registered with iana.

A

You wouldn't register this variable label, and you know whoever picks up this spec, to use it and say ttls or or fast or some other uh tls derived protocol would register their label uh with the with the type with a different type code um which might.

G

Be an advantage.

A

um And that you would make sure that you had different labels registered for each of these, and it would reduce some potential for confusion, but it also could be a disadvantage and then it makes it a little more complex.

G

And there's basically three variants on the table. Then.

D

Well, I guess maybe it will help the like. We can agree on the exact label we register with ayana, but maybe it's better that we agree, maybe on the fundamental question of whether we have a context or not and like personally either way is fine. I think.

D

Both martin and ben were being more pedantic that saying it's for connection value. The context is per connection and therefore this type code is perhaps more suitable than the label.

D

uh If you know they approve it being in in in the context, I'm I'm fine, otherwise having it in the label and and, as joe said just instead of having this plus appendix actually registering the full label, if underscore tls underscore msk underscore 0d, for example, might make sure that there is no overlap so yeah, I personally think just having everything in the label is fine.

D

We could also like support libraries, which don't necessarily allow context, but no no strong opinions like whichever gets the document moving forward, is, I guess, more important. At this stage. Yeah.

G

Should we try to do that and register specific labels for the different method? That seems to that? We know, will come past iest and it addresses alan's comments, also that this goes against, that I am a registry.

F

In terms of you know, the tls review per mo eats comments that the context should be session information. The the simple pushback there is. There is no session information in eep right because eve can go over ppp um 802 on x. You know anything, there's there's pana collab now, apparently there is no session.

F

We can put into that context. um So for sheer laziness, my preference would be to put the type code into the context um and that way, there's less work for implementers to do and the iana registry doesn't have um 60 things, all of which are minor variations of each other.

G

I agree, I think, that's the best solution. That's why we had that solution from the beginning. Do we know if we can get that past ben's discuss, or should we try to do that? That's also what have been tested in the hackathon. I guess so should we try to go for the context again unless ben says that this is not okay and then we go for different labels.

A

Is there anyone that objects to uh using the context.

A

B

Yeah, I was going to say I it's, I don't have an objection. I was going to interject kind of a process thing. I I. It seems like a lot of work to try to rev a bunch of code if we're not sure that this is going to be an acceptable resolution.

B

So one thing I could do is I could talk to kind of ben and the rest of the isg to make sure that we are comfortable with that before again anyone has to write code, uh it would be a nice step after we have that informal nod to to get that verification, but I can ask first.

A

I think most of the code yeah, I think most of the code is already using the context I mean. Maybe some people have implemented both but.

F

Yeah, I know no one's implemented the type code in the label um that that's not done, there's no configurable flag for that and, realistically speaking, it's not huge amounts of code to change it. um It's just. Why have an unused field and then make your life more complicated when you can just use a field? That's.

A

There, okay yeah, so we'll probably want to check to you know. Obviously we don't want the block document blocked on this, um but it seems at least from the list and and from this discussion here- that going with the type code in the context would be the preferred approach um and it, but it's not something that is a blocking issue if we had to change it for, for some other reason,.

E

All right, thank you. Next slide,.

G

So these are two pull requests based on the uh these are based on the isd and the previous comments that we didn't miss to put into 14.. So it was uh several comments. How this document relates to uh alan's documents on tls types, so now to this has been added as a reference and in two sections, both in the beginning and in the key derivation then also a comment uh that these message flows how they relate to earlier versions. So it has been added that is, example, message, flows specific to tls103.

G

There's no issue related to these. These are only pull requests.

A

Okay, these seem pretty straightforward to me. I don't know if anybody has any objections to.

A

G

A

Yeah, if anybody has concerns here, um we can uh avoid them now. If not, uh these are probably things that can be merged. I think.

G

I think my plan is to try to merge and submit the version 15 for everything that there is no objection to.

A

Yeah it'll take probably we'll probably have to go to the list for a couple of these things.

E

A

This one, I think, is more editorial.

G

Good so 45, so this is related to um new session tickets. This was a lot of discussion during uh alan's um comments, um so this no. So this is yeah. This is clear. Some guidance by resumption is needed and also some where the new session ticket can be sent. So there was a lot of discussions. Why you? Why do you need resumption at all and what is beneficial for- and conclusion, I think, is that resumption is very beneficial in etls, due to the number of due to packet, fragmentation.

G

So and then there's a correction that the ticket does not contain a psk. It has a associated psk to derive a psk based on the I think, the identity and the ticket for the nonstory. I don't remember, but it's not indeed.

G

G

Is there any comment, I guess we can go to next.

A

Yeah that one looks good next.

G

So- and here is here's guidance on new station ticket, so this was first, it was discussion in isd ben pointed out that the drop ship mentioned ticket request, and that was done.

G

Then there was comment from alan that we should have much more um guidance, and this text in green here was what was suggested on the issue in github. I think I been worried you I don't remember um so that is that they should take into account that fewer new session tickets will likely be needed for etls and in most cases the single new session ticket will be sufficient.

G

um I made a police based on that short. I think, based on alan's comments. We, I think, there's more guidance needed here, both security and for implementation.

G

It was a recent comment by alan on the list that the draft should refer to rfc 8446. I agree that that's a good idea and then alan also wanted to restrict it more to worry.

G

I don't require is very restrictive. I don't, I personally, don't think that's a good idea. I think, but expect here is good and that's maybe already what is.

G

A

Okay, yeah. I think this is going to probably take a little bit more discussion, especially, I think the what became a little clearer to me in allen's uh implementation report was that there are problems potentially with implementation, sending new session ticket early. I I have to go back and look at the tls 1.3 spec, because I'm not sure if that's a valid thing to do, because I thought the resumption key was derived from both the client and the server finished.

G

But it might still be, you cannot derive the key before before. You have received client finish, but you can still use the ticket. If you would like to. I think.

A

Interesting: okay,.

G

But I think we definitely need to sort out all the security problems here. Give guidance on that.

D

A

Guess go ahead for it.

D

uh Yeah, I guess for this one: we need to still wait out a little bit before merging into the repository.

D

So I think what we have conclusion is that we should say that in most cases, one session ticket is enough and then list out that you might send more because of limitations of library or you want to prevent extra round trips during resumption.

D

What remains uh is how do we then like schedule when this new session ticket is sent uh because in in in the web scenario like there is very rarely any client authentication, whereas in epls predominantly there is client authentication. So you would want to issue session tickets only after receiving the client certificate and verifying it, and if libraries currently don't allow you to like pick an appropriate time when to send that new session ticket, then that also needs to be documented.

F

Yeah helen, for me, that's real yeah. It really just needs to be documented, as here be dragons right. Otherwise, what happens is um you know jorge, and I and various other people working on host ap um have just been beating our heads against this for months. Exactly what does the tls layer do? How do you control it? um It's it's best to write all this. You know interoperability, hackathon, report stuff down and go by the way with tls one. Three almost anything can happen and you have to be aware of it. Sorry.

A

Yeah and clarifying the behaviors would be.

A

A

Okay, any other uh comments on new session ticket. I think um there's a we. I think we've made progress on uh the issue of how uh how many session tickets need to be sent. I think that we can give clearer guidance there. um I think the issues of the ordering of the tickets and the how those are handled is still open issues that need to be resolved.

G

Activity on github in this issue would be appreciated. If you have anything to comment.

A

Yeah, it's a good point. I also posted to the list. I don't know if we had done that previously. I can't remember, but I did post where the repository is in github and it's a vassal authors to use pull requests so that we can track the issues better going into the document and having comments in the github are is is good.

G

G

So yeah, so this is about packet modification attacks. This was raised. I think the first paragraph here was raised during the isd discussion was, and maybe also during the sec picture. It it was. People did did not understand what an attacker could modify and what so.

G

This pull request tried to summarize what an attacker that an attacker can actually modify quite a lot and then also it was a comment from bernard about the during this discussion of protected failure that this was important for availability.

G

uh Then there has been a discussion on guitar. I think the conclusion is that the tls is quite it's. I think this academic paper about protected failures was they. They tried to focus too narrowly on one attack, but there's basically any number of other attacks that do the same thing. Basically, any package you send to tls makes it fail. So there's basically nothing we can do here, but that's probably acceptable, because you can always try to connect again and there's a comment from you one. So these two have been added to the pull request.

G

Also comment from you that the similar text is needed on success. Indications, but based on the discussion between bernard and mohit, it seems a bit unclear exactly what what and when the protected success protects against. So.

G

J

I don't understand where it says that protective failure uh may be unauthenticated. um The whole 3748 defines protective failure, as what does it mean to have integrity protection but are unauthenticated.

J

They've got to be integrity, protected right.

D

Well, if you do opportunistic beefy helmet and then use the keys from there to to protect the failure indication, it's integrity protected, but you don't know who is sending like or like you don't you haven't authenticated. Who is sending that so in dls 1.3 uh at least some of the early failure?

D

If and john you can correct me, some of the early failure messages may be unauthenticated if you have not yet received the the certificate of the other end point, but they they will still be protected with the with the first dp helmet exchange or keys, resulting from here.

G

Okay: okay, yeah! That's my understanding.

F

This is alan. I I think for me the main purpose to have protected failure. Is it's it's generally good to protect your your application signaling, but the only thing I really care about is that the errors get back to the end user and administrator um and protecting them seems to make that they make the correct errors go back right, so you get you know, certificate expired or whatever, rather than the ubiquitous failed, and now nobody knows what to do or how to fix it.

F

So the protection here is ensuring that it's, the correct error getting back packet modification is just yeah. Something went wrong with the connection, which is rather a lot different than the server. I trust told me that my certificate has expired.

G

There is a upcoming slide on maths and error, which is related to the more finding errors yeah.

D

Well, at least this uh text looks fine to me and I would be uh at least happy to see this merged before we publish 15, but others can obviously chime in.

A

K

Guys, thanks for the opportunity to comment- um and I think this is okay- uh just to allen's point um anytime, you say errors get back to users, be careful with that one, because there might not be a user on at least one end of the connection. And and if that's your goal, we, you know it's it's a deep, deep rabbit hole um which I don't.

F

K

F

F

Yeah, um I I I guess my position could be more stated as I am against the idea that no errors go back to the user, um which you know is is not proposed, but yes, requiring things going back to the user is rather too strong.

K

Okay yeah that, but this is otherwise I mean as far as it goes, it's okay, it's a this! This is a really hard problem, because in the context of iot in particular, and something we we don't, I don't think anybody has a good answer for by the way so.

A

Okay, so I think the the spirit of this um you know modification is is good. I think maybe there's a little wordsmithing that maybe could go on to make sure that we're clear on uh what what some of these uh things mean, but I think it should be pretty easy to resolve. Ellie did you have uh more to say.

C

G

Good then, next, so here's an issue that I opened so tls working group has decided- or at least they have adopted, um rfc 8446. This, which changes the terminology for tls, 1.3 and tls 1.2, and this terminology change is to remove master everywhere and replace it with main and where master was not really needed, it's just removed.

G

So the suggestion change here is to do this before publishing, because this will be the future of tls, so change master secret to main secret and export the master secret to export the secret, and that would be the two changes to the tls.3 document.

G

I think there has been no comments on github on these proposed changes at all.

A

Yeah, I think it's better to align with tls modifications now, instead of having to make changes later,.

G

Good, so this is uh the issue here related to the mustang error discussion we basically already had. uh So this is another pull request that says that you, uh whenever an implementation, encounters a fatal error condition, it must send an appropriate tls error, alert.

G

And also some all this green text here is new. uh I don't know if the text was suggested by ireland or based on suggestions by alan.

G

Yeah and then comment on github, I think from you that user cancel behavior needs to be clear. When we talk about error- and I agree problems with this- is we probably need to wait on the consensus for protected indication, success of failure before writing something about user cancelled and then the use of user cancel in tls 103 is unfortunately unclear.

G

uh The specification is contradictory and an issue has been opened for the beast version. The the issue was opened by based on my comment, so I think there's agreement among the tls people that this is unclear.

A

Okay, unless there's a more discussion here, I think we'll have to see how that discussion on uh 8446 bits can.

C

G

Good so then here is uh text on the e state machine, so this is based on suggestions um first from uh mostly from bernard in his mailed mail some months ago and then based on discussions on mostly on the list. Maybe some on github also.

G

And yeah, I don't know if people have read these pull requests on on github.

G

But I think to finalize this section, we would need a conclusion on what to use for protected indication, but successful failure.

G

And this references three seven, but uh but only in the info, it references it describes how you would implement according to 4137. But as this is an informal document, it tries to not make it normative to follow four one. Three seven, um even it seems that my understanding now is that, basically, all implementations are following.

D

Yeah, I guess this is the perhaps the most important and biggest issue we need to resolve is so I think the error and failure alerts. Is we more or less agree on? It's mostly on the protected result, indication whether it's closed notify or the one byte of application data.

J

Bernard yeah- um and this is probably more of a question for alan and jorge, but um given the issues in the tls libraries about sending a closed notify, um are you. It seems like that. The question is closed, at least for you guys, or am I interpreting that correctly- that it really has to be the application data, because you can't get the close notified? You can't control it.

F

um From most of the issues is from my side and open ssl I'd say it's an open question right. um I've had my my guys looking into this and it's one of these. You know tell openssl not to do a quiet shutdown where it just closes the connection and doesn't send close notify, so it should be sending the close notify.

F

We say: please shut down the tls connection, it appears to we say: is there data available to send to the other end, and the answer is no, um so the question is: are we using the openssl api incorrectly or um is openssl 1 just completely broken here? I I don't know enough to say what I do know is sending the one byte of application data is a well-tested code path, not just for eep because of peep and ttls, but for tls in general.

F

I think we're probably running into a corner case an open ssl where it just doesn't expect to do the full setup and then tear it.

G

Down, I personally think application data seems like the most logical choice now when we are talking about protected success and not commitment to not send more handshake question, do we know that application data will work with all the other e methods and do we know if application data will pass ben's discuss? I don't think I've seen a clear answer on that, but I assume ben would not have a problem with application that that data has a predicted success.

G

I think his problem was with trying to profile affecting the tls state machine.

F

Yeah, so my take on that would be that the application data is an application layer signal that each tls is done and as a side effect, the etls layer promises not to do any more tls negotiation, so you're not making a statement about the tls layer, which is what some of that original phrasing sounded like you're, making a statement that the tls implementation and the eeplayer promises not to do any more poking of tls for the other eat methods.

F

The application data isn't necessary for normal authentication because they send their own application data and for resumption they're exactly the case of eep tls for resumption and from a practical point really, the only difference is that you type code, so it works perfectly fine there.

F

um There is some caveats I'll I'll get into later with the other eep document. But yes, application data should be perfectly fine here.

G

Should we try to go for application data after checking with ben that this will pass his discussion.

D

I think we should just put this in 15 with application data, and you know this will go back to the the new isd that gets seated and we will see my feeling is if, if I understood ben's previous review was that it was mostly because we were using it as a commitment to no more both handshake messages that was causing the problem and using it as a success. Indication should be fine and, and it should pass through the iesg, so I don't think we should wait for that.

D

Just do this publish 15 and we seem to have implementations that are currently using the one byte of application data yeah.

G

And then, as soon as all alerts would be tailored.

A

Yeah so yeah, I think, um unless uh I I think for me, we we have interoperable implementations with uh application. Data um and closed notified seems like even if we can get it to work, there's a little bit of question as to how much control you all have over that message, and I, I also think that uh you know the iesg comment is something that uh was more on it. The way it was uh phrased to be a control, how tls was behaving than how he was behaving, so I think yeah.

A

We should move forward with that unless anybody and give anybody a chance here to voice any objections that they have to using application data instead of close.

A

A

Okay, honest, I don't know if you want to say anything at the mic or not.

C

Can you hear me?

C

Yes, okay, um no, but I I I will definitely uh look at the open, sl issue and I also wanted to um implement this uh document in embed dls, which I didn't got to uh last week, because um the suit stuff took a little longer than I thought everything always takes longer than I think.

A

Okay, cool yeah. It would be great to have another uh implementation implementer, so I I know uh alan and jorge and folks would love to have another implementation to interrupt with. So that would be great.

C

We'll get in touch with them.

E

G

G

So this is about more information and in key derivation and beating down.

G

I think this was raised by martin thompson and you and I think it seems to be consensus that no, if more in additional information is needed in the key derivation, whoever it seems to be consensus that the text in rfc, 521, 6 is lacking and that more guidance is is needed, and this is currently only an issue. There's no pull request.

G

This is, I just took the latest here's the latest suggestion by you on the github issue.

G

I think we need what is needed is maybe some high level security requirement which might not go into details and then guidance on different ways. How to do this securely.

A

Yeah, I think this will need some more discussion on the list.

A

um Probably, although it's be good to discuss here, if people have uh views, I think currently it's a little bit uncertain how implementations behave and and what we would recommend them to but well I guess there is a some good examples that we can follow with kind of what like what um uh edgy rome does, um but uh I think we need some some guidance here.

G

Yeah more discussion on github and and or actual pull request suggestions would be.

G

G

G

So and then I think this might be the last slide. So this is the summary of alan's review that was sent in the last week.

G

Maybe we can discuss these points one by one. The first is that it says that the document defines this with etls1.3 or higher nylon says this is not true, and all references to higher should be.

F

Removed well, I run into implementation issues. As I noticed, um this came up as openssl started, implementing tls 1.3. Suddenly, all kinds of people complained that hey everything started: negotiating tls 1.3 and it doesn't work, um and the answer is oh yeah.

F

Neither neither the epir nor the server side put maximum limits in the supported tls version and those definitely caused deployment issues. So my two sensors. We have no idea what tls 1.4 is going to do so. This document, based on past pain, should suggest that we do tls 1.3 and everybody forbids tls 1.4 until such time as we know that what that means.

D

Well about this uh tls, 1.3 or higher at least I'll, have to double check. If I'm quoting rob correctly uh from his isg review, he was also saying that the previous epls document was not tied to a specific tls version, and why is this document specifically tied to tls 1.3, of course, knowing that none of us are at least I don't know what tls 1.4 would look like. Maybe it has all sorts of post quantum, magic and whatnot, and maybe we'll have to do everything in etls from scratch.

D

But if 1.4 is, is you know similar or exactly with minor modifications to 1.3? Maybe we won't require another update to the epls document and it should be independent of the dls version. I'm not saying I have strong opinions on on this, but I also see rob's point, at least from his isd review, that maybe we can leave it open and if there is a dramatic change in the next tls version, we'll we'll revisit and update or obsolete this.

G

I agree with allah that or higher should be removed, because we don't know how tls 1.4 or 2, but top 0 will look like, but I'm I would prefer to keep it open, just writing me and that we don't know how this will work with with future versions. Rfc 5216 works quite well with three different versions of tls before it.

G

It didn't work.

I

Anymore, um yeah, so I I think that we should look at what quick did a similar thing and it, it seems, like, like um eap, is unfortunately very tightly tied to details of tls in a way that a future version hopefully wouldn't be, or you know something needs to come out of this, where it's like, if you're going to work on tls 1.4, here's what you need to do to avoid all this pain.

I

G

Yeah, I think it has been during this work. There has been very different comments on what epls should be. We have having comments that, if tls should not specify anything about the tls version at all. Yes, the interfaces between tls and 103, and then we have comments from implementers that need to specify very much. Otherwise it will be security issues yeah.

G

I think the current status is somewhere compromised between these views, probably similar to what rfc 5216 was.

D

Yeah, I just really honest comment that there are plenty of experts who will be there to standardize the epls 1.4 whenever that comes, so I guess he's uh yeah suggesting we drop or higher, which is, I guess, fine.

K

Elliot yeah, so um I think, there's I think, mohi you just captured it right that that that is definitely where I, where I see things as well. What I was going to say, though, was that um I think one of the things that should come out of this document is um a bit more participation um in the tls working group from non-web users of tls.

K

I mean, I think, we're feeling the pain. The group is heavily web-based and you know that's all right.

K

It means it's a very, very large use, but it's sort of on us a little bit to keep those guys reminded of what is necessary to implement beyond that one use case in particular, um what might be useful for the next version of tls, which you know got who knows when it's going to come, but it might be useful just to make sure that there's an understanding of calling interfaces for non-web use cases like tls or um other uh non-web use cases, maybe relating to uh maybe industrial cases, hana, something I'm sure you could come up with a good zillion examples as well, um so maybe just a short report once we're done saying you guys.

K

Don't forget, don't forget about us the next time, maybe even a short document. If somebody wants to write it and I'd be willing to help along those lines, because I'm sort of waiting in the wings, because you know I've got another document, that's sort of going to have to track what you guys are doing here and- and I'm just you know, scared you know quite a bit well, I was going to say another a word I shouldn't say here, but um I'm I'm rather scared about how I'm going to proceed with that document.

K

uh Given what's what I'm trying to learn from what's going on here, so I'm sorry, I've been taking a little bit too much time on this I'll. Just leave it at that, though. Thanks.

A

F

Yeah, so I you know I'll go back a while and say that in fact, the key exporters in tls were defined coming out of the needs of etls going back to gosh. I think it's 25 16. I don't remember on the original epls doc reached into the internals of tls um and uh and mucked with it in order to do what etls needed um realistically practically. I think, if you know tls call it plus one doesn't change the key exporters or if it doesn't change the key exported apis, we're probably mostly okay.

F

um The problem excuse me the problem with tls 1.3. Is it changed the state machine? You now can do tls negotiation after the finished message has come out and that breaks all the eep implementations um and the tls.

K

Working group for good reasons- yeah sorry, I'm just gonna- say I don't think it's the. I don't think he's the only thing. That's gonna break on that.

F

Yep- and it may happen again in the future, because you know realistically what 80 of traffic on the net is. Is you know web variants, tls variants at this point and um yeah protocols are designed to keep them happy and everyone else sort of has to dance around the stomping.

G

Elephant yeah, I I guess.

G

More people should have been active in tls 103. I don't think it's a bit.

G

I don't know if people were active and was voted down or was is the problem is that people were not active in the tls 103 development.

A

Well, I think tls 1.3 made some fundamental changes to the protocol that were kind of in order to reduce round trips, and things like that that you know were on were sort of unavoidable in the design that were going to cause this type of problem, and we should have do. We certainly should have done better, probably in keeping the two groups in sync, especially since you have a chair between the two groups, um but that didn't happen as well as we would have liked.

G

Okay, should we try to move on? I think new tickets we have already discussed the bullet3, is no peer, authentication adds new pre-authentication. I don't think that's true. New period authentication was allowed before what is added is a figure.

F

Please note that section 5 doesn't discuss the security and implementation or implications, sorry of not authenticating the peer, um if you're doing ebtls with allegedly client search and then not implementing the pier.

F

There are certainly use cases for that, but it has to be discussed that you shouldn't be giving these people wide open access to your network.

A

Elliot, are you still in the queue bernard that.

K

Hand forgets to go down.

J

Yeah, I think allen makes a good point because there have been security vulnerabilities in that area. That have been discovered. So you have to be very, very careful about managing resumption.

J

You know you don't want somebody resuming from a no pair on authentication to a session where it's assumed appears.

E

G

Yeah any any guidance here how to improve security, for this would be very helpful. I'm not against that. um I think that these documents add peer authentication. I think it's not correct, but any guidance on this, maybe someone can um suggest something based on seems like this is um sounds like this is security problems that are known and what to do with them.

A

Yeah we should. We should open up an issue for, for these.

G

G

Then backwards compatible. The document doesn't say how this is. I think this tried to refer to the tls version negotiation that should probably be clarified.

G

Don't know this point, you say.

F

um One or two sentences of we rely on tls and oh by the way, there's nothing in the eep tls headers to allow any kind of version.

F

F

G

Yeah good then we have next is hello, retry, request um anna says no explanation on how this affects etls and but also suggestion that it doesn't appear to affect tls. um So I hello, retry request is new in tls 1.3.

G

I think we need to allow that. We don't think either that it's it's effects.

G

I think any. If there is any effect would be.

G

I would be happy to add that to the document, if somebody makes a pr or share something on the.

G

G

Identity and answers that gishon should be to use the same identity from the first full authentication, and he says this of the number of potential privacy and interoperability issues.

G

uh I personally don't really see how this solves privacy issues is like selling. Something twice could cause privacy issues and also comment that I think type d specification will send the same clear text, identity but encrypted so that they on the buyer. They would be different.

F

Yeah, this is a change from some of my earlier comments uh using the tls psk identity in the eep identity.

F

I think in the end, tls can probably just rely on the tls layer to say: hey, you have session tickets, whatever magic goes on in tls. This session has been authenticated and has been tied to a previous user session. um It just seems to me that there's no real benefit to using this encrypted tls sk identity in the eep identity field.

F

You might as well just use at realm all the time and it makes things simpler.

F

I

uh So I just want to point out that or watson on cloudflare. I just want to point out that in resumption you may your implementation has to keep track of the credentials used if you want to have a notion of of user identity.

I

So if you resume a session and you don't store the client certificate, you don't have it in the resume session, and so, while it's true that the that the you have some way of of storing this in the ticket, so it might not always be possible depending on what implementation is doing. How they're hooking in dope is. I suspect that this is part of the part of the issues that we're seeing with with session tickets.

I

Where it's you know, I looked at rfc, eight, four, four, four six: they can't send a session ticket until after you've sent the finish on your ad and if, if that session takes for whatever reason is it doesn't contain the credentials that were used and later you're trying to verify I'm not sure whether the receptions happen or not, then you can run issues.

G

I don't really understand to comments here about psk identity and identity response in eb. I don't think the document says that you should do that. I think the only sentence I can find is that says that psk identity is unsuitable for use in the identity response.

F

Okay, so I'll double check that um and for uh previous comments yeah, this is what um eep server implementations have been doing for quite a while is, is caching all the policy information from the original um authentication and reapplying it and reevaluating it during resumption, and that gets into the other issue of no peer authentication where, if you don't have an identity, arguably you probably shouldn't do resumption too, because you can't apply policies.

G

I think we open an issue for this identity. Then uh next bullet is uh defines key exporters for tl other tls base the methods, the working group order document, which covers this topic, except as working group document. Prior to these changes, I don't think this document specifies key exporters for other methods. I think it specifies a key exporter for eptls 1.3.

I

G

I think the working group.

G

Agreement as I remember it was that it should define only for tls.1.3 but define something that could be used as specified in other documents for other methods. I I don't. I don't really know what you want. What kind of change you want here.

F

The the thing is the text in the document explicitly says it defines these exporters for other methods um and, if we're going to keep this to.

F

Tls just etls, it should just define its exporters for epls, as I think you would make these changes already in an earlier slide and then simply point to the other document and go hey. There's similar things elsewhere,.

G

Yeah, I think the version github might be better all already yeah, otherwise,.

G

Yeah I and the last thing is additional- leaves a lot to be implementation defined. Yes, we can try to add more more guidance before publishing this. Otherwise I think this is the last.

A

All right great, um I think we should open up github issues for most of these or the ones that we still need to have more discussion on which I think is most of them, um and then I think we can. I think most of these will be relatively straightforward to resolve a couple of them. Maybe take some more discussion, all right.

A

I suggest we uh move on to the next agenda item that took a little bit longer than what we had thought so.

A

Eep space tl other tls based eep.

F

Types yeah, so there's only one slide here, I I think there's been some standard discussions on um any of the important topics elsewhere, specifically in the implementation report.

F

In short, things mostly work resumption is easy, open, ssl is horrible, and the question is: what text do we put in to go? Hey would like to fix open ssl, but we can't so here are the corner cases that you have to worry about and, as jorge was noting earlier, these these corner cases are specific more to peep and ttls than to etls, which seems to be pretty much okay. At this point,.

A

One of the things I'd like to see is is more discussion on this particular document and the other eat methods um as we're going through these ftls issues, because these these discussions may have implemented implications on these other documents. It would be good to get those out now so that we can get this document maybe out at the same time, or at least shortly following.

A

A

So I encourage people to read this document, and uh maybe we can get some comments on this as well. Any particular comments on the in the group.

A

A

All right, then, let's move on to, I think what is our next topic, which is rc 3748. This yarn.

E

Can you hear me all right?

E

Yes, all right, um so this is uh the beast document for 37.48, which was published 17 years ago, and um you can see the obviously. The draft is in the iotf directories, but you can see the difference to the original rfc in this our code.com link and if you go to the next slide, so what are we about to do? Well? The first thing is that you should not panic, we're not doing something horrible here, there's nothing fundamentally wrong with the existing rs. It's it's pretty good and we're also not changing the protocol.

E

However, there are some updates that we could do together. The next slide.

E

So there's some some potential things we could do. We could fold in errata or other issues observed over over the years.

E

We could probably update the security bits quite a bit because we think about security in different ways today than we did in 200 2001. When the work on this current rfc started.

E

We also have published several core eap protocol documents since the publications of this rfc- and they aren't pointed to by this rfc, we could have an opportunity to put in some more references.

E

The authors of this particular update thought that it would be a good idea to change one or two of the terms. I will talk about that in a bit. We could update the references and I guess overall, there's nothing earth shattering here. We could go on, but there's opportunities to clean up and provide more information.

E

You can think about this. Like the you know, your car's a yearly maintenance and if you didn't, do the yearly maintenance in 17 years, there's quite a few dents in the car that you know, maybe you should have fixed, and some of that might actually give you some headache next slide, please so the specific updates- and I I don't want to spend too much time on any any of these balls- let's very briefly mention what what this is about. So there's, actually one errata, a minor thing, that's fixed here.

E

A bigger thing is that, like obviously, we know now more about the various eap methods and some of the algorithms, so, for instance, there's some text on md5 and so on and and the issues with that. We also point to the newer, newer methods, uh because we felt that that's uh reasonable. uh We added one security claim. That's remember this: a set of security claims requested for for all methods. We added one I could discuss if that's the right one or if other other things could be added, but we did add one.

E

We also refer to these other base or core eap documents like the state machine, the keying document and so on.

E

The terminal exchange is kind of analogous to what john was talking about in the tls side of things, so master change, domain um yeah, you know not a huge deal, it's not one of those master slave type of terminology issues, but we felt that this would be better.

E

We've updated the references we discuss. Also, I mean the original rfc discusses mostly.

E

Name portion of the ni in uh eap response, one part of the document and updated the iona rules. And if you go to the next slide,.

E

So there's some open questions as well likely you could say more about security. We did not uh make a full listing of all the attacks and everything that that we've learned since then that that might actually be a useful exercise um and also since we do have some of those other documents, part of the core eap specifications. It might be that some parts of this document could be thinner and point to those other other rfcs.

E

Maybe or maybe that's not good, because we want to keep things self-contained.

E

The ieee references and discussions are fairly dated. I felt we felt I could probably update that and finally there's a comment around passwords and passphrases in general for all eap methods and they point to uh sassoprep and some of these international characters at issues and that reference is like very old and it's been updated, two or three times to newer rfcs, and I did not at least know what to do with this. I don't know if the old rfc still is valid.

E

This would be replaced by whatever was replaced in the ietf or it's some other discussion that should be had here, but that's clearly an open issue and then next slide, which is the final slide.

E

So basically, this is for your consideration. We took a first cut, I'd love to hear what we missed or we went possibly too far and uh the question is: should we do an update and uh if we want to do an update, uh watch the people there? Thank you opening up for discussion.

J

Yeah, so um usually, what was something that's 17 years old? Is you try to advance it uh to the next stage of the standards process, which would involve things like implementer surveys? uh You know addressing known interop issues, and I'm not seeing any of that here.

J

So uh I do have a concern about it, which is that I don't think it's it's actually bringing the draft forward in in the way that the standards process describes.

J

E

Okay, um so are you concerned that we did not document the implementation.

J

Experience or that.

E

There isn't implementation experience well.

J

Usually well, I'm not sure that uh usually what you do right for the standard process is you try to document that everything has two implementations or more and potentially find areas that weren't implemented um or interop issues that were encountered? You know that's what that that's what this that's, what the advancement process specifies? It's not just uh you know, especially if something's 17 years old, we don't really rev rcs. For the reasons you describe right just to change, update references. uh There is no yearly maintenance process in the ipf.

J

um It's usually for the process of it. Well again, you're changing the standards process. You know you're not describing the stance process. We have you're describing it stands for us as you want to have happen, but I'm just saying.

G

J

There you know there are things that you do to advance that aren't on this, and it is a lot of work. People often don't like to do it, but you know that would be. It would be. An implementer-focused thing um that you know you'd have to you'd have to get into, and maybe some testing you know as an example, I I often wonder how things work in practice when you use the uh non-standard eap type space you know, is that interoperable between implementations, those are things I don't know that we fully tested.

J

So there actually may be things in 3748 that actually it's possible. There are things that just don't work.

E

Right yeah, I mean in general I love to have that that sort of thing here. I do think, though, that there's two categories of things that we can update rfcs for and what one is this implementation experience and the other one is uh new information and uh fixes to documents um and- and both are valid reasons and- and we usually fold documents in in that that have both components, um but I'm not uh disagreeing with you. I I agree that that would be a wonderful thing to have.

E

This is a zero zero, so we don't have a lot of that. A lot of the material in it yet go ahead.

D

Sorry, I was a little distracted. Apologies for that or joe. Could you go back to the slide? uh I don't know one slide or uh yeah this one uh so about uh eight now, I'm uh so what would happen when we use encrypted identifiers? If we are now saying, should omit the peer name portion, so I know 3gpp uses encrypted identifiers and if we are going to say, should omit. Isn't that an issue, or am I missing something here.

E

uh John, do you.

G

Want to take that.

G

Yeah, I think you might have a point. um Maybe this should be updated to be a bit more descriptive, that you should hide the identity peer name instead of saying should remove it yeah. um I think both approaches are okay. The important thing is that you hide the identity for any attacker.

D

Agreed that I guess in in some methods uh or in in some some deployments, uh you might still have the username portion and and still have privacy, whether it's encrypted identifiers or random identifiers.

D

This was just a minor uh comment. I I was a little bit uh distracted with the chat. The other question uh I guess uh would be- uh and this is like I haven't- thought this through fully and up to you, yari and john- on how you see it, but at least in eep tls.

D

When we started updating for tls 1.3, we realized that two things would be very helpful. uh Make make save save some round. Trips was, if we can add a payload to eep success and make the success protected, because mostly methods export keys, and you will have keys to protect that message and if you could send the new session ticket, for example, in the eep success or sends and other time types of configuration data. So I remember there was a presentation from huawei to do that.

D

I know this would be a much bigger change than than what is intended, but something that at least you could consider as input from me uh to to look into whether it makes sense to do it in this version or or wait for another version. No, no strong opinions.

A

B

Just wanted to jump in with uh with a process kind of commentary on what we had just talked about about what we standardized so ignoring some of the details of what's on the screen right now, because I think those changes fall into a lot of different categories of what you're doing. But I would say the conversation of how we do. Protocol maintenance varies across kind of the ietf, and I think that there's two different things to consider here. There is the conversation around.

B

How do we document implementations and how do we elevate things from ps to higher levels of standard and that's one level of administrative bureaucracy and then the other element of kind of bureaucracy? Is you know what triggers of this is that in chartered to trigger kind of abyss? Does that change kind of the protocol? And, I would say, the idea of collecting a package of erratas, certainly that are areas where we don't have a lot of clarifications and we jam that into abyss without necessarily changing a protocol version of her.

B

It's something that's been done before and also if we want to elevate the the document itself to a higher standard, we would need a revised version anyway of of the core spec itself, because we wouldn't want to leave any of the kind of ambiguity hanging out there.

B

So I think we need to go point by point to kind of decide what category things fall into and how dramatic uh dramatic of a change that is- and we need to probably squint at that relative to the charter, about whether we're really changing the protocol itself or creating an extension.

B

So this is a zero zero, so we're quite early here thanks.

A

E

K

Hey there, joe uh and thanks um and thanks yari for the draft, I want to say that I totally appreciate um your car analogy uh in terms of maintenance, um which leads me to want to ask a bunch of questions which are probably inappropriate for the working group. But um what I did want to ask is: if we're going to go to these lengths, uh if we're going to open up abyss document, is it worth stepping back a little bit and asking the question you know at more general levels?

K

Are there things we really ought to be doing differently, and um I mean it's a very lengthy conversation right and maybe we should be testing you know, what are we protecting? What are we not protecting is the connection model still appropriate is the the is the model we're using still appropriate for for um tunneling. uh These are all um questions that I think it's at least worth considering. If we're talking about doing abyss for this um and which is to say, um I'm perfectly fine.

K

If we come down with the answers and say yeah, I think we're really comfortable with where we are just a couple of tweets here and there we have ourselves a full standard. I would be very happy with that, but I would like us to before we go to the effort of turning something into a full standard.

K

Is it what we want at the end of the day and and to give you just one example of uh uh uh the um the applicability and we should be thinking about that is the applicability good across um not just 3gpp and and 802 networks are there? um Is there other applicability that we should be considering in answering that question um and I'm not trying to reach it prejudge the the answer? I'm just saying. I think we should be asking some of these questions all right. Thanks.

E

Yeah, it's a good good question. Of course um we set out uh from the point of view of uh not changing the protocol, and but you could certainly consider um providing a sort of a eap next generation type of thing, um whether that's sensible or not.

E

This is obviously a a different and maybe a bigger discussion, but but you- and you might also have like both answers- are valid situations where you want to keep your documentation up to date and so on, and you might also work on some newer stuff, but but it but there's a you, know, weight in deployed systems and um and that that was basically our rationale for mostly worrying about the protocol assets and describing it correctly um than than updating the or changing the protocol.

E

um Yeah. One more thing on this, this discussion by started by bernard and uh what roman said. I I think the awareness of what's working and what's not working would be really good to have. There's also a category that I did not see anyone mention yet, which is you know, maybe there's some parts that we could just deprecate, because you know this is not up to today's standards anymore.

E

Particularly if it's not today, anymore performed because of some.

A

Reason yeah, I don't know moet, did you have any uh or roman or are you guys still in the queue.

D

Oh no, I just uh thought that we are now running like two minutes and I don't know if we'll have time to discuss the milestones, but uh no no more comments on on this draft.

A

Yeah, I think we'll we'll have to take the milestones offline and um I think we'll want to have more more thank you for bringing this yari.

A

I think we'll want to have more discussion of uh of this on the on the list and to kind of figure out what exactly the target will be here, and um I think also the milestone discussion will be timely because likely we'll have to figure out if this fits in the in the emu charter and- and you know what I think some of that will depend on where we think we want to go with this document um or this effort.

A

So anyway, I think we're just about out of time. So, thanks for uh uh joining the meeting today and uh see you next.

D

Time yeah, I guess you'll find some of us in the gather town so have a great rest of the itf.

A

A