IETF 87 -- STIR BOF Minutes -- 30 July 2013 STIR BOF Chairs: Russ Housley and Brian Rosen Notes taken by: Jean Mahoney and Olafur Gudmundsson Minutes assembled by: Russ Housley Jabber Scribes: Dan York and Peter Saint-Andre Jabber log: http://www.ietf.org/jabber/logs/stir/2013-07-30.html NOTE WELL presented. ------------------------------------------------------------------------- Agenda Bashing Change to the agenda was posted on 29 July 2013. Hadriel Kaplan withdrew his presentation to provide more time for discussion. Dan York asked that folks state their names at the mic. ------------------------------------------------------------------------- Problem Statement Question: Should the IETF develop a solution to this problem? Goal: Determine scope... - Is blocking robocalling and the like enough? - Do man-in-the-middle concerns need to handled too? - Is provider-to-provider sufficient? - Have we failed if end-to-end is not provided? Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stir-3.pptx Slide 3 - Two modes of caller ID spoofing Henning: It is popular in the US to spoof 800 numbers since the owner of the number has to pay. It is also popular to impersonate a credit card company to collect personal information as part of a vishing attack. SWATing brings out emergency services when not necessary. Inter-carrier compensation - billing fraud - leads to free phone calls. TDOS - telephony DOS - extorts money from hospitals, hotels, and such. Slide 6 - Legitimate caller ID spoofing Henning: I won't talk about caller ID suppression since recipients get notifications that the caller ID has been suppressed, and they can choose not to answer. Slide 8 - Requirements Henning: You need to gain benefits from deploying incrementally. It shouldn't be all or nothing. Slide 9 - Not in scope Henning: We do care about cross-national calls, but it's okay if the solution is only for one country at first. If we can also get media protection, that's great, but it's not a primary goal. Man-in-the- middle attacks are generally not happening. Pete Resnick: The "Requirements" slide states that the solution must work without human intervention. Must it work with intervention? Is the requirements set for carrier-carrier only or could it be user configurable? Henning: I'll dive into that later. It should be done at a variety of points in the call flow, including ends. Hadriel: On the "Not in scope" slide, cross-national isn't in scope? It has to work across countries. We have the same problems with international calls. Henning: On initial deployments, working for a single country code adds value. The number of international robocalls is very small. Having robocalls originate in all kinds of countries is not the issue. The issue in the +1 country code is the caller ID presenting a 800 or a 212 area code. Bernard Aboba: There's a cross-national component to TDOS. This needs to be cross-national solution. Henning: The physical origin of the call can be anywhere. The spoofed number is in-country. If people see an international number, they just won't answer it. Dave Crocker: On the cross-national issue, we should be careful about engineering versus deployment. Eric Burger brought up performance constraints, and it was discussed on list. We must pay attention to any potential impact on the call setup time. Henning: We'll cover that later. Martin Dolly: The international part is important. It shows up as anonymous or a local number. TDOS is the most dangerous. Secondly, fraud. There are legitimate robocalls; some people have a right to solicit. Bob Moskowitz: People from the EU are being polite. We need to tackle cross-national. There's legitimate and non-legitimate robocalling. Henning: Robocalling isn't the target. Political calling is not illegal, but it is considered a nuisance. I assume that I have a right to block those. Bob: In my community, getting calls about births in the community is legitimate robocalling. Hannes Tschofenig: We shouldn't get hung up on this. The solution needs to be incrementally deployed. There's great value there. Henning: If we don't have the ITU signing the root of the system, that's ok; and we don't have to wait for them. Philipe Fouquart: There are E.164 numbers that are not tied to a state. Henning: I'm glossing over details in this presentation. I don't think it changes anything. Philip: That's right. Henning: It is important to capture that in the working group documents. Hadriel: Whatever we do has to scale for international uses. The work for carriers to deploy this will be massive. Dave Crocker: On the "Basic architecture" slide, it looks like it precludes that the signing is done by the calling phone. The solution should allow that as an option. Henning: Definitely, yes. Slide 22 - Incremental deployment Martin: On the "Incremental deployment" slide with respect to the stop sign, the carriers can only stop a call if the customer has said, "Yes, you can block traffic". A carrier can't stop ever without prior permission from the customer. Cullen: On the "Known unknowns" slide, the enterprise PBX should be listed under signing. Slide 23 - Conclusion Henning: Land lines are least protected from robocalls. There are multiple approaches that can work. Sanjay Mishra: Are countries other than the US saying that this is a problem? Henning: Yes, that is my impression. I've talked to Croatian regulators. Since Indians don't speak Croatian, they don't deal with much of this. Hannes: At WCIT, the attack pattern is a concern in other countries as well. Call fraud is a huge international issue. Henning: People pretend to be domestic so they do not pay billing charges. There is concern. Robocalling is a big country issue. For small countries, the issue is billing fraud. Wolfgang Beck: Are CAs better at validating phone numbers than phone companies? Is seems that the phone companies would be mire authoritative for phone numbers. Henning: We may want separation between signing entity and the authority system. National authority or their delegate could run the system. This is not the same model as domain name PKI model. If you get a certificate for a German telephone number assigned by US authority, then there's something amiss. Think of this as a primitive version of DANE. Eric Burger: On the "Conclusion" slide, bullet 2, this informs whether the IETF does anything. It will be 3 years before this is deployed. Instead of keeping PTSN going, let it decay and die. (applause) Klaus Nieminen: As a Finnish regulator, we think it's very important to validate caller ID. Using mobile number from another subscription should be there. Richard Shockey: In other jurisdictions like Germany, there's no legitimate spoofing. Whatever work we do here is not a silver bullet. We need to coordinate work with regulators. Philipe: At Orange, we have similar problems in countries where we operate. There are variations, and the exact nature of the problem may depend on the national numbering policies and what they permit. Hadriel: It is going to be a problem. We have SIP deployed to non- regulated carriers that sell to companies with Asterisk boxes. The chain of trust is expensive. In the US, it is cheap to connect and the chain of trust is broken. If it worked like email, you would throw your phone away. There is no silver bullet. Can do white lists, black lists, reputation systems help? Steve Kent: One should not confuse the terrible state of certificate authentication in web PKI with the proposed PKI for telephone numbers. It could be implemented in a much more secure fashion. The hard part for the CA in this situation is the databases. ------------------------------------------------------------------------- Solution Proposals Question: Is this ready for engineering? Or, is further research needed to develop a solution? Goal: Demonstrate that we are ready for engineering. Presentations: http://www.ietf.org/proceedings/87/slides/slides-87-stir-4.pptx http://www.ietf.org/proceedings/87/slides/slides-87-stir-5.pdf Jon Peterson gave the first presentation, and Eric Rescorla gave the second presentation. Slide 2 - In-band precedents Jon: Haven't seen RFC 3324 in the real world. RFC 3325 is used in a lot of contexts that were not predicted. RFC 4474 was dead on arrival. RFC 4474 was too restrictive, and intermediaries were modifying header fields. It assumed public ENUM, which never materialized. Slide 3 - Components of an in-band solution Jon: We seem to have agreement here. Slide 4 - STIR Logical Architecture Jon: Small points may be controversial. Room seems to be okay with it. Slide 6 - Rescoping to the Problem Jon: On the mail list, we reached consensus for limiting the scope to telephone numbers. Handling body protection separately does not have consensus on the list. Slide 7 - Limits of in-band Jon: We can argue about how hard it is to make changes at the carriers versus endpoints. We should consider in- and out-of-band jointly, allowing the group to look at the tradeoffs. Dave Crocker: I have a small point to register, and not pursue now. What should we sign? The core of the mechanism is not a certificate, but the digital signature. Similar to DKIM, the topic of what to sign raised some challenges. It is not straightforward. Be careful. Let the signer choose what to sign. Jon: We should select the smallest viable subset to sign. We should avoid variable strength of certificates. Eric Burger: On the "Limits of in-band" slide, do we need a solution that is better than what the PSTN provided 5 years ago? You trusted your service providers. The source of spoofing was bad PBXes run by enterprises. If we don't have to be better, then this helps us at the PSTN. It is a gateway at a carrier. If the caller ID in the SIP part is good and it goes to PSTN, does it solve the problem? Jon: The assumption is that once it hits the PSTN, it is in that trusted network. There are too many sources that inject bogus IDs. If there is data that that shows this a bad assumption, please point us to it. Maybe Henning has info on that. Henning: If you can validate before you hit the SS7 network, then you're okay. One of the problems is, if you validate in network, that the carrier has to make a decision without asking the user, who is not their customer. Not sure if you have a solution in mind. Generally, our experience with the gateway operators is that they want to do the right thing. They know their customers, but they can't tell their customers who their customers are. The problem is 3-4 levels down. I'm struggling with what that means. In my view, we can't go back to the PSTN model. Hadriel: The "Limits" slide shows why we need an out-of-band solution. Eric Burger said that if we are looking for a short-term solution, we're talking 2-3 years for the RFC. Vendors will not implement until the RFC is published. Then it goes into testing, and then it gets deployed. In that time, there will be a lot of SIP deployed. Thousands of SBCs for interconnecting SIP. The PSTN is not going to be swapped out. It's not our problem. Carriers are moving to SIP. Let's work on future. Jon: 95% of calls make use of the PSTN. Cullen: What can we sign that can survive the SBC? Hadriel is mischaracterizing PTSN. It's not what survives PTSNs; it's what survives SBCs. We can't make guarantees. Hannes: In response to Dave - The question is, what can you sign? The signature construction itself is not the issue. We have new work on Session ID. There's a challenge there. There are problems with deployments that mess with contents. Martin Thomson: Consider an SBC with SIP with both sides. I work for company that doesn't use SIP much. Needing in-band doesn't connect for me. Brian Rosen: Canonical to canonical - that mirrors something that we would see in SIP. Might some form of Session ID survive? Matin: I want interoperability. Jon: If we are going to accommodate non-SIP, are we going to look at out-of-band mechanisms? Martin: I'm not just thinking about my employer, I'm thinking about webRTC. Eric Rescorla (EKR) begins his presentation. EKR: This presentation is about what an out-of-band solution would look like if we decide to do it. It's not an argument for doing it. Slide 2 - Assumptions EKR: If you don't believe the first assumption (we care about IP-PSTN and PSTN-PSTN) you can tune the presentation out. slide 8 - Don't I know you from somewhere? EKR: This is a basic store-and-forward system. Not delegating to the chain. Slide 11 - Questions? Wolfgang Beck: What about call forwarding? How to locate CPS and know it's trustworthy? EKR - One CPS is the simplest case. Simple to build a federated system. In terms of trustworthiness, a single CPS in each nation. Martin: The PSTN isn't going away. Rural areas will have it for a very long time, but most traffic is moving to VoIP. Carriers want to retire the older infrastructure. PSTN being in the middle is not a justification for an out-of-band solution. I've talked to device manufacturers about an API to the dialer. The dialer has all your call information, and you don't want that exposed. EKR: I'm not defending that this is needed. Regarding the question on the dialer, it's a trusted application. I don't think you should expect that an application will interface with the dialer. The dialer will be modified, which is not a technical challenge. Hadriel: How does "Bob" know about CPS? Jon: We are digging too much into the details. Hadriel: I realize that the draft is early. Your draft talked about sending SIP to the CPS and bypassing the carrier; it's vipr redux. I recognize that's possible but unhelpful. I think we should remove out- of-band from the working group. Jon: I have no problem removing it from the draft. Eric Burger: The CPS will handle 3-4 billion queries a day. It must happen within 14-20 ms. It is not like DNS. It has to work the first time. It's not a solved problem yet. We have some years to make the hardware faster. It has to work first time under incredible load. EKR: If that's the correct time budget, then this won't work. My impression is that the budget is larger. The load is laughable from a webscale perspective; it is nothing. Steve Kent: This is just like iMessage. Apple is monolithic. I worry about using it as an example. As for third parties for credentials, let's just say "no". As for timeframes for deployments, people won't wait for a RFC if there is an economic incentive. If there's no economic incentive, it won't matter. Cullen: Enterprises would have better relationships with their customers by implementing this. This is trivial on a web scale. It's easy; there's not that many phone numbers in the world. It's not that big a deal compared to many Oracle databases. Dave Crocker: Focusing on technical issues rather than political - how much experience do we have that it will work and scale at speed? Twitter and iMessage are monolithic. It looks like a single global authority. On the list discussion, there are different views on who would sign and validate. If it's endpoints and SBCs, then it's not a technical issue, it's political. This is not trivial, we don't have an existence proof. It's an interesting engineering task. In-band is really interesting. Anyone that says that it's easy doesn't have proof. Jon: There is the existence of a large monolithic system that could do this. It might be the closest to what we understand. A distributed model is reasonable. Having an alternate enrollment system doesn't mean an alternate authority. A national regulator could have a proof-of- possession system. It would be horrible if multiple entities had responsibility for the same number. EKR: The challenge is a federated model. Don't base assumptions on how email works as an example. There will be a long tail of 3-4 people on a server, but the majority would be on a few giant servers. Henning: There are commercial systems on smartphones that crowd source caller validation. They don't modify the dialog, they do an event subscription. You could do something similar here. For scaling, separate what happens in real time. Adding 1 second or 10 seconds for call setup is not critical. On Mobile case, information can be cached. The frequency of changes like call porting is on a human scale not machine scale. Numbers are not reassigned that often. Separate what happens call-by-call versus realtime. There are lots of moving pieces that moves at a leisurely pace. Martin: The milestone should be in-band solution first; get it out quickly, and get it adopted quickly. Out-of-band solution should occur, but down the road. Differentiate the two in the charter. Russ: I want to take to hums. Hum 1: If we chose to tackle this problem, is it ready for engineering? Or, is more research is needed? Russ: Overwhelming response for "ready for engineering". Hum 2: Should the IETF take on some or all of this problem? Or, should the IETF avoid working on this problem? Russ: Overwhelming support for taking on the problem. ------------------------------------------------------------------------- Draft Charter Question: Can we reach consensus in this room on some charter text to forward to the IESG? Goal: Draft charter that is ready for review on the mail list and then IESG review - Present draft charter from mail list discussion - Make sure problem statement is clearly reflected in the text - Summary of the Problem - Scope - Deliverables - Milestones Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stir-7.pptx Jon Peterson presented. Eric Burger: Russ, when you asked the question about engineering, there is something to do. Ee need an ID mechanism that can survive SBCs that break the identity system. Vendors working in parallel to get this done. A lot of things won't be relevant. It sounds like an ITU issue I think. I don't know if it's relevant. Brian Rosen: What do suggest? Eric: SBCs broke the network, let's fix it. Jon: There may be nothing we can do to fix the SBCs. We're here about the problems identified here; vishing, robocalling, and so on. EKR: And we had solutions. Hadriel: RFC 4474 was broken fundamentally. It focused on domain names. Jon: I'm with Hadriel. Slide 3 - Preamble Dave Crocker: The first paragraph floats on its own. The last sentence is the sense of what the working group will do. I suggest remove the word "deployable". Add "within call setup time"; it's a non-trivial point. If it's too small, we don't have the engineering opportunity. I'll put my suggested wording in the jabber chat room: Suggested replacement for the last sentence of the first paragraph of the draft charter: This working group will define a mechanism that can perform verification within call-setup time, confirming the authorization of the calling party to use a particular telephone number. Brian: We've tried and failed because it wasn't deployable. Dan York: Deployable is a "motherhood and apple pie" term. How do we get something deployed rapidly? To do something sooner, we need laser-like focus. We need text that will help us rule stuff out of scope, less is more. Focus on getting this done. Jon: I hear you. Dan: I'll do the wordsmithing on the list. Jonathan Lennox: On the deployment point, we have to have a full architecture, we can't have magic. Don't assume that someone else will do magic for you. Sanjay Mishra: From a carrier standpoint add to the preamble that the solution should be deployable in chunks. Cullen: I want to discuss what's more deployable and sooner, in-band or out-of-band. Jon: Later. Steve: It sounds like you were ducking. You talked about previous efforts. I don't think we can do anything with an architecture that doesn't identify all pieces of architecture. We risk failure like we did in past. To Russ, I'd like to see a real threat model, be very clear about what the bad guys can do so we can assess if the solution works. Jon: There's 01 text. On ducking the architecture, can describe modular components that could work with other moving parts. I don't think we need to say that they have to have exactly these components. Hannes: We have a separate document on swatting. Jon: They're a different case because they *have* to accept calls. Orit Levin: What does "calling party" mean in the last sentence? Jon: The number rendered to the terminal. Orit: It's not clear. Jon: The proposed charter text is only shorthand. Slide 4 - Postamble Jon: RFC 4474 didn't work for telephone numbers. It is a nonstarter for this work. We need a mechanism to fix these things. Jonathan Lennox: Need to give consideration to the alignment of incentives. Make sure that it doesn't rely on somebody else to spend money so that I can get benefit. Brian Rosen: What text would you like? Send text to the list. Jon: It is salient to out-of-band. Slide 5 - The plan (wall o' text) Cullen: This paragraph starts with "As its first work item". But I think we should work on the in-band and the out-of-band solutions at the same time. Jon: The proposed charter text says that we will do in-band then out-of-band. We'll talk about it in a minute. Slide 6 - Limitations slide Hadriel: The middle bullet says to do out-of-band. Jon: We'll discuss at the end of the slides. Cullen: Let's just get through presentation of the proposed charter without the in-band/out-of-band discussion. Slide 8 - Disclaimers and Pleasantries Lucy Lynch: The punt on privacy considerations makes me extremely uncomfortable. And it really is a punt. Jon: There's only so much we can put in the charter. If there's something stronger, please suggest text. EKR: What should it say other than what it says? It's obvious there are privacy issues. What else are we going to say? Rich Shockey: We have 10 minutes left. We need to talk about doing out-of-band at all. I believe out-of-bound is undeployable, and we shouldn't do it. Slide 9 - Outputs Steve Kent: It should include a threat model and a privacy document laying out tradeoffs. Jon: Fair enough Eric Burger: Can we do the IETF thing? That is, get in-band done and then recharter for out-of-band? Hadriel: I'm with Eric. When we have rechartering, we would have more information at that time, no need to create milestones for later work. It is hard to sell later milestones to carriers. Bernard Aboba: I agree with Hadriel. We need to understand the PSTN scenarios. In-band may not do all we want, but we should work on in-band first. Dave Crocker: For every complex problem there's a complex solution that doesn't work. We should be narrow, focused and quick. The IETF can focus on stuff that's useful quicker. In-band and out-of-band are two separate problems. If we work on both at the same time, we will drop both balls. Let's have the charter focus on in-band, and then recharter for out-of-band. Cullen: In-band and out-of-band need to be done at the same time so that they will work together. From a deployment view, the users should get the benefit as early as possible. If in-band was finished tomorrow, how long would it take to roll out? Not earlier than 5 years. It's lacking incentives to reconfigure SBCs. For out-of-band, Apple and Android update very frequently, so one billion could be are covered in two years. There is a huge incentive to solve the problem for all users at the same time. Jon: IP-PBXes? Cullen: Easy thing to do across PBX with year and a half cycle. IP-PBXes are moving to cloud-based services. In-band solutions are a nightmare. Getting a SIP trunk takes a long time. It is hard to get a SIP trunk that will provide anything but narrow band. Brian: We are running out of time. People in line, please keep your comments to 30 seconds each. Martin Dolly: Speaking as someone with 29 years working for service providers, I disagree with Cullen. In-band will deploy more quickly. Klaus Nieminen: The mobile carriers can validate VoIP with in-band. Most IP-PBXes are connected to carrier side. We can ignore that. In-band is preferred. EKR: These have to be done jointly. There's a lot of commonality. If we're going to choose one, we should throw in-band under the bus. Martin, I think you're wrong. Sanjay Mishra: The in-band solution needs to be looked at. There are no dependencies in the in-band solution. We should pursue in-band first. Adam Roach: I support what Cullen said. This is good for devices and device manufacturers. Rich Shockey: I respect Cullen's argument. I support Hadriel. We should separate these, do in-band first, and recharter to do out-of-band. Jeremy Fuller: Working on two issues in parallel doesn't drive industry to the pain of deployment. Doing in-band only will get people on the same page. Doing both at the same time will avoid people sitting on the sideline. Hadriel: The charter has the out-of-band stuff in it. Are we going to call for consensus? Russ Housley: We will do some hums. Eric Burger: As Jon pointed out, we've failed at in-band for 12 years. Building on what Cullen says, if you get Apple and Google to do something, then it's over the top of voice. We're good at end-to-end communication. We should focus our efforts there. Hand out-of-band to the ITU since it preserves the PSTN; it will take them 10 years. We can work on the real communication solutions. Russ: We will do some hums for the charter: Choices for the hum are: (1) in-band only, (2) out-of-band only, (3) in-band then out-of-band, and (4) in-band and out-of-band together There was roughly equal support for "In-band and out-of-band" and "in-band only". There was less support for "in-band then out-of-band". There was no support for "out-of-band only". Cullen: I object to not having enough time for the conversation. I want it noted in the minutes. Russ: Okay. Russ: For the next hum, indicate whether you could live with in-band and out-of-band at same time? Russ: For the next hum, indicate whether you could not live with in-band and out-of-band at same time? Russ: There is more support for "could live with both" than "could not".