Pierce Gorman: Welcome to Tuesday Talks, a live discussion series where we bring truth and shed light across the brand identity and communications industry. I'm Pierce Gorman, Distinguished Member of Numeracle's Technical Staff, and I'll be cohosting today's session with Anis Jaffer, Chief Product Officer, and Brett Nemeroff, Numeracle's Vice President of Engineering for Voice. Brett has close to 25 years of experience developing, delivering, and operating voice solutions with experience both as a service provider and as a customer of service providers. Welcome to the podcast, Brett and Anis.
Brett Nemeroff: I'm glad to be here, Pierce.
Anis Jaffer: It's a continuation of you guys having the previous conversation, so I'm just going to be a fly on the wall, I guess.
Pierce Gorman: Well, hopefully, you'll be more than a fly on the wall, but yes, absolutely. Last Tuesday Talk, we dove into the FCC's 6th Report and Order and Further Notice of Proposed Rulemaking, specifically on the topic of third-party call signing. Brett and I did our best to get through it, but there's a lot to unpack there and we only made it as far as the paragraph following paragraph 100. So, paragraph 101. This is it, Third-Party Call Signing 101, as it were. In that paragraph, there is a description, or I'll say that the FCC kind of lays things out about what it is they're wanting to get feedback on. In paragraph 101, they described Hosted SHAKEN, Carrier SHAKEN, and SHAKEN software as three ways that have been described for doing third-party call signing. I remember talking with you, Anis, that you thought there was quite a bit of material on there to help people understand what they meant by that in the footnotes. Would you want to review a little bit of that for the audience?
Anis Jaffer: It was interesting that they had three options and they described those options in the footnote. Hosted SHAKEN is described as a turnkey STIR/SHAKEN authentication and verification solution offered in a public or private cloud that includes all the required SHAKEN components for offering a comprehensive standards-compliant solution. What it essentially describes is a software as a service (SaaS) that could be deployed in a public cloud or in a private cloud within customers' or service providers' cloud environment, which to me could be a relevant third-party kind of implementation that makes sense. We do know that there are companies that are offering this solution. So, that's Hosted SHAKEN. Then, they describe Carrier SHAKEN, which is another category of turnkey SHAKEN services offered by a growing number of direct, inward, dialing or wholesale providers that also provide SIP termination to the PSTN. This service combines SHAKEN authentication service with SIP termination. That's how they have described it in my mind. It's describing an OSP that's signing calls on behalf of other resellers or wholesale providers. That's how I see it. I'm not sure if this is really a third-party call signing kind of solution.
Pierce Gorman: That's why I thought we should talk about this. Brett, you had some comments on it. You had some thoughts about how this is being implemented.
Brett Nemeroff: On the Hosted STIR/SHAKEN, I think that that's where we typically look at what we call third-party signage. Carrier SHAKEN, though, is where it starts getting into the gray area. One of the things that's described in the footnotes is the possibility of an entity sending calls to a carrier with the expectation that that carrier is going to take care of STIR/SHAKEN for them. Now, for an end-communicating entity, maybe that's okay. But for an Originating Service Provider (OSP) sending calls to another service provider, it's really important. This is what I was talking about on our last podcast, the certificate that's being used to sign the call needs to also be useful for enforcement on that particular call. So, if we're doing Carrier SHAKEN and a service provider sends its calls to another carrier and expects them to sign the calls, the problem is the enforcement is going to go to the wrong carrier. It's going to go to somebody who isn't going to pull the plug on the customer, they're going to pull the plug on the entire carrier. Remember, one of the ATIS definitions was that you have to have a direct, authenticated relationship. The reason for that is a given carrier needs to be able to see across all of their traffic, across all the trunks that they have coming in, the differences between all of those individual customers. When enforcement comes down, they can say it's this customer that's sending the offensive traffic or this customer sending the offensive traffic. If they don't have that direct, authenticated relationship, for example, if a reseller is not signing their own calls, but sending the calls to a downstream provider and saying they're just going to sign all my calls for me. The problem is, when the enforcement comes to that carrier, they won't necessarily have a direct, authenticated relationship with the individual customers, so they can't know who to pull the plug on. I think that totally gets around the entire spirit of what we're trying to do here. One of the really good things that STIR/SHAKEN does is gives us the ability to point the finger somewhere so that we can perform enforcement. Enforcement is one of the main mechanisms that we have right now for removing Robocalls. If an entity that's signing it can't tell who's making that traffic, there's not a whole lot that we can do in terms of enforcement. I personally agree with Hosted SHAKEN as long as we're using a first-party certificate as a certificate from the Originating Service Provider who's sending the calls. That way enforcement works for Carrier SHAKEN. The number one thing for me, at least, is the certificate has to be tied to whoever is doing Know Your Customer.
Anis Jaffer: Right. And the Carrier SHAKEN scenario would also be applicable for intermediate call signatures that are being added if they don't get a call, right? So, if there's an intermediate service provider who's getting a call and they add a signature, would that be considered Carrier SHAKEN?
Brett Nemeroff: Yeah, absolutely. It's still Carrier SHAKEN and hopefully by the time that it gets to that intermediate provider, it's already got a SHAKEN certificate on it. If it doesn't, the only thing that can really be done at that point is to attest with a level of C, because that intermediate hasn't done any kind of Know Your Customer so they can't tell us anything else about it. Attesting it with a C and putting the certificate on it is still a good thing to do because it still gives enforcement some way of jumping as close as possible to where that traffic is coming in. It doesn't get us all the way there, but it's better than nothing, right?
Anis Jaffer: The last one that has been described is SHAKEN software as a software-based SHAKEN solution deployed in-network by the OSP or TSP. That's how it's described. To me, this is basically the deployment of an OSP service. I'm not sure if I would even consider this as a third-party call signing because it's a software that's been deployed by the OSP in their network. Maybe there's a vendor who has developed the software and deployed it. Regardless, if it's being deployed on the OSP and using their certificate, for all practical purposes it's first-party call signing. I don't see this as a third-party call signing. Any thoughts there?
Pierce Gorman: Yeah, I was going to make a couple of comments. One is, it does mention terminating service providers and I think the only comment they're making there is somebody's developed authentication and verification software. So, the STIR/SHAKEN software is the combination of those two. Use the authentication server as a server when you're signing a call and use the verification server to verify a call. It's the originating versus terminating side, but both of those are required together if you're going to be doing a full SHAKEN implementation. I wanted to make a comment on the Carrier SHAKEN-- they are saying that it's a downstream carrier that would be doing the calling or doing the signing. And I think the general concern that we've seen over and over again is that that signature is the signature of that downstream service provider, not what we would call the Originating Service Provider. That's the problem that Brett is pointing to. I will say that if a downstream service provider had access now this would be a bilateral agreement, but if they had access to the private key and to the certificate of that upstream service provider and we're just providing a signing service, then they would be more of a classical, almost Hosted SHAKEN signing service. So, it'd still be a downstream carrier, but operating as a Hosted SHAKEN signing service, if that made any sense.
Brett Nemeroff: Pierce, as much as I agree with you, the concern that I still have with that is the lack of a direct, authenticated relationship. It's still possible that a downstream provider could actually know about all the individual trunk groups. It still makes it really hard for a downstream provider to know who's plugged to pull when enforcement shows up.
Pierce Gorman: It's a good point. Even though there can be information either made outboard, like put in a database or something, that could be dipped by the downstream service provider, or you could even work out some way of sending the attestation info. I agree with you, it's really not well defined what all has to happen between the originating service provider and that downstream service provider to make sure that all the important components, the identity of the originating service provider, the private key signing so that it can be verified and the certificate all being associated with the originating service provider. It was a nuanced thing. I just felt like to be complete, I had to say it would be possible. There's a bunch of junk that has to happen to make it. The more clearly understandable thing is Hosted SHAKEN. You've got a third-party signer using the certificate of the Originating Service Provider carrier. SHAKEN is the one that we're all not comfortable with because it implies that you're losing the identity of the Originating Service Provider in the call signature. Then SHAKEN software is just your service provider. You want to sign and verify, you get some software. All right, I think that there might have been some more material, so I'm going to double check here, but I think we covered what we wanted to for the most part out of paragraph 101. Others might have questions, and if they do, hopefully, we can get to those. Okay, paragraph 102, what are the pitfalls of third-party authentication? I think we've gone over some of those already, but I think Brett, you had some opinions on this. Do you want to get us going on it?
Brett Nemeroff: I'll just say in my personal experience, I haven't seen any evidence that the analytics engines are actually using attestation to either elevate or de-elevate the amount of trust in a particular call. I haven't seen that happen. Also, it's really important because I think that the Attestation levels get confused with trust levels, perhaps. Just because a call is signed with an A doesn't mean that the call is good. It doesn't mean that the originator isn't spamming their end users or doing something offensive. People will oftentimes talk about how they want their traffic to be an A because they don't want to be labeled. It's important to realize that an A call can still get labeled and it's not just a mistake in analytics, an A call can still be offensive, right? The only thing that an A really means is that we've got a certificate for the originating service provider and they are attesting that they have performed a high level of Know Your Customer on the person who's making the call and they know who that is. So, I don't know that this is necessarily a pitfall, specifically a third-party authentication, and I think it's more of attestation. Those are my thoughts there.
Anis Jaffer: I agree. On the analytics side, they use attestation as one of the inputs for looking at what kind of call it is, but it's not the final determining factor, right? You can have a call signed as A and still be labeled as spam and for legitimate reasons. It could be an entity that is legitimately spamming even though they get signed with A. So, I think using the attestation level to say whether the call is good or not, I don't think that's the right intent.
Brett Nemeroff: Keep in mind, we still see plenty of calls that aren't signed at all and they don't get labeled.
Anis Jaffer: That's right.
Pierce Gorman: I think my comment was going to be, from my experience, it does look like the call signatures and attestation are being included in analytics results. Although your comment wasn't that they aren't, but that you didn't see evidence of it in terms of there's no way for you to easily tell about all of the signed calls getting better treatment, necessarily. It's just that the information isn't easily available to know whether or not there was better treatment and that it was appropriate because your point was an A-level attestation can be applied by an Originating Service Provider who's done careful Know Your Customer information gathering, has a direct, authenticated relationship with that customer end entity, and is legitimately applying that A-level attestation versus another service provider who may have been served one or more cease and desist letters, not pay any attention at all to what kinds of calls are coming across your network, have no usable Robocall Mitigation plan whatsoever, and every customer gets an A-level attestation, which I call poisoning the well. That might be part of the reason why you can't necessarily tell that analytics has been beneficial.
Pierce Gorman: The concern that the third-party analytics are somehow impaired, I suppose that's true, but I don't know that you can get away from it by saying, well, now we won't use third-party call signing or we'll get a better experience because of third-party call signings. The concern about analytics is sort of orthogonal to what are the pitfalls of third-party call signing because it's not a pitfall of third-party call signing, it's a pitfall of SHAKEN.
Brett Nemeroff: Right. One of the points that I wanted to make, though, is that we know that there is a non-zero amount of poisoning the well it's out there, right? We know that there are service providers out there that are putting A's on calls that don't necessarily deserve A's, and that haven't done a thorough amount of Know Your Customer. The thing that we have to realize in this ecosystem is that the bad actors are looking for those carriers, actively looking for them. So, as much as that is allowed out there, there is going to be poisoning of the well, and there is going to be potential impacts to the performance of analytics. Should they actually apply that? And that's something that we have to be aware of. That being said, I don't know that third-party authentication necessarily changes the equation at all for this particular problem.
Pierce Gorman: Other than if it's the examples that we've already given before, where it's once removed, or how many layers were removed from the actual origination.
Brett Nemeroff: I wanted to add one additional note on there about with third-party authentication and where the attestation comes from. The originating carrier can't ever give up the responsibility of saying, "I hereby give this call an A," or "I give this one a B," right? They can't just say, "Well, I'm using a third party, they'll figure out if it's an A or a B," right? Generally, in those circumstances where we do see appropriate use of third-party signage, we'll see things like the Originating Service Provider using their own business logic to tell those software solutions, this is the attestation that we want to use.
Pierce Gorman: I think we've pretty well-covered paragraph 102. Let's move on to paragraph 103. In that paragraph, the FCC asks, "Should we explicitly authorize third parties and what limitations should we impose?" Brett, what's your opinion on that?
Brett Nemeroff: I think that third parties should absolutely be allowed, and I think it's really important that we allow third parties. The cost to improve all of the infrastructure out there to support STIR/SHAKEN is tremendous across the entire telecom ecosystem. Having third parties out there does two major things for us. Number one, it reduces the financial burden of each individual company out there to do their own individual implementation of it. The second is because there are additional options out there, it means that we can get this implemented quicker. That's really important because as long as we have these windows of opportunity to get calls onto the PSTN without STIR/SHAKEN, bad actors are going to abuse that, and they're going to get calls out on the network that are offensive or abusive, that have no STIR/SHAKEN and are hard to perform enforcement on. Ultimately, if our goal is to reduce robocalling, we need to do whatever we can to increase our ability to perform enforcement. Having these holes where we allow entities to have a path because it's expensive or because it's complicated with the technology-- as much as we're giving those passes, and I understand, years ago, maybe it makes sense because there has to be some amount of ramp-up time, but now there are third-party entities out there doing signage, and they should absolutely be allowed because implementation is the only way we solve this problem.
Pierce Gorman: Okay. Anis, any comments on this?
Anis Jaffer: Yeah, I have a question here. Now, if the third-party call signer is using the first-party certificate, is it really third-party signing? How is it different than using a tool developed by another vendor and then using your certificate to sign? Is that even considered a third-party signing if you are using first-party certificate to sign the call?
Brett Nemeroff: Personally, I don't think that it is third-party signage. I think there are a lot of business operations that businesses normally do that they outsource to third parties. They don't necessarily say, we don't do these functions. It's just an extension of an internal business process.
Anis Jaffer: Right, exactly. That's how I see it. So, to me, calling this third-party call signing, if the certificate is actually from the first-party, technically, yes, it's third-party, but then you're using your own certificate, so it's a tool that you're using.
Brett Nemeroff: Now, I had a similar discussion with Alec over at TransNexus about this. One of the examples that he had given me was if you were working with Amazon and you were using one of their servers, you wouldn't necessarily say Amazon is performing your business function for you if it was your code on there, if you're operating that code yourself. I think that the analogy holds up. I think the important thing to understand, especially with Hosted STIR/SHAKEN or third party-- I don't even like the term third-party, but hosted, I think actually does make a little bit more sense-- is that the Originating Service Provider owns the business logic, the decision making, the certificate, the enforcement, the buck stops at the service provider. We are never taking responsibility and giving it to this third-party entity. They really have nothing to do with it other than providing the software solution. The carrier maintains responsibility.
Anis Jaffer: Yeah, I agree with that. Here's my related thought on this. Is this a case for, I'm going to say it, delegating certificates, even though this is not a delegated cert as it was intended in ATIS? Is there a way to call this a delegated STIR/SHAKEN certificate that's being given to the third party, even though the OSP is the one that's responsible for that? Is there an opportunity or is this a use case for something? I'm just throwing it out there.
Pierce Gorman: Well, I think we could do a whole show on delegated certificates. The way that the policy was written, version 1.3 of the certificate policy from the governance authority, and I have seen various comments on this, but I would say that the FCC probably should have asked about certificate delegation and signatures with certificate delegation, and then what's the third party use case there? If we think of third party as being this business relationship that Brett described, where it's really on you to have done the signature, but you're just using a service, whether it's hosted on AWS, etc. It's your responsibility. You understand the obligation and you're fulfilling those functions and you're not outsourcing the obligations with attestation or anything else out to anybody else. Specific to what we call delegate certificates, the ATIS 10092 specification, the intent there was to allow nonservice providers to be able to sign calls. One of the reasons why I think it would have been great if the FCC had explored that a little bit was to understand some of the pitfalls that exist in that and in terms of maybe authorizing third-party signing as it relates to delegate certificates because it has a different set of pitfalls and concerns associated with the reliability in the standard subordinate certification authority, which is a service provider. I think I could go into a lot of weeds on this that would take a lot of time and probably confuse the daylights out of the audience, so I don't want to get too far down the delegate certificate rabbit hole. I'll just say that it's appropriate for nonservice providers and the FCC's focus in the 6th report and order was really on STIR/SHAKEN and addressing what you might call the signing and attestation gap that exists within service providers. Just leaving TDM to the side without even talking about those kinds of technical issues with even being able to authenticate a call. Just staying with VoIP, we've had issues with service providers. Shows up in the Robocall Mitigation database as having claims to STIR/SHAKEN compliance when they're not authenticating calls, they aren't registered with a policy administrator, they aren't being issued service provider code tokens, they aren't acquiring certificates. It's what we've described internally as the third-party signing with a third-party certificate versus the first-party certificate that Anis mentioned earlier. All right, so if we're done with paragraph 103, I think we'll move on to paragraph 104. Okay, so paragraph 104 addresses the costs associated with the implementation of STIR/SHAKEN. They wanted to know, oh, I apologize, I'm going to go back to 103 for just one moment. It mentioned authorization of third-party signing and Brett, you used the term allow. Allow and authorization are two different things. So, yes, I agree with you that the FCC should allow third-party authentication. What they mean is authorized, like specifically write a rule authorizing and constraining and specifying what third-party call signing should look like. I agree with your terminology where you said they should allow it. I don't know that they should necessarily authorize it and prescribe rules about what that means other than what we've described as the first-party signature. Whether it's applied by a third party or by the first party, it needs to be the identity of the service provider with the direct, authenticated relationship with the customer identity and who has the knowledge about whether or not they can apply an A-level attestation on that call.
Brett Nemeroff: Yeah, and one of my thoughts on that, Pierce, was that we already have rules from the FCC on what service providers need to do. I think we need to stop creating these windows of exception for service providers. I don't know that we necessarily need it to be separately authorized. As long as third-party signage is using a first-party certificate that internal business process carriers should be solving the problem using their own means.
Pierce Gorman: I agree. And that meets the requirements of the traced act also, in terms of getting back to the throat to choke, the neck to ring where there is the admission of illegal robocalls.
Anis Jaffer: Okay, one comment there, Pierce, before you move on. I think the FCC document is kind of asking, would there be a security concern if the SPC token is shared? I think technically it shouldn't be the SPC token that is shared. It should be a certificate that's generated using the token that should be given to the third-party call signing. That's how I see it.
Pierce Gorman: I agree with you. Then, that third party that would be signing with the first-party identity information would also be using the private key in their authentication server that's associated with that first-party originating service provider. So, the SBC token is just a technical piece that's used between the policy administrator, a service provider, and a certification authority. It's not really germane. As far as signing is concerned, you need a private key, and you need a certificate with a public key that can verify what was signed with a private key. So, it's a good point. Let's move on to 104, and see if we can get through the rest of the paragraphs. Paragraph 104 addressed the costs associated with the implementation of STIR/SHAKEN and they wanted to know if there was any benefit. Brett, what do you think?
Brett Nemeroff: Yeah, I touched on this a little bit a minute ago. STIR/SHAKEN carries a significant financial burden for carriers. I think having third-party signage, allowing third-party Hosted STIR/SHAKEN, makes STIR/SHAKEN more accessible to more carriers, and I think ultimately that's good for the entire ecosystem.
Pierce Gorman: I agree. Then there was a question about how to monitor implementation by third parties and whether should it be included in the Robocall Mitigation Database. I have an opinion on that, but what's your opinion? Well, let me see. We're going to go with Anis or Brett? Let's go with Brett because it's the Brett show today. Go ahead, Brett.
Brett Nemeroff: I don't think that we should require service providers to necessarily divulge that they're using third parties. As long as they're using the right certificates and they're following the rest of the rules and regulations, that's an internal business process, and I feel like it's an overreach by giving the FCC the authority to record that information. That being said, I do think that for service providers to indicate in the Robocall Mitigation Database that they're fully STIR/SHAKEN compliant, they do need to absolutely be signing calls with their own certificate. I think that that's really important.
Anis Jaffer: Yeah, I would agree with that. I have some other thoughts. If a service provider is using a third party as an internal tool or outsourcer and they're using their own certificate, then I don't think FCC needs to say anything about how it needs to be compliant. It's on the OSP to do it.
Pierce Gorman: I agree with you. And the FCC asked how they would certify to that. And I have a pet idea that you wouldn't just say, "Oh, I'm going to do it," and you kind of hope that they do. I think they ought to be required to make a phone call to an interactive voice response server hosted by the FCC and also get a report on whether or not they successfully verified. Their identity is going to be in that call when they make that certification call. It would be more than just attesting to it in the Robocall Mitigation Database. It'd be a real live network test.
Brett Nemeroff: I think that's a great idea because a lot of people depend on their downstreams and just say that they're compliant, but they're not really. This would require them to prove it.
Pierce Gorman: Yes, I agree. Well, I think we're out of time and we almost made it to paragraph 106. If we have any folks who regularly join Tuesday Talks and want to hear about paragraph 106, let us know. We can maybe get a blog, or respond to you privately. I doubt we'll do a whole Tuesday Talks on it, though. We'd like to thank all of you for joining us for another episode of Tuesday Talks. We'll be taking a week off for the 4th of July holiday, but we'll be back live on Tuesday, July 11th, with Numeracle's Rebekah Johnson and a special guest, Doug Ranalli, Founder & CEO of Gated Networks, Incorporated. So, be sure to register to join us live. We hope to see you there!
.png)
.png)
.webp)
