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 co-hosting today's session with 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 as both a service provider and a customer of service providers. Welcome to the podcast, Brett!
Brett Nemeroff: Thanks, Pierce. I'm excited to be here.
Pierce Gorman: It should be a good show. We're going to discuss the 6th Report and Order and Further Notice of Proposed Rulemaking (FNPRM). Brett, if you wouldn't mind, dropping that link into the chat so people can go download it and read it in all its wonderful glory on their own if they'd like. I'll mention that we also filed a set of comments with the FCC on this proposed rulemaking; I don't know if they're already available-- I assume they are. Anyway, we did file. If we say anything here that doesn't sound quite like what we said there and there are conflicts, just let us know. Hopefully, that won't be the case. Now, to kind of give people some background on the way the FCC writes these things: they present you some thoughts about what they're dealing with, the questions and problems that they have, then ask some questions and get feedback. To warm the audience up, I'm just going to read Paragraph 97 from that Further Notice of Proposed Rulemaking to let you know what it was that they were asking about. They said, “The record before us is not sufficient for us to understand the full scope of the various arrangements that exist between providers and third parties that authenticate their calls. Nor does it allow us to determine whether these 3rd-party arrangements satisfy the requirements of the Commission's authentication rules, how and what information is shared within those arrangements, whether that information sharing implicates privacy, security, or other legal concerns, and whether they have a net positive or negative effect on the reliability of the STIR/SHAKEN framework and its objective to curtail illegal spoofing.” I'm going to just queue that up right there, Brett. I think it’s a good thing for them to share the stuff that they really want to know about, but they ended with the curtailing of illegal spoofing, which caught my attention. Did it catch your attention?
Brett Nemeroff: Yeah. That always kind of irks me when I see that phrase and I see them use that frequently. Most people, when you ask them what the purpose of STIR/SHAKEN is, a lot of people out there will say that it's to prevent spoofing. And the reality is it just doesn't address spoofing. What it does do, and it does very well, is it gives a pointer for enforcement because of the way that the certificates work, it gives a positive way for a terminating service provider to find out where a call came from, but because you can put anything into a passport, it really doesn't do much to prevent people from doing things that they're not supposed to be doing.
Pierce Gorman: I agree with that. One of the things that I've tried to remind people about is, spoofing isn't illegal to begin with, and there are plenty of legitimate uses for spoofing. The one that used to be rolled out pretty frequently was when a doctor calls a patient. A lot of times the telephone number associated with that call will be the receptionist number at the clinic, not the actual doctor's originating phone. That's a pretty trivial example, but it is a legitimate example of spoofing that wasn't illegal. The other point there is, and this is what I think you were hitting on, Brett, when the call is originated and it gets to the service provider, it might be difficult for them to know whether or not that number belonged there. The fact that the call is signed, that the FCC Enforcement Bureau could go to that signing service provider and talk to them about problems with illegal calls that were using spoofed numbers-- that's what the real purpose of STIR/SHAKEN is-- to give that, as you pointed out, the identity of the signer so that you can talk to them about problems that you might see in the spoofing of the number. The spoofing happens before it gets to the service provider, before the authentication occurs, so it doesn't prevent spoofing. Spoofing is not illegal. It's just a place for enforcement to go if there's a problem.
Brett Nemeroff: Right, and Pierce, to elaborate on that too, I would say that enforcement does help with spoofing. It does help eliminate spoofing. So anything that we can do that helps the process of performing effective enforcement will help to eliminate some of the spoofing.
Pierce Gorman: I agree. In the technical circles where we were developing the protocol, that's exactly what we had counted on-- that the Enforcement Bureau would have STIR/SHAKEN as a tool to identify the bad callers and be able to go talk to the service provider serving those bad callers. For folks who haven't read through these things before, they're broken up into numbered paragraphs. We're going to move on to the next set of questions that they had. Now, we started with and I'll just say we kind of cherry-picked questions. There were questions that were for lawyers that we’re not suited to answer, so we skipped over those. There were some that asked for data that we don't necessarily have and didn't respond to in the comments that we sent to the FCC, we won't talk about them here either. This one from paragraph 98 is, “Are originating or other providers entering into agreements with 3rd parties to perform their authentication obligations under the Commission's rules and the ATIS technical standards?” And the short answer is 3rd-party signing does exist. Then they went further about who these 3rd parties are. Brett, you want to comment on that?
Brett Nemeroff: Yes, and what I would say about who these 3rd parties are-- in my opinion, I don't think it matters who the 3rd parties are as long as the individual service providers are meeting the expectations of what the Commission has set forth as their obligations. That should really be an internal decision of how a service provider performs their obligations.
Pierce Gorman: I agree with that. Your point is that it's an internal business practice and the important point is that the calls get signed by or on behalf of the service provider who has a direct authenticated relationship with the communicating identity and the attestation is assigned accordingly. The next question in that paragraph was, "How does any agreement between a provider and the 3rd party purport to assign responsibility for compliance with the Commission's authentication rules and the ATIS standards?” Here I do the caveat, I'm no lawyer, but my opinion is the 3rd party Signing Service Provider (SSP) should ensure. Now, this is the Signing Service Provider, the guy who's actually creating the identity header and making it available to be put into the invite and sent out to the terminating service provider. If I was the 3rd-party signing provider, I would tell the communicating service provider that was hiring me to build those identity headers for them, that they're responsible for compliance with the Commission's rules and staying within the ATIS standards. The attestation that would need to be there has to come from them. And the certificate that's used to verify that signature also has to be their signature and it has to be their private key that they obtained, that they created when they got the certificate.
Brett Nemeroff: I totally agree with all of that. I think in a proper relationship with a 3rd-party signer, the service provider always retains all of the responsibility and obligations that the commission gave to them. I think that's a really important point on what is a proper 3rd-party relationship. We'll cover this a little bit more here in a minute, but service providers can't give up their obligations by handing them over to a 3rd-party company. That's really important. The service provider, even though they may be using another company to perform the signing activity, is still responsible for the responsibilities and obligations that the commission gave them.
Pierce Gorman: Yes, I fully agree. And as you said, we're going to get into what 3rd-https://www.numeracle.com/insights/inside-the-innovators-pierce-gorman-on-call-authentication-design-standards-developmentsparty signing even means in a little bit. What is the 3rd party? What's okay? What's not okay? The next question was, "Are there 3rd parties marketing callerID authentication services for originating and other providers?" I thought this was an interesting question and they even asked it right-- because I think that the answer is manifestly, yes. If we were to detail, though, the different types of 3rd-party authentication arrangements, how would you describe them, Brett?
Brett Nemeroff: The two that we're seeing really are 3rd-parties signing with a 3rd-party certificate. This really should not be allowed. This is a 3rd party that's using their own certificate and it shouldn't be allowed because it subverts the ability to perform enforcement. That's really what the intent here is, to be able to provide enforcement. You'll hear us say this kind of over and over again. The certificate gives you a mechanism to reach out and ring someone's neck or pull someone's plug or whatever that is. When you have a 3rd-party company performing the signing and using their own certificate, rather than the originating service provider certificate, what ends up happening when enforcement happens is they reach out to that 3rd-party company. That 3rd-party company isn't actually making the phone calls, they're only signing the calls. So, if they're going to try to do anything to affect that traffic or to remove that traffic, or to perform any kind of enforcement action, the only thing that they would really be able to do is to stop signing the calls. They wouldn't be able to pull the plug or make adjustments to the traffic or anything. The other way that we see it, and this is a way that absolutely should be allowed and addressed, is a 3rd-party signing agent with a 1st-party certificate. In other words, having a 3rd-party signing agent who signs it with the certificate of the originating service provider. In this particular model, when enforcement occurs, the originating service provider is held accountable. When we talk about that 1st-party certificate, it's the certificate of the entity that has a direct, authenticated relationship with the originator of that traffic, which means specifically performing a high level of KYC. And one of the things, Pierce, that I've been kind of disappointed in is the lack of definition of KYC. As some of you may know, we produced an ex parte detailing model standards for KYC. In some of that, we cover what you really need to do to cover your bases and make sure you're doing this properly. But those are the two methods that we typically see. And certainly, 3rd-party signing with the certificate of the originating service provider should be allowed.
Pierce Gorman: Yes, I agree. The only comment I'll make on what you were mentioning at the beginning about the problem with a 3rd party signing with a 3rd-party certificate is that you're hiding the identity of the 1st-party service provider. That's the problem with it. If you use the identity of the information and the certificate, you find the signing service provider (the intermediate service provider) instead of the originating service provider. You mentioned you can't really pull the plug either... I will say that the FCC would feel very confident saying that they can pull the plug on that intermediate provider if they weren't able to trace back beyond that, to the originating service provider. I know they feel capable of pulling plugs on people if they know who they are.
Brett Nemeroff: I agree with you. That last point you made, I think, is really the kicker, as long as they know who they are, right? Before we had STIR/SHAKEN, it was really difficult to find out where the traffic came from. We would have to go hop by hop and do a whole investigation that could involve dozens of service providers. That's the whole point of STIR/SHAKEN. Well, it's what I see as the point of STIR/SHAKEN. It's what STIR/SHAKEN actually does quite a good job of-- identifying who was responsible for allowing this traffic to reach the PSTN (Public Switched Telephone Network). So when we're talking about enforcement, it's a really great vehicle to reach out all the way across perhaps dozens of intermediate service providers and find an effective place to pull that plug.
Pierce Gorman: 100%. I used to call that automating traceback and it fit perfectly with the TRACED Act and the idea that you're trying to identify the sources of the illegal robocalls that you want to tamp down. I don't know if we'll ever 100% completely eliminate all illegal robocalling or any kind of illegal calling, but we're going to keep working on this. We're going to make a difference. I'm pretty confident about it. Moving on to Paragraph 99, "The Effect of Being A 3rd Party." I'll just mention to everybody quickly before we move on-- There are Paragraphs 97 through 106. We're going to do our best to go through these. If we don't make it all the way through in this show and folks are interested in having either a follow-up show or if they want to see a blog or just want to ask us questions, those are going to be options depending upon how well we do getting through those. Paragraph 99 summarizes the effect of being a 3rd party on how signage attestation is performed. To me, the question about attestation associated with 3rd party call signing is a little bit of a red herring, right? Because the attestation is a complex subject. As we were working through this, preparing for this show, Brett and I thought that this topic all by itself is worthy of its own Tuesday Talks presentation because it is complex, and because of that complexity, I don't think it helps to mix it in with talking about 3rd-party signing. To me, 3rd-party signing needs to be signing with the certificate of the originating service provider who has that direct authenticated relationship with the communicating identity, the customer. If you have those things, you've met the requirement in terms of signing and providing the identity of what we call the originating service provider. That's the key thing, right, is that you're getting the identity of the originating service provider. Now, are they applying the attestation correctly? There are guidelines and there is also a standard that says that it's local policy. I might be stepping on what Brett had to say, so I'll just stop there and say 3rd-party signing should be considered outside of attestation. Just understand if you're okay with how 3rd-party signing would be done, we say that 3rd-party signing with 3rd-party certificates is bad. 3rd-party signing with 1st-party certificates is good because then you get the identity of the originating service provider.
Brett Nemeroff: When it comes to the level of attestation, like Pierce said, this is a hot topic and I've also referred to it as one of the deadest horses in telecom because we keep talking about this over and over. Honestly, I feel like we need to keep having the conversation because when it comes to A, B, and C, people are still kind of confused about how those attestations are applied. So I'm going to touch on it. I'm not going to go into it too deeply because, like I said, we could have a whole hour on attestation. What I will say is that when it comes to 3rd-party signers, they need to be using the certificate of the 1st-party service provider, the originating service provider. Everything that's happening is part of the requirements of the originating service provider. It's part of their responsibility. So, when it comes to, "Do I sign this call or not? Do I sign it with an A, do I sign it with a B or do I sign it with a C?" That is entirely up to their business logic. The 3rd-party entity that's assisting with the software or the signage of itself is not actually part of the process of applying business logic on how calls get signed. It is 100% the responsibility of the originating service provider to decide what gets signed, how it gets signed, and it has to use their certificate. They can't use somebody else's certificate. That way we know exactly who is responsible for that business logic. That being said, without getting into too much detail, I saw that there was a question about this and, I don't know, Pierce, you may have some additional comments on this, but generally speaking, A and B attestations really, really require KYC and direct, authenticated relationships. As I said, we could have a whole discussion about that. I don't know, Pierce, if you wanted to add anything on to that before we moved on.
Pierce Gorman: Looking at the question from Harold Salters, do you mean some big 3rd-party signers or providers of TNS? Yes, that's correct. So, they can talk to the B aspect of Attestation. Okay, that's fair. What do you think of that? Would you be okay with them doing B's if they provided the okay? So, Harold, I'm so glad you asked the question. I'm not going to answer it, and I'll tell you why. Brett and I decided that we needed to have a whole show just talking about attestation to try to answer your question. What sparked that question was looking at a chart that's in one of the Call Authentication Trust Anchor Working Group reports that talks about various ways that you might encode attestation based on four different inputs. Thinking about how you could write code that you could then use to assign the proper attestation. There are some gray areas in a few of those and what you just asked would be what I would call one of the gray areas where you could argue about whether or not it was okay or wasn't okay. So, I apologize for not giving you a complete answer, but I'll just say that it's a good question. Thank you for submitting it! If you want to talk more offline, we can, but I would say that you're going to really love the detailed conversation that we'll have on attestation later this year. I think that's good enough. Was there anything else I wanted to add to this? I think I wanted to say that when we talk about 3rd-party signers, we didn't talk very much about who can be a 3rd-party signer and the FCC was sort of peppering around who can be a 3rd-party signer. We talked offline preparing for the comments and for what we call a transit provider and an intermediate provider being also a signing service provider, because that does exist. There are intermediate providers who provide signing services. Obviously, we've made it clear that we would think that the intermediate provider can sign on behalf of an originating service provider. The service provider with a direct authenticated relationship with a communicating-end entity customer but we feel like that has to be with that service provider, the communicating identity. It can't be the intermediate service provider's certificate. A transit provider in the role of transit, should sign with a C-level attestation because they don't have a direct, authenticated relationship and they don't have information about the right to use the telephone number. Now we're getting into the station we said we wouldn't. Sounds like you have a comment, so go ahead and bring it!
Brett Nemeroff: This is something that I think people frequently get wrong. I'm hoping that in the next year or so, companies start understanding a little bit better about what their rights and responsibilities are in this ecosystem. It's hard to get it right. It's confusing, it's complicated. These Report and Orders can be hundreds of pages long, and a lot of businesses where telecom is not their primary focus will find themselves being deemed service providers and needing to fulfill the responsibilities of the SBC (Session Border Controller). I had been kind of thinking, what's a litmus test to find out, are you doing it right or do you need to do something different? Now, the document that Pierce was referring to goes into more detail than the thoughts that I have on top of my head here, but ATIS standards say that you need to have a direct, authenticated relationship. Interestingly enough, the ATIS standards also say that you do attestation by local policy. I'm not going to get into that a whole lot right now, but it's important to understand that there are already conflicting ideas there. When it comes to a direct, authenticated relationship, I think that this was a great way that ATIS ended up saying this, when I think about an authenticated relationship, I think about a switch provider, a service provider that is authenticating individual calls, either on a source IP base or maybe on a username password base. They have some authenticated way of knowing that this particular call or these groups of calls are this specific customer. If you are that entity that knows those customers, you should have a responsibility to do KYC on each individual one of those customers, and you should have a responsibility to sign those calls before you send them out. Now, just saying it like that puts a lot of people into a box of needing to do things that they probably aren't doing right now. So that's my litmus test. When you take a look at a transit provider, they might be taking traffic from one of those entities. Can that transit provider, when they see call by call, tell it's Customer A versus Customer B versus Customer C? They can't tell the difference between those individual customers in that way. The only way that they can provide attestation is a C on that call with their certificate. Right? The whole point here is about what kind of metadata you are passing along with the call. What are you telling the terminating service provider about your level of confidence about the ownership of this number? I'm trying really hard not to get into the attestation discussion, so I'm going to leave it with that and let us move on to our next point.
Pierce Gorman: No, you did great. I'm glad you brought that up. It is one of the things that we talked about, so you're not hurting a thing. I was also going to add that I feel like you're channeling Sarah Delphey when you mentioned the KYC stuff and say it's really important, it's critical. I agree with you. It's 100% correct. The protocols do what the protocols do, but if you don't do something outside of those protocols to make sure that the information that's in there... It's the old joke about garbage in, garbage out, right? KYC is critical, so I'm glad you mentioned it. We're up to paragraph 100. I'm going to say we're probably not going to make it all the way through, so people will have to let us know whether they want to hear more about this, our comments on the Further Notice of Proposed Rulemaking. Continued discussion on how a 3rd party changes information sharing and privacy concerns. This is the paragraph where the FCC asked about customer proprietary network information and privacy concerns and some other things, which are good questions. The joke I wrote for myself to say here is that CPNI (Customer Proprietary Network Information) is thin ice on top of quicksand. So, I don't feel comfortable making any comments on it at this time depending upon what I say, it could cause a lot of problems for how things would get done. It's a subject that's worth thinking through before you say anything and I haven't thought it through enough. We had a really good conversation offline, but I don't feel comfortable talking about it here. I think there was a better question, wasn't there, Brett, that came next?
Brett Nemeroff: Yes, there was a better question later in the same paragraph and it was specifically, "Should any explicit authorization of 3rd-party authentication practices be conditioned upon providers ensuring that 3rd parties have the information needed to apply A or B-level attestations consistent with ATIS standards?" And this kind of goes back to what I was saying a second ago. Are the ATIS standards consistent? They do allow for both local policy and descriptive policy. I personally think that it should not be based on local policy. The descriptive policy is good and in fact, it should be more descriptive, if anything else. A direct, authenticated relationship. This means something from a technical perspective, and it's something that we can prove, it's something we could demonstrate, and it's something that we can automate in terms of the course of an actual call getting set up. The other part of it, which is a little bit more sloppy and harder to prove, is a right to use. Very frequently we do these with LOAs (Letters of Authorization); showing the right to use is certainly something that we can do. In addition, and a whole other podcast episode for us, is talking about additional ways to transmit right-to-use information within the entire PSTN.
Pierce Gorman: I 100% agree. That leads back to the requirement to know the provenance of the telephone number, and the right to use the telephone number is a key input to what kind of attestation you're supposed to be able to provide. If you follow the guidelines that are prescriptive as compared to saying it's a matter of local policy, to the originating service provider it can be very hard to know the provenance of the telephone number. What's the source of the telephone number? Do you have letters of authorization associated with the telephone number? Is it practical to even try to obtain that information and manage it? Do you maybe just fall back on, "Well, Fidelity is our customer, and they're a big important customer, so everything we get, we're just going to provide them an A-level attestation." We're kind of giving you teasers here, but there is an awful lot to unpack there in talking about attestation, so we'll leave that for that podcast. We're on to paragraph 101. We're making progress, and we only have a minute left. So, I think we're going to have to not go over the rest. People will have to let us know what you think, how you feel, if you want to hear more, if you want to see a blog, want to ask us questions. Join us for our next live episode of Tuesday Talks on Tuesday, June 20th. When I'll be joined by Numeracle's Chief Product Officer, Anis Jaffer. Identity will once again be taking center stage on our mission to return trust to communications. So, be sure to register to join us live. We hope to see you there!
Brett Nemeroff: Thanks, Pierce.
Pierce Gorman: Thank you, Brett.
