Session Date/Time: 20 Jul 2026 07:00
[00:00:14] Jim Fenton: Okay. It's now 09:00, so we should probably get started. Good morning, everybody, and welcome to the first session of IETF one twenty six. My name is Jim Fenton. Next to me are Shuping Peng and Rifaat Shekh-Yusef. Did I do right? Okay. Great. So we're gonna start, of course, with the note well, and we're gonna pay a little more attention to that than we do in most sessions, I think, because this is the first session of the of the meeting. If you're not familiar with the IETF procedures that are kind of summarized here on the slide, we strongly encourage you to review the relevant RFCs here and so forth. But generally this has to do with a few different aspects of participating in IETF. One aspect being behaving in a professional manner and and not not harassing other people. Another aspect has to do with intellectual property rights and making sure that you you disclose anything that you are aware of that is covered by patents, for for example. And, generally, the the the the processes that that IETF uses for rough consensus and and all of those sorts of things. You if you come up to the to the microphone here, you you will be on the video regardless of the color of your lanyard. So please be aware of that. And we are making public audio and video recordings of the session. If you have any questions, please catch us after the meeting or talk to talk to one of the area directors here. But this is something that's very important to IETF that everyone be on the same page with this, and we hope that you all will be. So one of the things that's new here is that we've combined dispatch with sec dispatch and also with the non transport aspects of the web and Internet transport area. So this is kind of a kind of a new format. We've been doing this sort of informally as a as a joint session between dispatch and sec dispatch in the past, but now we're a single working group and and one big happy family. So just wanted everybody to be aware of the the very recent change that has happened on that. I'd also like to thank Laura Scolaro, and I think Rich Sauls is is also helping with taking notes for the session, and we really appreciate that. Attending the session here, please make sure that you're signed in to data tracker. There was a a QR code, I think, at the very beginning, but there's one outside the door, or you can get there from the from the data tracker tool itself. If you're in the room here, you normally use the the MeetEcho Lite client. Although but if you're if you're using the full client, please make sure that you have your audio and video turned off so that we don't end up with with feedback. If you're remote, again, make sure your audio and video are off unless you are presenting, and we strongly recommend the use of a headset so that everyone in the room can hear you clearly. Please, if you get up to the microphone, state your name each time you you begin speaking so that the notetakers and everybody else has has that context. And I guess I got this out of order here, the new dispatch. This explains that we've merged with with SecDispatch. And we have significantly updated the wiki that describes dispatch and and also has some new information about, like, what if you have something to be dispatched that is in a in an area other than the ones that we cover. It gives suggestions about other places to go for that. So please have a look at your at your leisure. The focus of this session is to answer what we refer to as the dispatch question.
[00:05:14] Roger Anderson: And there are several different options that we can recommend for for new work. It could go to an existing working group,
[00:05:25] Jim Fenton: a new working group. I won't read all of these, but these are the various various of the options, and it's a it's a recommendation that this that this working group makes. And so that's that's really the focus here, and we really want people to focus on answering that question rather than getting into the details of the technology. We're all engineers here, and we love to get into the details of the technology, We need to resist that a little bit here. We need to cover just enough of it to understand what it is that we're talking about and not get into the guts of it. Next slide is the agenda. We have, I think, seven presentations lined up, fifteen minutes each. Here's what they are, and we'll we'll try and summarize the actions that were recommended at the very end. A couple of other announcements. We have there's a a a great agenda of side meetings at this IETF. I know that Descartes has one this afternoon. I think he'll he'll talk about that as part of his. There's also a side meeting coming up about trying to revive XMPP work. So if you're interested in that, please refer to, I think it's sidemeetings.ietf.org in order to learn about those. But but you should look at this the schedule anyway because there's a lot of great stuff there. Alright, any questions? So, let's get started with our first presentation, which is Roger Anderson talking about caller ID vouching and vetting. And, Roger, I assume you'd like us to run your slides? Please. Okay. Great. Okay. I can
[00:07:28] Roger Anderson: do this up here.
[00:07:29] Jim Fenton: Yeah. So, yeah, just
[00:07:32] Roger Anderson: you so much. Hi, everyone. Thank you for this opportunity.
[00:07:36] Jim Fenton: Bring the microphone up. Really have to eat the microphone here.
[00:07:53] Roger Anderson: Tap. Tap. Hey.
[00:08:01] Jim Fenton: There we go.
[00:08:05] Roger Anderson: Nothing, like, making me even more nervous with
[00:08:10] Aaron Parekhi: okay.
[00:08:10] Roger Anderson: Thank you, everyone. How's that? Is that better? Thank you, IETF and dispatch group. I'm here to talk about the caller ID vouching and vetting protocol. This protocol is designed to address caller ID spoofing in the telecom network internationally or domestically within The US. The big
[00:08:36] Lun Li: Okay.
[00:08:37] Roger Anderson: There we go. Okay. Got it. Okay. In many real world call paths, legitimate caller ID spoof sorry. Legitimate caller ID presentation and malicious spoofing look identical to the called party. So recipients of calls need a way to determine whether this this caller ID that is presented is authorized or if this is impersonated. STIR/SHAKEN has made tremendous strides in this area. There's important important caller identity support. Deployment of STIR/SHAKEN is incomplete globally, and sometimes call paths fall outside it. Sometimes call paths intentionally fall outside STIR/SHAKEN. So adoption has not been rapid with STIR/SHAKEN. I know there there are also strides to improve STIR/SHAKEN. So this protocol is not meant to compete with STIR/SHAKEN. It's meant to work alongside it. The protocol is simple, incrementally deployable, and it allows the called party to ask a simple question and get an answer. And that is, will the party responsible for this presented number vouch for this call right now? So the the recipient of the call is able to make a determination whether the party responsible for this number will vouch for this call right now. It's based upon two, basic principles of telecommunications. One, when we receive a phone call, the presented caller ID is easily spoofed and is not trustworthy. However, if we were to make a telephone call to that number, generally speaking, we will reach the party responsible for that number. So caller ID vouching and vetting simply uses the trust of the routing back to a number using reachability to verify whether the call ringing the device right now is can be vouched if the party responsible will vouch for it. It uses that call routing back. It uses short signaling only. There's no media setup for this. It works across SIP or legacy s s seven, and it requires no new SIP methods, headers, or response codes. No changes to SIP or ISDN. I know there's no appetite in telecommunications to introduce any new extensions or new protocols. So this this uses it requires no changes to these protocols. Okay. The the the there are two core concepts of vouching and vetting. Vouching, as we discussed, allows the receiving party to determine whether the the owner of the telephone number, even though we don't really like the concept of ownership of telephone numbers, but the party responsible for a number can answer a question one of three ways. Yes. I vouch for that call. No. I do not vouch for that call. Or it's undetermined. There's there may not be a determination for it. And and this is real time information in and it's it's authoritative enough that you, that the the terminating party can act upon this and actually not deliver the call if the number is not vouched. Again, it uses short reachability based verification, and it works independently or alongside STIR/SHAKEN. K? The second concept is a slightly more narrow use case, and that is vetting. It's today, it can be somewhat challenging to verify whether an enterprise has responsibility for all of the phone numbers that they that they claim. So some enterprises may have tens or hundreds of thousands of telephone numbers. And branding campaigns, vetting agents, trust programs, trade organizations, a lot of these organizations need to verify that these telephone numbers are actually owned by the enterprises who claim them. And vetting allows allows two parties with no central authority, two parties to confirm through through a shared key exchange, can cryptographically confirm that a third party actually controls the number. So it addresses vouching and vetting. But the core idea of the protocol, really, the one that that's most interesting to recipients of calls would be would be to allow this third party to determine whether or not the responsible party truly owns the number. Okay? So the desired outcome, of course, during this meeting is simply to determine whether or not the IETF it's appropriate for the IETF to to work on this. How should this protocol fit into the existing working groups, if possible, and what the next steps might be. And if there's any interest from existing working groups regarding trust and and caller ID verification sort of allow outside, alongside, or complementary to STIR/SHAKEN. So thank you very much. Any questions then?
[00:14:05] Jim Fenton: And Jonathan Rosenberg is first.
[00:14:25] Jonathan Rosenberg: Alright. Can you all hear me now?
[00:14:27] John Klensin: Yeah.
[00:14:27] Jonathan Rosenberg: Alright. Good morning.
[00:14:29] Roger Anderson: Good morning.
[00:14:29] Jonathan Rosenberg: Thank you for bringing this to the ITF. So Jonathan Rosenberg from Five nine. Obviously, I've I've worked a lot in this area, and this idea is is has been explored as you as you're well aware before. It it does have the challenge of being very difficult to introduce in a backward compatible way. And and in particular, I'll I'll ask him the form of a question first. So in in your proposed solution, let us say the called party supports this mechanism, but the calling party does not. Their domain, their environment. They place the call, and it comes to the called party. What what happens in your system in that use case?
[00:15:13] Roger Anderson: The vouching calls so we we've Just the vouching one too.
[00:15:18] Lun Li: I'll just Yeah.
[00:15:18] Roger Anderson: The vouching calls have a a special prefix to the caller ID. So a call would return back to the originator with a special caller ID.
[00:15:26] Mohammed Khalil: Yeah.
[00:15:27] Roger Anderson: If the originator does not support the protocol, then there might be a blip of a ring.
[00:15:33] Jonathan Rosenberg: Yeah.
[00:15:33] Roger Anderson: The as soon as there's a ringing or certainly an attempt to establish media, the call is canceled immediately. And it may not be a good fit for Northern or for North America, and it may not be a good fit for environments where STIR/SHAKEN when we think of mobiles as originators mostly, you know, we have STIR/SHAKEN in those environments. So we have some some validation. And so this would be in a situation where we call back. But, But, yes, there would be a blip of a call back to the originator.
[00:16:01] Jonathan Rosenberg: Yeah. So I I think that's a huge problem. And and that's why when way back we'd written a draft on this and it it used SIP extension semantics to ensure that you didn't get a a ring of any sort on the calling party. I think without an assurance of that, this is effectively not really deployable, as it would be very onerous. Like, think if you think about what happens for the very first person that turns it on, it's, like, destructive to everyone that calls them. They'll leave it with just lots of ghost rings, and that's all there ever is. So it's it's very difficult to incrementally introduce. So so that's that's my my feedback. Yeah. So in terms of answering the dispatch question, again, I I thank you for the work, but I I do not think this work should proceed.
[00:16:44] Jordi Rajyal: Thank you.
[00:16:47] Jim Fenton: Alright. Thank you. Ecker is next.
[00:16:51] Eric Rescorla: Yeah. Eric Escrowla. I I have the same concern. I raised this on on email as Jonathan does. So I think, you know, for this to proceed, you'd have to invent some way to suppress the ghost ringing to indicate that, like to indicate that, actually, you were supporting this mechanism and so it was safe to, like, issue a reverse call. And I I don't believe that's possible. But if you have some color on what you do, I'd love to hear it. But, but I think I think that would be a requirement to make this work. It's, like, only to only to issue the reverse call on people who is safe to issue for. I think unless you can solve that problem, I think this kind of is dead.
[00:17:23] Roger Anderson: Correct. Yeah. This you're I think we all agree. So I've run a a anti telemarketing fraud, and I know that my customers, subscribers, and consumers are looking for ways on a call by call basis to determine whether or not to allow the call and deliver the call. So you're right. And reachability has been explored before. You know, the the the way to address it would would simply would would require some changes in support in the network. And I know that the network, essentially does not you know, the operators within the PSTN have no appetite for changes. So so this could be implemented on certain verticals, you know, peer to peer. It could be, you know, enterprises could support it, enterprise to enterprise where it's somewhat controlled on the originating side and the terminating side. But ghost rings and phantom rings, if that has stopped this type of work in the past, if that's the only reason, then, you know, then we're we're determining that, that that callers are unwilling, to trade off a a fix for spoofing, essentially, in a call by call basis. There's no analytics required for this. But you're right. I I understand that reluctance completely.
[00:18:46] Eric Rescorla: Like I said, I I I I wanna just, like, resist resist that framing a tiny bit because the issue is incremental deployment, not what callers are wanting to do. Maybe callers would eventually be willing to do that. But the point is the first person to deploy the this this calling mechanism is basically breaking everybody else, and that just can't work. So, like, so, like, I think I think, like, that that that like, the issue is, like, not necessarily, but they're willing to do it eventually, though I think they probably aren't, but, like, but really, like, incremental deployment of of protocols. Anyway, see John John's on the line, so I'm gonna step back.
[00:19:13] Roger Anderson: Yeah. I believe there thank you for that. I believe there is already there are some antifraud tools out there. TransUnion through Trust ID has a, you know, has a product that does ring back an incoming call. The call is delivered to an enterprise. That enterprise, before answering or responding to that call, does ring the originator back. And so we there is some precedent for ringing back.
[00:19:43] John Peterson: Hi. John Peterson, TransUnion.
[00:19:45] Roger Anderson: Hey, John. How are you?
[00:19:46] John Peterson: Good enough. How's it going, man? Good. I'm gonna have to pick this up, I think, because it's a little little short from the floor.
[00:19:51] Vittorio Bertola: Yeah.
[00:19:51] John Peterson: So I actually, I came up here to ask kind of a meta, more process question. Because you as you point out, this isn't the first time that we've considered dial back authentication here in the ITF. And in fact, how many dispatches ago was it that we were discussing Hao Feng's draft? Like, which does dial back authentication?
[00:20:08] Ted Hardie: Yeah. This is
[00:20:08] Roger Anderson: brand new to me.
[00:20:09] John Peterson: Oh, no. Got it. I from a process perspective, kind of how, you know, do we need, like, a draft about how dialback authentication has a couple of known drawbacks, right? And one of them is this, it's not merely the ghost string. It's that people will exploit the ghost string for reflection attacks and amplification attacks, especially in a SIP environment. You can get forking. You can target someone by spoofing their number and make sure that they're, you know, DDoSed, basically, by this. And the divergence of the authority of of originators from forward routing, which occurs in a number of extremely, you know, common use cases that involve large enterprises. And so, you know, I guess, yeah, we've already considered an idea that's quite similar to this, and even earlier considered in the STIR context, like Jonathan's version of this, like, you know, I feel like we've already dispatched this, I guess is kind of what I'm saying. And so You feel like, what's that? We've already dispatched
[00:21:01] Roger Anderson: We've already dispatched it,
[00:21:01] Mauro Gennaro: This got
[00:21:02] Mohammed Khalil: the idea.
[00:21:02] Roger Anderson: Yeah, believe the previous proposal did establish media, correct? No. Okay.
[00:21:10] John Peterson: So, I mean, yeah. So I I I mean, I don't really know where to stick this because I don't know how to fix the two significant problems with that. Right? And if I think
[00:21:21] Roger Anderson: The phantom ring and the reflection attack.
[00:21:23] John Peterson: Well, the the, again, the phantom ring being exploited for reflection and implication attacks is I think the real difficulty, even more than the incremental deployment breakage that Echo was referring to. But, yeah, and the divergence of authority problem is the problem that, you know, forward routing does not work the way that originating router works in a lot of these cases. So if we had a way to address those, then I think we would have a fresh thing to dispatch. But, I mean, as it stands, I think we're we're effectively
[00:21:49] Roger Anderson: Yeah. The only way to address those would be to to make changes to the underlying protocol, which
[00:21:53] John Peterson: And you and I both know. Yeah.
[00:21:55] Roger Anderson: Exactly. Yeah. Yeah. Exactly.
[00:21:56] John Peterson: And we can talk about trusted. Trusted, by the way, not an anti spoofing technology. It's like an anti fraud enterprise technology. And so there's a different, I think, risk and friction service for the way that trusted works, and the way we would deploy things for, like, consumer use of, like, ordinary calls. But we can talk about that offline.
[00:22:12] Roger Anderson: Wonderful. I look forward
[00:22:13] Jim Fenton: to it. Maybe you can take it from there offline have some Okay. Further hallway discussions about
[00:22:19] Ted Hardie: Thank you, Roger.
[00:22:20] Eric Rescorla: I think
[00:22:20] Mauro Gennaro: we have
[00:22:20] Roger Anderson: our answer. Thank you, everyone.
[00:22:22] Jim Fenton: Okay. Appreciate that. K. The next presentation, which is not in front of me right now. Email verification protocol. Take heart. Thanks.
[00:22:37] Dick Hardt: Thanks, Roger, for debugging everything for me ahead of time. I used the suggested slide template, like, maybe I shouldn't have done. Let's see. I thought it was on the next slide. There I am. The problem is verifying an email address. You go to a web page. You type in your email address, autofill it. Then when you get a code, you have to go and change apps, wait for the email to come in there, check your spam, see if that's where it went, try to get that code, copy that code, go back, paste it into the form, and then you move on with what you've done. And and hopefully, you didn't see a scroll run by the window at the same time and do something else or see something else in your email. And so, you know, there's a huge issue on completion of going through and verifying emails. So that's a lot of friction. And so the EVP is a way for how do we verify that email while staying on the web page. The let's see. That all makes sense for the motivation. Everybody nobody nobody likes going and getting the one time password and pasting it in. So both on the RP side and as a user side, that's a problem. This work started in w three c. I was working with Sam Goto, a co author on this spec, and we wrote everything up in w three c. We got feedback from the tag that the protocol part should be an ITF. We were already a fair amount in running and deploying these things. So we've split the protocol part into the email verification protocol, which is the draft there. And then the browser part is in w three c as a email verification API. Still working on those aspects. It's now implemented in origin trials in Chrome and Edge. Google has enabled email verification on the gmail dot com domain. And so any site that opts into the origin trials can now have it work if they jump through all the hoops on trying to make it figure out the get their code to do the right things in the right places. We've already found quite a few interop issues in trying to get all the pieces to say the right thing in the right time.
[00:25:34] Roger Anderson: Very touchy.
[00:25:40] Dick Hardt: How it works is it builds on some of the concepts that were in FedCM of looking at it requires that there's cookies between the browser and a domain that is gonna issue the token. So in the the first part is the email domain has a DNS record that says has the host that is a for it. And so there's a record now underscore email dash verification dot Gmail dot com that points at accounts dot Google dot com to say that accounts dot Google dot com is a for issuing EVP tokens for gmail dot com. The browser on auto complete looks to see if that's there. If it's got cookies for the issuer domain, it sends those over assuming that the issuer said that it's logged in and it said that those emails are there. And then if the cookies match the email that the browser sent over, the issuer will sign a token that it sends to the browser, and then the browser will provide that token. Currently, the implementation is in the it puts it into a hidden field in a form, and then the browser can go and get that token and send it down to the relying party which will verify that token. To preserve the privacy of the user that the issuer doesn't know every place that the protocol is being used as, you know, a privacy enhancement over email, the current process of sending an OTP. We do the browser mediates the thing until the token from the issuer is bound to a key at the browser. And then the browser does a key binding token, and so it sends those two tokens down to the rerelying party so the reprelying party can walk that chain. So the issuer is binding it to a key at the browser as opposed to the actual rerelying party.
[00:28:02] Jim Fenton: DAWN't don't get too lost in the details here.
[00:28:06] Stephen Farrell: Well
[00:28:09] Dick Hardt: well, some of that was to understand dispatch on all the different pieces as to where it might go. Okay. Cool. Just Okay.
[00:28:16] Jim Fenton: Keep going.
[00:28:20] Dick Hardt: Like, did I miss it's hard to know. Did I go through? Is this even working or is it somebody else?
[00:28:27] Roger Anderson: Yeah. Yeah. Yeah. It worked. You're driving.
[00:28:29] Dick Hardt: Well, it's not going backwards.
[00:28:34] Shuping Peng: Okay.
[00:28:37] Dick Hardt: Yes. I'm at the end.
[00:28:39] Lun Li: Yes. Like
[00:28:42] Dick Hardt: click the button, nothing happens. Move. Yes. Just move it.
[00:28:48] Jordi Rajyal: No.
[00:28:51] Dick Hardt: This is our last. Yeah. Yeah. Yeah. Is.
[00:28:53] Jim Fenton: Yeah. This is the last slide.
[00:28:55] Dick Hardt: Yeah. Okay. Yes. That's our question.
[00:28:58] Martin Thomson: Yeah. Go. So
[00:29:03] Dick Hardt: it's an origin trials. So, I mean, the browsers are moving and they've they've viewed w three c is what they're doing. They're working on that. You know? Assuming the trials go well, might this gonna be deployed in six months in production in the browsers, and they're not gonna wanna make changes. So there's sort of a limited window for ITF to provide feedback and guidance on the protocol. So we need to move reasonably quickly. So I'm suggesting that maybe it's an AD sponsored thing. We don't have time to sort of run through a BAW or create a new work. But we can have a meeting again in San Francisco, but a BAW and a working group is gonna be probably too late to have any impact.
[00:29:50] Jim Fenton: Okay. We have quite a few people in the queues. So let's start with Mauro. Please try and keep it short so we can make it through the queue here.
[00:29:58] Mauro Gennaro: Hi. Yeah. Mauro Gennaro, Stover Labs. Yeah. Overall, I like the idea. But in order to answer the dispatch question, I would like to know how is this going to work with the rest of the Internet that is not using a browser to access their email. How do you plan to to make it work, for example, with the normal email clients? Are they using IMAP or JMAP where you don't have a browser involved here? So that is an important point, I believe.
[00:30:31] Dick Hardt: I mean, so the you're targeting where somebody is in a web page and doing OTP?
[00:30:38] Mauro Gennaro: Yeah. The problem is that Yeah. Sometimes the the identity provider is decoupled from the mail server. So they are so they the flow goes like this. You connect. Yeah. You have your email client. You log in. You go to identity provider. You you get an OAuth token, and then you access your email. So you are online, but you're using an email client like Thunderbird or anything else.
[00:31:05] Dick Hardt: Sorry. I I I didn't realize which slide you are. You're thinking of it from a issuer point of view.
[00:31:12] Mauro Gennaro: Yeah. Not only not only issuer for, like, any like, let's say, any normal email provider that is not Google and has, for example, let's say, their own email server. And they're gonna combine into products, an identity provider and an email server. And the user is logged in actually, but they're not using a browser. So what based on what I read on the on your draft, it's all it is tightly integrated with the browser. So the authentication may be done by the browser. They get the token, but then the browser is gone. Like, it's it it disappears, and then the the mail client takes over, and it's using either IMAP or JMAP. So how will that work?
[00:31:53] Jim Fenton: Mauro, do you do you does that lead to a a decision recommendation on on the dispatch question?
[00:32:01] Mauro Gennaro: I believe it's important because if it's something that only will work with Google Chrome, for example, or a browser, so this should be something that is should be used internally on the by Gmail, for example.
[00:32:14] Jim Fenton: Okay. So so I IETF should do what?
[00:32:18] Mauro Gennaro: IETF if if there is a way to use it in the self hosted community or anywhere else that is not Gmail where everything is controlled by a single provider, like, that you're combining different products from different companies, then, yes, I should it should go ahead with with the ETF. Either working group, a response, or anything. What what I mean is that it it belongs in the ETF if it's something that could be used by the entire Internet.
[00:32:43] Jim Fenton: Oh, okay. Thank you. Let's we we've got a long queue, so let let let's move on. Vittorio. Yeah.
[00:32:50] Dick Hardt: You. Briefly respond to that. So you can separate those two those two functions are collapsed in Google, I understand, but you could separate these two functions that the email domain could delegate to some other service that acts as an issuer. So at hello, we'll act as an issuer. If you go and you point your domain to hello.coop, we'll act as the issuer for that token.
[00:33:14] Aaron Parekhi: Okay.
[00:33:15] Dick Hardt: Go ahead.
[00:33:17] Vittorio Bertola: Hi. Victoria Bertola, Open Exchange. So speaking as a large email platform vendor. First of all, I think you missed the word address because for email people, email verification may whatever. So maybe it's email address verification. Apart from this small point, I I think this is really interesting. I see a lot of email vendors or maybe everyone implementing it. Again, I agree that it needs to work for everyone, not just for integrated things, but for large telcos, small telcos, even individual in the service side. Yeah. So I think it needs a little more discussion. I don't think you should rush it. I don't think it's wise at this point in time to standardize very quickly something that only comes from two American companies speaking as someone who is often in Brussels and sees the scrutiny that the European Commission gives to this kind of, let's say, things that can affect the competitivity of a email the competitiveness of email services. So my recommendation would be to have a maybe above. I see this going to a new working group, but not to rush it, but have a full discussion with the with the email community that has not been involved in this in any way and somehow. Thank you.
[00:34:21] Dick Hardt: I live in Lisbon now, by the way. So
[00:34:24] Jim Fenton: Okay. John.
[00:34:25] Lun Li: Yeah.
[00:34:27] John Levine: John, let me I'm gonna say basically the same thing the last two guys said. You know, Vittorio is too polite to say. He he works for the largest open source vendor of an IMAP server, you know, and which I use. You know? And I would love to use this, you know, but if I can't use it with my with my with my IMAP server, you you've you've broken the email world in half between the between the Webmail giants and everybody else. You know? So I I think it's I don't see any reason that we can't figure out how to make this work with people who are doing conventional conventional nonbrowser email, but I think it's really the I the ITF is gonna work on it. It's it's gotta work for all the mail. So maybe a boff, you know, maybe a maybe spin it spinning spin up a tiny working group because I agree it's too big for Mailmaintenance, and it's got too much web stuff for for just mail people.
[00:35:12] Jim Fenton: K. Thank you. Ecker.
[00:35:15] Eric Rescorla: Yeah. Hi. So I I thought I was heard you say you don't wanna buff in a working group because you don't wanna change anything, really. So, and I think we really the first the the the threshold question here is, are you in fact going to like, do you wanna standardize this, or do you wanna rubber stamp it?
[00:35:34] Dick Hardt: I didn't say I didn't wanna change anything. I said now is the time to change anything.
[00:35:39] Eric Rescorla: Okay. But I heard you say, like, hey. Come on.
[00:35:41] Dick Hardt: It's right. If don't have a working group for a year, it's gonna be baked in. It's gonna be hard to change things. So now is when I would like to try to engage everybody because now we can change stuff easily.
[00:35:53] Eric Rescorla: Oh, okay. I guess I'm trying to figure out the timeline you're really talking about here because you know this is a two year effort. Right?
[00:36:02] Jim Fenton: Okay. Yeah. Great. Thank you. Dennis Jackson.
[00:36:06] Aaron Parekhi: Yeah. I mean, plus one's what like I said, this seems like it needs a a bunch of improvement from the cryptography design, and I don't see that happening in an AD sponsored draft. It seems like it needs a bunch of work. Yeah.
[00:36:22] Jim Fenton: K. Richard Barnes?
[00:36:25] Richard Barnes: I I agree that a d sponsor is completely inappropriate for something of this this scale and magnitude. And so as Edgar said, if you if you wanna get this done, you're gonna have to do the work, and that work is gonna take some time.
[00:36:41] Jim Fenton: Okay. So not AD sponsored. It sound I guess the sense I was getting was off maybe? And Or or Right. But but would be a boff leading to that, I guess. Yeah. Okay. And again, pointing out that there is a side meeting on this this this afternoon. Yeah. Okay. Thanks, Dick. Great. So the next presentation is remote from John Clemson. And, of course, we're running the slides for John. Right?
[00:37:26] John Klensin: Hello, everybody. This presentation is a little bit unusual for dispatch because norm, including the presentation we just listened to, is for relatively new protocols. And this is about taking a particular set of set of protocols, which are, to various degrees, widely deployed in trying to, rationalize them a little bit, explain them, talk about how they fit together. Next slide, please.
[00:38:04] Shuping Peng: You have the control. John, you have the control.
[00:38:11] John Klensin: Oh, please please do the slides there if you can. Okay.
[00:38:25] Jim Fenton: K. Background slide is up.
[00:38:27] John Klensin: Okay. Thank you. So the ITF last call and I asked you to review those applicability statements created some controversy, and those who've been following that an email core bit more about it than you probably like to. But there's a very strong push for TOS requirements, scourge email without it, something about which everybody seems to agree in principle until we get to other details. There's some possible misunderstandings in those conversations about how email works, including multi steps forward and questions about where the vulnerabilities lie. And there's a tension between IAT about IATF objectives and current established practice and whether it's wise or sensible to impose requirements, which we do in advance that nobody they almost don't wanna pay any attention to. DAWN't wanna spend any time on that today. It's a detail as far as this presentation is concerned.
[00:39:29] Richard Barnes: Well, I I I just as a as a point of clarification here, this is a really serious misrepresentation of the email core debate. The debate is not about requiring TLS. It's about not requiring insecure modes of operation.
[00:39:44] John Klensin: Thank you. And, as I said, let's not go here today, talk about an email course or else. But the difficulties turned up some discussion turned up some difficulties with the TLS and related specs and potentially interoperability problems. Next slide.
[00:40:06] Jim Fenton: K. Authentication problem slide is up.
[00:40:12] John Klensin: The authentication problems are almost separate from confidentiality problems, unless the tools overlap. At least the first of these tools is required to verify the path as intended rather than getting into discussions about in the middle attacks. But there are more one of these authentication problems as indicated on the slides, the SMTP sender verifying the receiver, SMTP receiver verifying the sender, message originator questions, etcetera, authenticity, and message integrity issues. To save time, I'm not gonna address these today, but these methods involve many of the same issues and challenges and interact with the others. Next slide, please.
[00:40:58] Lun Li: Next slide.
[00:41:00] John Klensin: Okay. We've got a large collection of TLS and other link level confidentiality approaches. Actual distinctions of what this looks like to an email implementer or user from the outside. We've got some SMTP extension specifications, including start TLS, REQUIRETLS, and SMTD off. We've got requirements for SMTP centers, specialty MS checks, including MTA-STS, and other posters which are floating around. And we've got some confidential transport possibilities including IPsec and specialized tunnels including SSH underneath SMTP. There we've also got a collection going back decades of end to end origin recipient methods which are developed, standardized, and little used. S/MIME and and OpenPGP being the two main examples. Alright. Next slide. Okay. What's the problem? What's the problem? At a fundamental level, these methods are not interoperable. If a sending system has support for where two of them and receiving system has support for a different set, interoperability using these things may be impossible, And we end up faced with the question of whether to call fall back to clear text or just not send the message or not deliver the message. Many of these things expose more information as generally understood, in particular pieces of the envelope. And the relay hosts, not just the link level environment, are poses fairly superior fairly serious risks. How serious those are depending on the environment in which one is located, but the risks are there. At the moment, and this is the gist of this suggestion, there's no clear easy to find and understand guidance about what should do and what trade offs exist. These are generally not policy questions, but they're technical choices about best approaches and trade offs. Next slide. Dispatch recommendation. If we want serious interoperability use of message confidentiality techniques, a carefully thought out, well written set recommendations are needed. It needs to cover circumstances under which different methods are optimal, trade offs between limitations of various methods, clarity about what is and is not protected, or we can continue to do what we've been doing, which is a model long appearing to overpromise what various techniques provide, making requirements that if observed would kinda large push the world off of email, get extensive discussion about email behavior in Africa, for example, and it's deployed and associated deployed with TLS. And this will probably require a working group or assignment to an existing one. I see no hope in trying to do a AD sponsor. Next slide. The other thing which makes this unusual as a question or problem is that most presentations you're seeing are from people who are enthusiastic about their new protocols and interested and willing to do the work. I can identify the problem and describe it in in however much detail one wants, much more than in this slide, but I'm not qualified to lead the work. So the question is not just, is this work important? Should the idea to do it? But can participate people, participants be found who can and will do it, or do we live with the problem and the impediments it poses to email confidentiality, which is effective looking which is actually globally effective. Next slide. Thanks very much.
[00:44:59] Jim Fenton: Okay. We've had a fairly fairly lively discussion in the, in the chat session. Ted is first in the queue.
[00:45:08] John Klensin: I should note that I can't look at the chat session and talk at the same time. So
[00:45:13] Ted Hardie: Ted Hardy, no relevant affiliation. I just wanted to say that the typical way we we discover whether there are people interested in doing the work is to hold the BOF and then ask at the BOF whether or not there are folks interested in solving this problem, and there are enough of them to write and review the drafts. So I would say that if there's a dispatch outcome from this, it it would be to hold the BOF and see.
[00:45:35] John Klensin: That would certainly work for me.
[00:45:41] Jim Fenton: Richard Barnes. Oops. Maybe not. Eric.
[00:45:47] Richard Barnes: I I was gonna yell. No.
[00:45:48] Eric Rescorla: Go ahead. Ahead, Richard. It's fine.
[00:45:50] Richard Barnes: No. Go ahead, Eric. Please. Please.
[00:45:51] Eric Rescorla: Oh, okay. Yeah. I mean, I think maybe a bot. I'd like to see this as evidence that anybody wants to actually do this before we spin up a bot. We have quite a few bots at this at this ITF, and so I think there has to be a fairly high threshold for actually, like, reserving a slot. I'm not quite sure what the ask is here. It seems to be the ask is, does anybody wanna work on this rather than you're proposing it proposing working on it? So I I think if you if you don't have enough enthusiasm to work on it, I I I I'm hard pressed to see that we really should spin up.
[00:46:19] John Klensin: I'm certainly going to work on it, but a series of recent discussions have demonstrated that I don't know nearly enough about the deep details in this area nor about where things are deployed where they're not deployed to take a leadership role.
[00:46:37] Roger Anderson: Okay.
[00:46:41] Richard Barnes: Alright. Richard, are Thank you. I I was gonna propose, what is hopefully a friendly amendment, which is that, I I think, John, that you you correctly pointed out that there is a morass of, complicated and sometimes conflicting and overlapping protocols around email security. So I think there would probably be more utility to the community in trying to clean up that morass, than simply producing a map of of the complication. So if if this does go to a bot, which I think is the only possible path forward here, I would suggest, including some of that as scope as well, which may in fact attract more interests than simply documenting the sad state of affairs that exists today.
[00:47:28] John Klensin: No. No. Absolute agreement. And that's why I think we're looking ultimately for for BCP or applicability statement or a combination of the two that really talks about what the balances are and gives some useful advice.
[00:47:47] Jim Fenton: Alright. John?
[00:47:50] John Levine: Yeah. I think this is a useful thing to do, and I'm trying to figure out a polite way to save this.
[00:47:55] Jonathan Rosenberg: But
[00:47:55] John Levine: email is our oldest actively used protocol. You know? It's it's older than TCP, And it has decades of cruft. And if we were designing it today, there's a lot of choices we would make different from the way from from the way we from the way it's it's turned out. You know? But it's implemented in billions billions of devices all all over the world. And so when I talk to people who actually run mail systems and who actually write mail software, many of whom are not if not in this room or certainly active in the ITF, I mean, there's an overwhelming consensus that backwards compatibility so the mail can get through is the first priority, and we and we improves we improve security only in so far as it doesn't break as it doesn't break people's mail. And we've heard people with let me just say we've heard from people who have different priorities, which I don't which I what while reasonable, I think, don't match with what people and people people writing actually email systems do. So I think if we I I think we should do this, but I think we should be very, very clear that if we're gonna produce something useful, we have to have active involvement of people who actually run mail systems and actually write mail software and make sure that that we have consensus from them and along with everybody else that what we're describing is something that that actually realistically realistically describes both how mail works now and and what changes we might make. I mean, I don't think any of us think that mail is actually impossible to change at all. But I think we've we've provoked we've heard proposal for a lot of what are basically breaking changes that in in reality are just off the table. Nobody's gonna do it. So I think I mean, I hate to say this, but, you know, I I would like to finish email core and then recharter it to do this. But failing that, some sort of working group would do it.
[00:49:42] Jim Fenton: Question for you, John Levine. Do you I mean, you mentioned a number of those people are not active in ITF.
[00:49:50] John Levine: I see no who are active in ITF. Yeah. We have people we have people from all of the major mail vendors, and most of the major mail software providers are active here. So, you know, we need to make sure they're in the room.
[00:50:02] Jim Fenton: Ah, okay. I I I misunderstood. The the acoustics up here are terrible. So
[00:50:07] John Levine: Yeah. And and I mumble. So, yeah, it's okay.
[00:50:10] John Klensin: And and one of the key issues here one of the key issues here, I think, is that we need to look carefully at the balance between deliverability of email and and and confidentiality. And that's to a certain extent of of special case, which I just mentioned.
[00:50:33] Jim Fenton: Alright. Vittorio.
[00:50:35] Vittorio Bertola: Yes. Very quickly. Vittorio Bertol again. So speaking as a Gmail vendor. So we think everyone should agree to their email with TLS, and we think we are not going to drop support for plain text or plain text anytime soon. So this seems to be coming from a disagreement in policy terms between groups of people. I don't know if this can be resolved. If some people want to continue working, let's make above, but I don't know if this discussion can be productive because there seems to be some fundamental viewpoint difference.
[00:51:07] John Klensin: Mario, I don't think there's any fundamental disagreement. No nobody is gonna stand up and say, confidential email is evil. The question is how one balances and explains the collection protocols we have and what to use when and does so in a way which addresses the problem which I will find ways, which is that that this is has gotta work within an existing email environment, which if we were all redesigning, any of us will be deciding. Today would look different.
[00:51:45] Jim Fenton: Okay. Thanks, everybody. The sense I'm getting is that, we should probably do a bot for this one. So the next presentation is, Andrew Campling, parental control protocol.
[00:52:15] Andrew Campling: Right. Good morning, everyone. As was said, my name is Andrew Campling. I'm gonna be presenting a proposal to develop a protocol for parental controls.
[00:52:31] Mohammed Khalil: Oh, no. Press the wrong button. Oh,
[00:52:35] Andrew Campling: well, okay. So the reason that we believe that there's a problem is parental controls are used by many and are perceived as an important tool to manage access to digital devices, different applications, content, make purchases, etcetera. Unlike some areas, are plenty of options for parental controls. There are device level options, operating system level options, applications have them, network operators, ISPs have them on routers. Many platforms offer them. From the perspective of parents, they're a horrible mess. There are so many of them. This is an absolute example of where the level of choice is in itself a problem and a real barrier for success because the different systems work very differently. They use different vocabularies or for fun. In some cases, they use the same vocabulary to mean different things. I've spoken to CTOs of major tech companies who've said they cannot navigate parental controls successfully, particularly if we're talking about multiple devices across different ecosystems. So and and that's for highly motivated individuals with a good degree of technical knowledge. So for your average parent or carer or guardian, it's an impenetrable morass, which means they can't set effectively controls that in their view would keep their child or the young person they're responsible for safe from at least some online harms. Maybe it's not working, but We've put together a proposal for a protocol that could help to solve this problem by interconnecting the different parental control systems. So we're not proposing a new parental control. The world's got many. It doesn't need another one. What we're trying to do is to make them interoperable. And we've put together a proposal for a protocol that would help to allow them to interconnect, to share data so that someone could use their preferred system, and the settings would propagate across different devices, different applications, etcetera, without them having to delve under the hood in all those different systems. What I'm not gonna do is to dwell on the specifics of our proposal because this is a dispatch session. So the the intent is treat the draft as written as, if you like, a proof of concept that we believe a solution is possible, but would be perhaps a potential useful starting point should a working group be formed to actually take this problem forward. So the intention here is really to get agreement, hopefully, that this is a problem that needs to be solved and should be solved by this community. There is complementary activity already underway in another STO within the ITU. Within study group 17, it's focused very much on processes and procedures. So the sort of the the the stuff that typically the ITF doesn't want to touch, what it's not doing is looking at the relevant protocol. So the intention is to create a set of complementary activities so that the protocol work belongs happens here where it belongs. Some of the policy discussions take place in the ITU, but with effective interworking between the two. But I've put a link on the slide to what's effectively an abstract of a document within ITU study group 17, which is taking on the work as a new work item at the the end of last year. In the event that the community took this work on, then we'd create within the ITU a shared work area so that all of the ITU documents that would normally be behind a work a a firewall sorry, a paywall would be freely available to the ITF community. So there'll be transparency between the two STOs so they could work together effectively. We've already got confirmed interest in working on this problem from Qoria, which is now part of Aura Group. Since I suspect many of you aren't familiar with Qoria, it offers solutions for education in terms of pupil safety as well as parental control application custodial. They have about 30,000,000 customers spread across a number of different geographies. And Vodafone Group, major ISP that has about 350,000,000 customers, mainly, I think, in Europe and Africa, but also elsewhere around the grow globe. We have been in discussions with a number of of other major vendors, but they're not yet at the point where they're happy to be mentioned publicly. But we are getting reasonably significant support from people that recognize that this is a problem to be solved. They want to solve the problem and then to deploy the solution. Next slide, please. Having looked at the various working groups, we don't believe there's an existing working group in the ITF where this would comfortably fit. And we don't think there's necessarily going to be consensus that this is a problem to be solved. So we would recommend dispatch to a BOF to actually establish if there's sufficient people to work on the problem, and then ultimately to decide whether to form a new working group in the fullness of time.
[00:59:23] Jim Fenton: That's it. Okay. Thank you. Ted is first in the queue.
[00:59:27] Ted Hardie: Ted Hernie. For the dispatch question, I believe that this belong this work belongs outside the ITF. One reason I gave an email after reading the draft, I believe the function of the PEP is also within the scope of the the work, the twenty eight zero four defined by policy to be outside the scope of the ITF. More importantly, I think what you have here isn't a single protocol. It's a very complicated architecture, which involves jurisdictional and local authorities combining and and a series of different pieces going together. And historically, the the ITF does not build architectures of this type at all. We build the the building block protocols. If you want to use MLS as a building protocol in some other architectural group, be it study group seventeen, 3GPP, wherever you're gonna take the work, that's fine. And if you have requirements for the the protocol of MLS needs to to be able to be named this or that to do it, we can consider those on a technical basis. But this work is totally out of scope for the ITF.
[01:00:28] Lun Li: Thank you.
[01:00:29] Andrew Campling: Okay. Thank you for your comment.
[01:00:31] Jim Fenton: Steven.
[01:00:32] Stephen Farrell: Hi, Steven Pearl. I totally agree with Ted. In in addition, I think the vision here that seems to be behind us is that there's an MLS group that kinda everybody who's has a child is supposed to join, and every piece of software is supposed to only do what this MLS group says to do, that's kinda nonsense. This should go to to ITU something.
[01:00:54] Jim Fenton: Just a reminder for everybody at the microphone, please announce your names. Phil
[01:01:00] Phil Hallam-Baker: Hambaker. I have a bit of experience in this area. Over thirty years ago, was at W3C when we were developing PICCs. And the thing that I noticed with PICCs was there are a large number of people who were part of the group that should on no account be allowed anywhere near censorship system. And so I rewrote the PIX back when the guy in charge of it was out of the office, which upset him. And that's where we got the URI to describe your censorship scheme came from.
[01:01:41] Lun Li: So so, Phil, what's what's the dis
[01:01:44] Phil Hallam-Baker: Well, the point was that the minute that that went into the spec, all the people who had been part of pushing BICS forwards disappeared because what they wanted all along was not what they said they wanted. It was control. And we don't do control, and I don't think that we should do this.
[01:02:05] Andrew Campling: Thanks for your comment. I would observe that there's a plethora of parental control applications of different types so this thing exists already. This is a way of making it work properly for parents to try and address a significant and growing problem of online harm. And the direction of travel is that certainly a lot of jurisdictions are planning to to impose things, so this is a way of doing it much better than that to avoid a sort of top down imposition.
[01:02:38] Martin Thomson: Martin Thompson. I think Ted probably changed my mind. I sort of got up to say that the draft is somewhat unclear about its purpose. I think, ultimately, you need to be much clearer upfront about what it is that you seek to achieve and how. Protocols at this point of the process really only exist to sort of sketch out the direction in which you're heading, not to of pre decide anything. So I think the question of whether MLS is involved is somewhat irrelevant. But Ted's point, I think, is an important one. The interoperability requirement here is between different pieces of software that may or may not be networked. In many cases, the control that's being exercised by parent happens on the same device as the receiving software that's going to act in in whatever way. And so this this may be something the ITF is not well suited to deal with, particularly because, as Ted pointed out, a lot of the problems are jurisdictional or related to authorisation of various forms. So I was going to say a full BOF would be necessary after you do some more development on the requirements and what have you. But I think I'm also inclined to agree with Ted now at this point.
[01:04:09] Paul Wouters: Paul Valkas. I also think that the idea falls in two different things. One is the definitions of what you want to specify, which I know I would love a standard so I can I can configure not my child, in my case, my parent to to have certain things, which for parents are always unspecified, by the way? Right? Like, if you do any kind of parental control for your parent, they lose the banking information and they can't do any transaction online and so they've all thought. So it would be good if we get better specifications for for that part. But I think the issue here is really mostly is that you need to sit down for your parent or your child and make all the choices of what you want them to do or not to, and that should never be a policy that comes from from some conglomerate on the Internet somewhere. It's really you're raising your you're protecting your child or parent, and you need to make all these decisions. If we have a way to somehow convey that to the different devices involved, that would be great. Having that over a shared resource like an Internet connection from your ISP that has to serve multiple users in the same in the same network with different restrictions, I think you get really quickly into, like, you know, censorship pushed from upstream network down to your to the user, and that's really bad. And the ITF should not do that.
[01:05:24] Jim Fenton: Alright. Arnaud?
[01:05:28] Arnaud Taddei: Arnaud today, now alone. So it's a very strange situation because we in a g 17, we are not allowed to do protocols. That's the no duplication agreement between standard bodies. So what we recognized is that, one, we have a mandate by ITU United Nations as resolution 179 to work on channel and protection. There is a council working group on channel and protection, and LG seventeen is tasked to find gaps to help channel and protection. So the jurisdiction was, frankly speaking, probably something we should rework. We did that in a rush. We had our intention was simply to help parents, guardians, families, and and and to to have an easier way in practical terms to protect their children because in practice, they cannot do it. Just cannot do it. So, yes, we can improve the wording. Yes. We can improve the the specification. The jurisdictions are there, but we don't need necessary to care about them. There is nothing about censorship here. It's not about the content, about what we are going to do. It's about the mechanics of how we get whatever needs to happen to happen correctly across multiple devices, platforms, and so on. Therefore, I'll be very surprised if the answer would say it has to come back to ITUT because then member states will say, no. You cannot. This has to go in another place. So very strange situation that the ATF would not take its responsibility.
[01:07:09] John Peterson: The dispatch Yeah.
[01:07:10] Jim Fenton: We're we're running out of time. What what's
[01:07:12] Arnaud Taddei: what's your conclusion? Dispatch is I completely support the fact that we need to order full buff to have a proper discussion about that and make sure that we can go into details and understand better what is the ask for ITF.
[01:07:27] Jim Fenton: Alright. Eker?
[01:07:28] Eric Rescorla: Yes. I I have two, hopefully, very quick questions. One, if I'm reading this document correctly, the policies and the guardianship are somehow endorsed by some external entity. Is that correct? The PIP?
[01:07:45] Lun Li: What the most
[01:07:46] Eric Rescorla: Are are the policies and the and the guardian, identification somehow endorsed by some external entity, the PIP? Is that how it's supposed to work? The jurisdictions sign off on the policies?
[01:08:00] Andrew Campling: I think I heard the question. In 02/2008, no. So if that's unclear, we obviously need to work on the wording. More importantly, as I said at the start, the the ID is simply a suggestion of a way the problem could be solved. The the dispatch discussion is around whether the ITF should take on the problem and work out how to solve it. You know, this is a straw man solution. We're asking to dispatch the problem, not this specific solution.
[01:08:34] Eric Rescorla: Okay. My second question is, do any of the major device manufacturers have any interest in doing this at all?
[01:08:40] Andrew Campling: As I said, we're in discussions with a number of bodies who are interested in doing this. At least one of them is a major device manufacturer, but I can't say yet who that is because that's obviously up to them if and when they want to be public. But in case you missed it, Eka, in any case, Vodafone Group has got about 350,000,000 customers. Qoria's got about 30,000,000 customers. So given the usual hurdle for dispatch, is is there at least some interest from third parties? Yeah. That's the best part of 400,000,000 users worth of interest, which I think is a decent start.
[01:09:21] Eric Rescorla: Yeah. I I guess I guess my problem with that is that those are basically network filtering systems. And I think the IB has been pretty clear on what it thinks about network filtering systems. And so I I don't really that's not really doing much for me in this particular moment, but I'm gonna step off now because I think we have other people.
[01:09:36] Jim Fenton: Okay. Vittorio, very quickly because we're overtime.
[01:09:40] Vittorio Bertola: Yeah. I'd like to be very quick with Vittorio Bertola. First, I want to confirm that there is demand for this. I mean, there's a now as a DNS resolver platform vendor, we we have to provide DNS based parental controls if we even consider it as a vendor, and there is demand for interoperability across vendors. So I see this as useful work. I prefer this to be done at the ITF for I mean, as a citizen for have a to have an open discussion rather than have it discussed in less open places. So I I'm in favor of above.
[01:10:08] Jim Fenton: Okay. And then, Peter Koch, do you have something real quick?
[01:10:12] Peter Koch: Yeah. Thank you, Jim. Peter Kortniuk. I I just have a question. I might have missed that, but we do have a very formal relationship with the ITU. And I'm wondering at what stage we are with you asking the question and then making that a dispatch question. Do we have a liaison statement from SG seventeen or don't we? Or is this to prepare such a liaison statement? I know the chair is sitting.
[01:10:34] Andrew Campling: Yeah. Defer to the chair of study group seventeen for a comment.
[01:10:38] Peter Koch: Of course. The answer to my or question is yes.
[01:10:44] Arnaud Taddei: If the request is for AG seventeen to send you a liaison statement, we will send it.
[01:10:50] Peter Koch: Okay. Then I would strongly recommend that before we can answer the dispatch question, we need to involve the IAB and the whole liaison management to scope and make sure that the formalities are
[01:11:06] Andrew Campling: Okay. I further
[01:11:07] Peter Koch: defer responding to that question.
[01:11:09] Andrew Campling: Because the audio is not good here, I think Arnaud said that if there's a need for a liaison statement as chair of s g seventeen, he'll make sure one is provided.
[01:11:20] Jim Fenton: Okay. Thank you. We need to move on to the to the next presentation. The I we were it sounded like the verdict was going to be a mailing list, but it sounds like, actually, first, we need to clarify the relationship with ITU.
[01:11:40] Jordi Rajyal: Hello. Good morning. So I'm Jordi Rajyal from Qualcomm.
[01:11:43] Eric Rescorla: Uh-huh.
[01:11:44] Jordi Rajyal: And so we've been working for the Jordi?
[01:11:48] Stephen Farrell: So apologies. I I I just totally disagree with the idea that we can't dispatch something until ITU tell us that we can. It which is what
[01:11:55] Jim Fenton: I didn't see we were dispatching it to ITU. We were waiting for
[01:11:59] Stephen Farrell: No. No. I I disagree with the idea that we cannot dispatch something until ITUT do something, which I it's what I thought I heard you say. We can dispatch it to say we're not interested no matter what's happening in ITU.
[01:12:15] Jim Fenton: Noted. Go ahead.
[01:12:17] Jordi Rajyal: Right. Yep. Okay. So I was just saying that, yep, we've been working on the helping organize use cases for agentic AI. So a bit of background story here. In the past, IETF one twenty five, we had we had a site meeting. And and so what we did back then is we we thought that we wanted to bring some use cases about IdentityAI. As you know, use cases don't really propose, like, actual solutions or protocols. It's about defining the playground specific domains that people can work on. And then when going to that that side meeting and looking at some of the use cases, we realized that there were so many use cases coming to the ITF about AgenTakeAI that we had to do something maybe more abstract, which is and then the outcome of that meeting was to actually just say we should be working on on having a taxonomy to help organize use cases themselves because things are starting to be a bit disorganized, and we need to kind of bring some structure. So out of that side meeting on the idea of one twenty five, we took an action item, some of us, to to work on on taxonomy. And so we put a draft. So this is the draft that we are presenting. And this is a conversation about how how we can collaborate. Well, first, whether yeah. I'm just. Yeah. It's okay. Yeah. Whether first, whether yeah. Does it make sense to have a taxonomy for helping organize agentic AI use cases in the ITF? And secondly, how we can collaborate, basically. So let's move on to the next one. Thanks. Yeah. So I think we covered so this is the motivation for this. Like I said, so that many use cases come in to ITF. We feel that it's a bit unstructured, and this requires helping to organize them, classify them. Therefore, the need for a taxonomy. The taxonomy would help first do analysis of the use cases, organizing them, enable gap analysis, and ultimately requirement specifications. And also, you'll do know how to direct work to certain working groups. So next one. Yeah. So if you look at the document, we actually proposed a first proposal of the taxonomy. But again, we like to see this as a dynamic document and really driven by consensus because at the end the day, it's gonna be driven by experience and what we feel is necessary. So we actually put a GitHub repo also, and the idea is that we can enable, you know, pull request and and make use that as a as a vehicle to help organize the collective work. Right now, the taxonomy has seven classes and then each class has a subclass basically. We don't need to go through them in detail. I think it's about the concept here, but you got an idea what the taxonomy is right now. We can go next. Yeah. In the document, we also mentioned about when you write a use case, you know, what should be good properties? What should be you talking about? So we also have a section on this more attempts to give some guidance about, okay. I have a use case on AgenTiKi. I want to bring it to the ITF. What things I should be discussing? And then the idea is that you can use the taxonomy in your draft, in your use case draft, to help organize that. It's similar to, like, when you write a paper, say, for ACM or IEEE, that there is a taxonomy that allows you to classify your paper, then readers know exactly, you know, okay. This paper is about this this subject, so it's easy to classify that. Right? So similar similar concept. Next one. Yeah. In the draft, we also provide an example of how if you have a use case, how would you go about applying the taxonomy to it? We thought this could be useful to make to help see whether, you know, this is this practical and how we'd go about this. We So picked on one of the use cases draft that are coming up in this ITF, the DAWN use cases, and we provide an example. Today, we have a side meeting where the authors of this draft will also be describing how they apply the taxonomy and just to provide an example on this. Yeah. And then next one. Yeah. So what is the requested outcome here then? Again, determine the right home for this work to provide a structured framework for helping classify agent AI use cases across the ITF. So there are several buffs coming out in this ITF on agent AI, as you know. And where do we plug in? Where where where do we get some guidance in terms of how to how to how to plug in this work? And, also, maybe specific to to Dispatch, the idea that having a text only for AgenTiC AI use cases could also help Dispatch itself when a new draft or a new use case on agentic AI comes to the ATF, help organize it and and decide how to route that draft itself. Because if you understand which areas of the taxonomy get activated by the draft, then you can say, okay. Maybe this goes to this work working group or that other working group. So this would be a desired outcome from from this. And, yeah, I think that's it.
[01:17:35] Aaron Parekhi: Yep.
[01:17:37] Jim Fenton: Rich is first.
[01:17:39] Rich Salz: Hi, Rich Sauls. So it's interesting that you compared your proposed taxonomy to one draft. I think there are I don't even know how many AgenTic AI drafts there are in front of the IETF now, but it seems to me that it's not very useful unless you summarize or review at least half of them. And I wonder what the plans are. Do you consider that part of a working group that would do that? Is it an error in the drafts, or is it an error in the taxonomy?
[01:18:11] Jordi Rajyal: So I'm just trying to understand the last question.
[01:18:12] Rich Salz: Sure. You've only looked at you only looked at one draft. Shouldn't you be looking at more than one, or do you expect the group to do analyze all of the ones that are coming? And will you keep up with the flow of it coming?
[01:18:27] Jordi Rajyal: So I think the idea is is to make this a distributed effort rather than a centralized. So we realized that we started, like, trying trying to write use cases. We realized that this is not scalable. So that instead of writing the use cases for agentic AI, let's write a taxonomy. Then if anybody has a use case, you can write a draft on on on that use case and then have a section where you apply the taxonomy, like a small section where you would apply the taxonomy to that. So it's a decentralized effort then. Every every owner of a use case, we just apply the taxonomy, and this will help then everyone understand, okay. That use case belongs to this working group or that effort.
[01:18:58] Rich Salz: So Sure. But how do you know if the taxonomy is good by looking at only one draft? Sorry. How do you know the taxonomy is good by looking at only one draft?
[01:19:12] Lun Li: What's the what's the dispatch? Like, what do you wanna do?
[01:19:17] Rich Salz: More work is needed. Okay.
[01:19:23] Jim Fenton: Go ahead, Andy.
[01:19:24] Eric Rescorla: Hi. Yeah. I think this I I think this is a a mix of some interesting stuff and some kind of unfortunate stuff. The interesting stuff is I thought you did a pretty nice job of characterizing much of the considerations. I think the taxonomy is not very useful, and trying to map each use case into the taxonomy is not gonna work very well. And I think the example you show is actually quite instructive, where, like, a lot of it just is in app propell. And it's kinda just stuff that's filled in because it had to be filled in. And so I think this document should go should stay as the digital draft. I think that you should dip the taxonomy pieces and focus on sort of characterizing the angles of things where they're appropriate rather than trying to sort of force fit everything into into a single taxonomy, which I don't think is productive.
[01:20:04] Jordi Rajyal: So what what should we do with the useful stuff, Faker?
[01:20:08] Eric Rescorla: I think you should rip out the taxonomy pieces and and and just and just and just focus on characterizing the the the actual technical angles that are relevant to use cases, which that material is actually quite nice.
[01:20:21] Jordi Rajyal: From a dispatch perspective?
[01:20:23] Eric Rescorla: Nothing.
[01:20:23] Jordi Rajyal: Nothing. Perfect. Okay.
[01:20:25] Eric Rescorla: It should be individual individual draft to stay that way.
[01:20:28] Jim Fenton: Okay. K. Thanks. Usama.
[01:20:30] Usama: Usama, to you, Dresden. So in, first, before the dispatch question, you talk about in the draft, which you didn't mention specifically in your presentation, section 4.2.1, four two three, four two four two. In all of those, basically, you talk about attestation. There are a lot of critical severity vulnerabilities there. And about the dispatch, specifically, you are talking about use cases. There are a number of BOFs which are being proposed, specifically for AI and agentic AI. Agent to agent list already exists. So what I would suggest basically is to do nothing but to split this draft into whatever fits in these BOFs, and use this information specifically in these BOFs, or to propose that as these parts of those BOFs which are already existing. So I don't think this draft specifically needs any attention other than that to do something with the attestation part, which is really critical.
[01:21:33] Jim Fenton: Right. Arnaud.
[01:21:36] Arnaud Taddei: Yes. Hi, Jordi. So regarding this one, a bit like Rich has said, but from another angle is that the ATF is not the only one here. And many other places where people are working on on this, As I promised at the last IETF in Shenzhen that g seventeen would work on that, and out of the blue, we managed to create a focus group that is open to everybody, that is where objective 3.3 is on use cases. So you could get a lot of feedback from others regarding what you want to do, and then you could bring it back to ATF who is curated by a much larger community.
[01:22:16] Wes Hardaker: Wes Hartecker, Google, and also the DAWN one of the DAWN BOF chairs. I'm gonna sort of repeat what Usama and Ecker both said. It's a little too early. This is actually really good work. It needs to be done. But until this iETF is over with multiple boss kind of coming out and maybe forming something, there's nowhere to dispatch it to. That's a question that can be deferred. My guess is it probably needs to be coordinated across multiple of the future working groups and, you know, published under one, but but you'll need to interact with a bunch of them. Because the results of this is actually, you know, important with respect to where work has to be done within the ATF.
[01:22:59] Aaron Parekhi: Okay.
[01:23:05] Lun Li: Okay. Thank you. Thank you. Thanks.
[01:23:07] Jim Fenton: So what's what's the conclusion here?
[01:23:10] Lun Li: Nothing after this one.
[01:23:13] Jim Fenton: So Pick that up at the end. And then, so the next next presentation is Lun Li, MCP.
[01:23:28] Lun Li: Okay. Thank you. Thank you.
[01:23:29] Jim Fenton: Yeah. Bring the microphone up to you.
[01:23:32] Lun Li: Hello. Okay. Good morning, everyone. So this draft is basically about Cypher text based AI inference tool in the for the MCP, the Model Context Protocol. So ciphertext based inference basically means we are using FHE fully homomorphic encryption in this. Okay. Yeah. I'm doing Okay. So first, the problem and the context. The context is that, like, currently, all of times, we may have the request that we have some personal data or sensitive data we want to send to a certain server. Let them help us to process it, calculate it. Then, currently, all this process are being done in plain text. So, like, all the in crypto schemes such as TLS, what they protect is the transition, not the calculation itself. So the calculation, how we process data, the data is being processed in print. But so in this case, those privacy critical workload, they are not actually being being protected very well to protect the data themselves perfectly. So a possible way is to use fully homomorphic encryption, and we just do all the pros the ciphertext directly. Okay. So and and our context is since currently, MCP is one of the most common way, like, for AI agent to to to invocation interface, so we can just build this into the MCP. So what we want to propose is actually a very schema extension in MCP. So here, I just want to emphasize that the schema doesn't mean that we'll doesn't mean that we want to change the existing MCP protocol or the existing MCP schema. We are still using the JSON r p RPC stuff. We we are only adding a few arguments, like, that's relevant to the FHE parameters.
[01:25:32] Aaron Parekhi: Oh,
[01:25:33] Jordi Rajyal: okay.
[01:25:36] Lun Li: Okay. And then, like, some evidence of interest. First, regarding FHE, the standardization of it is something that is active actively going on, which is in the ISO standard. And besides, FHE is not the first time that is mentioning ITF. Actually, before there was already, like, a presentation on the FHE and privacy preserving computation related use case in the in one of the previous ITF in the PHD group. Okay? Yeah. Next slide. Alright. So this is basically a brief overview of what we want to propose to highlight how the architecture is going to work. So let let's say privacy preserving computation, we definitely have a trusted domain and and and untrusted domain. So, basically, we will have two MCP server that will work they will work as a pair. They work together. We will have a local MPCP server, which will do all the crypto stuff. So in this scenario, the crypto refers to the FHE crypto. So this server will be in the local inside the inside the trusted domain. Basically, it's usually with the MCP client, your user device together. So it will help you to encrypt whatever message or whatever payload you want. Then after the encryption into the FHE ciphertext, you will send the ciphertext into the remote, actually, the inference server, which is the is the is is the server that will do the ciphertext calculation or the evaluation. And after that, of course, you will only return the ciphertext result, and only the MCP client can use the local server to decrypt it and see the result. So speaking of, like, privacy preserving computation, the security boundary here is, of course, first, the plain text information, the any plain text data is not revealed to the remote server, and also the secret key is not revealed to the remote server. Okay. And here, I think the most important part is the section seven, which is the negotiation parameter. This this are just some specific stuff we want to add, okay, into the current MCP JSON RPC, the into the current argument. Because let's say now, if if this use case is being implemented, we have many different users and we have may also many different vendors that will provide those kind of MCP tools, provide the tools you do, FH three. Then different FH three schema, different algorithm, different vendors, they they need to we need to share a common way to write all those FH three crypto crypto, like, parameters we need so that we can inter operate. So that's that's why we want to propose this standardization is we are still using the existing MCP JSON RPC schema and also the FHE standardization from ISO. Okay? Next slide. Alright. So this is the current information what's going on. So this is our draft. It's the first version. Also, we have implemented a full running prototype, which I will show you a bit of detail later. This was presented yesterday in the hackathon as well. And they are also currently related already standards on MCP related and also the FHE securities related. And as I said, there was already a presentation in a PHA group in a in in ITF one two three before FHE use cases. So this is more like a continuation. Okay. Next. Okay. This one is basically the just a screenshot of what we implemented a live live demo. As you can see, at this one, we just choose a very fun use case where we use ciphertext to do image recognition whether the image is a cat or not. So you can see the the image will be going to be encrypted first then sent to the remote server, then sending back the result in ciphertext and only after decryption by the client, we can see what's going on. Okay? So not not many details here. The last slide. The last slide is basically answering the question. So since for our opinion, since this one is already FHU is already mentioned PFG group. So maybe it can fit into the PFG group. And, also, we want, like, any suggestion and collaboration from the community on this. So where exactly should we fit this into? Okay. Thank you. That's my presentation.
[01:30:04] Jim Fenton: Okay. Thank you. Elliot is first.
[01:30:10] Eliot Lear: Good morning. Thank you for your presentation. Thank you. Have you published your work in terms of in in in an academic environment, in terms of what the performance of this looks like and and also in terms of the amount of correct in terms of correctness? Have you published this work in an act in an academic form?
[01:30:38] Lun Li: Like, by published, do you mean, like, open source that
[01:30:42] Eliot Lear: No. I mean, have you written a paper and have it and had it reviewed broadly in terms of the of the correctness of what you're proposing?
[01:30:50] Lun Li: I think our own publication, not yet.
[01:30:54] Eliot Lear: Okay. I think it's a little bit premature for us to be standardizing this, quite frankly. PERG would be the general area maybe that that this goes into. It seems like there you know, if anywhere that would be the right place. If they're not willing to bite the IETF, I don't I I think it's too early for us to be looking at this until it until it gets wider eyes, wider
[01:31:17] Aaron Parekhi: review.
[01:31:17] Lun Li: Okay. Thank you.
[01:31:18] Jim Fenton: Okay. Thank you. Aaron.
[01:31:23] Aaron Parekhi: Hi. Aaron Parekhi. Have you considered bringing this to the MCP foundation in the Linux foundation to actually work on this in MCP?
[01:31:35] Eliot Lear: Oh, sorry.
[01:31:38] Roger Anderson: So did did you
[01:31:39] Jordi Rajyal: consider taking this to the MCP foundation?
[01:31:42] Lun Li: Oh, I think we that that might be yeah. That might be one of the one of the possibility also. Yeah.
[01:31:53] Aaron Parekhi: Yeah. It seems like this might be a good fit there. I'm not a 100% sure, but that's possible dispatch. Okay.
[01:32:04] Jim Fenton: Hey, Edgar.
[01:32:06] Eric Rescorla: Thank you for your presentation. This is an important problem. I think this probably isn't quite mature enough for anybody to pick up, but I think if somebody is to pick it up, it should be MCP, not us. We're not, like, we're in the business of, like, making micro extensions to MCP. So I think, like yeah. I think you should keep working on this, but I think you should bring it to MCP, not to here.
[01:32:33] Jim Fenton: Yeah. Steven.
[01:32:35] Stephen Farrell: Hi, Steven Farrell. So if you want to go and bring it to MCP, that that seems entirely fine. Think that's also an interesting problem, and I don't see why this shouldn't just be a a piece of good work that's done by the PEARG in the IRTF. So we can't dispatch there, but that seems to be the logical place that it's even in the the file name of your Internet draft.
[01:32:58] Jim Fenton: Did you talk to me, Archie?
[01:33:00] Lun Li: Oh, yes. When I submit the draft, it was submitted to PEARG first.
[01:33:03] Roger Anderson: Okay.
[01:33:04] Lun Li: Then it was sent to a dispatch.
[01:33:05] Phil Hallam-Baker: Oh, I see.
[01:33:06] Lun Li: Yeah. Yeah. That's like because the is the the it's not the first time talking about FHD. Yeah. Before, it's also
[01:33:14] Jordi Rajyal: So so you might wanna try it then
[01:33:17] Jim Fenton: and see. We can't use the second. Yeah. Are you using the mic?
[01:33:23] Jordi Rajyal: Sorry. Yeah.
[01:33:25] Jim Fenton: We we cannot. Yeah. So,
[01:33:28] Shuping Peng: we cannot dispatch through IRTF. Right?
[01:33:35] Lun Li: Okay. Okay.
[01:33:38] Jim Fenton: Thank you. So next presentation is remote. Mohammed, are you online? There he is.
[01:33:53] Mohammed Khalil: Good afternoon. Yes. I'm online. Okay. So good afternoon, everybody. I'm Mohammed Khaliluz, author of draft of. I'm hunting on authorization evidence for high risk actions to call signature to join me remotely. That's what I hope. I'm an of familiar protocols. The anchor Can you speak up a little bit? Yeah. The Yes. For this slot draft you to PCA with with related in the the drafts alongside. I'll about eight minutes. That's what I hope. Then I'll leave it for discuss. Just what I control okay. Thank you. So the problem, this work this is is not the lack. It's not that we lack signed artifact flex. We have them in multiple at multiple layers. What we lack, finding a way to compose them. In the taxonomy, Joe just introduced, which is on that tracker, the composition question is I'm raising sits directly on two of the categories of the taxonomy identifies. Accountability accountability under security, under trust, and the human loop under operating operations and management. This is not ajective work. It's exactly the requirements that as needed standardization. Several effort to find artifacts at different layouts. What's missing, common compression contract. Our relaying party defies each type of artifacts under its own trust rules, joins the results to one action and evaluate the set against the stated requirements. Third party in tariffs beyond the survey authors, DKA, Kashuri, joined the thread on the identity layers. Choq, Jonathan joined as the confirmation interaction layer. Both received, both insulated.
[01:36:06] John Levine: That's Mohammad?
[01:36:08] Mohammed Khalil: Yes.
[01:36:09] Jim Fenton: If I can interrupt, I'm seeing a lot of comments in the text that people are not hearing your audio very well. Is there some way you can get closer to a microphone or use a headset or something like that? Because they're not hearing you clearly, unfortunately.
[01:36:23] Mohammed Khalil: I'm using headset. Let's try to use another microphone. Do you hear better now?
[01:36:40] Jim Fenton: Seems about the same, I think.
[01:36:43] Mohammed Khalil: Okay. I'll try to
[01:36:44] John Klensin: be Okay.
[01:36:45] Jim Fenton: Do do the best you can. Maybe speak just a little bit louder or something. Okay.
[01:36:53] Mohammed Khalil: Okay. I I'll give you a little bit background and then direct to the question. We'll make it easier. Each of each effort that I'm visiting about, a crypt cryptography bins its own action or decision the SIP session. A common profile must define how these artifacts are joining to one action and most absent when symmetric. A couple of lists cannot be established. On each draft, you will see, like sorry. Just I'm so stressed. Okay. Let let let me move directly to question and to to stress. I have three three questions that want to ask. Does does this topic belong to dispatch or city at all? The material touch the ART and security. Second, does the confirmation action layer belong with check like work, like if it's work, or an escalated batch? Third, do the survey, the independent execution result, and the competence gap just to focus follow-up document and keeping this survey alone. Thank you.
[01:38:22] Jim Fenton: Okay. Ecker has a comment. Go ahead. Yeah.
[01:38:27] Eric Rescorla: So there's been quite a bit of discussion of this general topic in the agent proto working group. So oh, sorry. Mailing list. So I think what you need to do is kind of, like, chill out for maybe a couple of months and see what happens in agent proto. And if we decide to do something in this area in terms of having, you know, communication between the, like, tool harness, putting the client and, like, and, like, tools or or client and other things, then this would be appropriate thing to bring there. But until then, it's kind of, like, a little premature. So I'm not saying it's bad. I'm just saying I don't think we're quite ready to assimilate it yet. So I think you need wait.
[01:39:23] Jim Fenton: Any other any other comments on this? Okay. Alright. So, yeah, the the, the other other written comment was agreement that, the, agent Proto seems to be the seems to be the closest place to to go with this. Alright. That was the last presentation. Thank you to all of the presenters, and we should probably summarize here. Do you want to somebody else wanted to
[01:40:15] Shuping Peng: Okay. I will try. And the first one, the caller ID probably is the ITF shouldn't take it now because there are some thoughts about the proposal, whether it is deployable, and the the proposal may need more discussions. The second one, the email verification protocol. Yeah. That is above our our focused working group. And today, there's a side meeting, and you are encouraged to go to the meeting, have more discussions. And the third one, so Jim gave above, but probably it would be better to have more discussions. If there is no existing meeting list, create one and to get more energy and to see whether so one is get more mature and it can have above, and make sure to involve the right people. And the fourth one, PARCP and the parent control. And I think the discussed point is that whether this work belongs to IETF. And for now, we would say no action for dispatch, but the authors could do more work to, like, liaison with ITU and more discussions within ITF. Yeah. Okay. And the the next one. So so probably now is do nothing and no action from the perspective dispatch. And but in this IETF, there are more three AI related agent related bots. And after this meeting, we probably will create some working groups on agent. And so after that, and this work might be needed across those working groups. And the next one, MCP. There
[01:42:25] Ted Hardie: are
[01:42:25] Shuping Peng: some discussions, and the work is important and is worth doing, but the problem is where it should go. And but that is not so one is to Linus Foundation, one is to the PEARG. But that is not what we can do as a dispatch here. It's so no action from us. And the last one, probably the agent protocol proto above. And that is so talk with above chair if see it is possible to fit in there if we got a working group created this time, and that will be the right place to go. Okay. Any comments, questions?
[01:43:13] Eric Rescorla: Yeah. I don't think the last one, I don't think you want to talk to the buff chair. That buff is actually quite clogged already. I'm just saying wait to see what happens in the buff.
[01:43:23] Shuping Peng: Okay. Okay.
[01:43:25] Lun Li: Yeah. Understood.
[01:43:30] Jim Fenton: Alright. Is there any other business?
[01:43:33] Leslie Daigle: Yeah. Sorry. It was slow getting in the queue. Leslie Daigle, co chair of the agent proto BOF, and Ecker is quite correct. The agenda for that BOF is not to review documents and separate work. It's to motivate the overall direction of the work, and it's quite full. It's possible that at a next IETF meeting, if agent proto gets gets chartered, there may be it might be an appropriate place for the work, but not this week.
[01:44:04] Jim Fenton: Okay. Thank you. Any other business? Seeing none, thank you all for, coming to this session.
[01:44:43] Shuping Peng: Okay. This one. Mean, I I I think now people start channeling about the the outcome. Just one of one of these.