Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls

Federal Communications Commission Chairman Ajit Pai today proposed a major step forward to further the FCC’s efforts to protect consumers against
spoofed robocalls: new rules requiring implementation of caller ID authentication using socalled “STIR/SHAKEN” technological standards. STIR/SHAKEN enables phone companies to verify the accuracy of caller ID information that is transmitted with a call. Industry-wide
implementation would reduce the effectiveness of illegal spoofing, allow law enforcement to identify bad actors more easily, and help phone companies identify calls with illegally spoofed caller ID information before those calls reach their subscribers.

The FCC will vote on these new rules during its Open Meeting on March 31.

In my opinion, STIR/SHAKEN is solving the wrong problem. e.164 addresses are dinosaurs and pretty irrelevant for identity. Cryptographic protection of the From: address in SIP would be a lot more sane because we already know how to do that. Since it's basically an all SIP world these days, we should just retire e.164'isms and move on.


Good luck supporting it on legacy TDM switches. I know work-around exist, but nobody wants to invest any money in modifying legacy gear.

Why don't they just ask the phone companies who are billing these
robocallers who they are and we can arrest them.


And if your urge is to jump on your keyboard and deny the telcos know
exactly who they are please ask yourself if you really know or are you
just defending some world view based on nothing really other than
you're uncomfortable with such treachery.

Last time we went around this several weeks ago people who actually
truly have worked in the telco biz on exactly this sort of thing
responded yes, exactly, the telcos know just who they are and do
indeed bill them for those robocalls.



I have always maintained that if my phone number were one of those
"premium" numbers (1-976 -- maybe I am dating myself but you know what
I mean -- where calls to it were billed at $5/min), I am sure that my
telco (the one providing me the premium number on my the phone line
that runs into my location) would always know exactly who to send the
bill to for every call that called my number, including robocallers[1].

So, if my telco can bill the callers for those premium calls, they
surely know who they are, or at least know where they are sending the
bill and getting payment from.

But who are we kidding? The telcos have been making money hand over
fist with robocalls and are not really all that motivated to dry up
that revenue stream. Regulation (as much as I hate it in general) is
the only solution.

Making the allowing of robocalls more expensive than preventing them is
the only solution. Whether that is through fines as a result of
regulation or otherwise.


[1] I remember hearing a story of a guy, in the UK I think, that got a
premium number and then printed business cards with it on it and then
ran around a trade show handing out the cards. That seems kind of
shady, but the idea of getting a premium number and having it
criminally sold to telemarketers, phishers and scammers makes me giddy.

You are mistaken, billing is very hard.
Telcos show this regularly.

On the contrary: billing is easy. Getting it right is hard.

You are technically correct, the best kind of correct.

Seriously though, a bunch of the conversation about shaken/stir and
various problems with spam callers reveals:
  "telcos don't care (for any reason you can imagine)"
  "gov't mandates aren't really going to help"
  "people care as recipients of these calls, but really there are
options for them as well to not get the calls (or not answer them)"

I like that Mr Thomas's answer: "Why can't we just cryptpgraphically
sign the caller's ANI and use that as a method to ID real callers we
care about?"
since that was my suggestion to the stir folk in their very first
meeting... "what about ebony phones!" said the lawyer from

Well to be clear, i think it's high time to just ignore the old pstn identity stuff altogether and just use the SIP From.


that too was my message 12 yrs ago... I thought:
  1) cell phones and anything like a cell phone (sip things) can 'just do this'
  2) anything not in category1 could have the data stamped by the
thing electrically connected to it (in the CO)

really, this isn't TOO hard, and it enables a new business in the
'directory of certs' business...
and clear info to the endpoints about the caller:
  "This number says 1900-foo-bart, but that's not matching the Cert I
have for FooBart services? fake-call!"

lots of good options there, little interest from 'telco lawyer troll'
in the room. #ebonyphone!

Has encryption ever solved scams/fraud/spam?

Extended Validation SSL Certificates - Just pay a Certificate Authority more money

DKIM signed email - Just pay a mail provider more money to blast email

SWIFT encrypted payments - Just find the weakest bank somewhere in the world

it takes an ecosystem, authentication being one tool. before we did dkim practically nobody was using smtp auth. i would like to think that the accountability end of dkim's "blame us" had some effect, but it was probably in the water at the time.


In article <nycvar.OFS.7.77.840.2003071446060.17953@cnex.qbaryna.pbz> you write:

Has encryption ever solved scams/fraud/spam?

No, but signatures have helped so you can more easily identify known
friends and concentrate the analysis on the rest.

DKIM signed email - Just pay a mail provider more money to blast email

This must be some DKIM other than the one the IETF standardized and
every large mail provider uses to manage mail streams. There's no
CA's, you publish your own verification key in your DNS, and it costs
nothing beyond the software upgrades to use.


Most DNS registers avoid verifying customer information as long as the payment clears (for a short time). DKIM (and DNSSEC) is built on top of trusting tokens from third-parties which disclaim all liability.

Cryptography is not magic pixie dust. It won't create trust between unknown parties. Cryptography works between parties already known to each other to verify existing trust. Phone companies and advertisers have already demonstrated they can't be trusted to act as third-party introducers. They are more than willing to sell-out that trust to the highest bidder.

The reality is my phone already knows the numbers of my circle of friends and loved ones. Overseas call centers randomly generating phone numbers aren't matching the subset of phone numbers that cause my phone to ring.
When the scammers start matching social media circles and phone numbers, then I'll need something new.

Eventually we'll have STE/STU-equivalent end-to-end verification on our smartphones.

That's not how DKIM works at all. Even a little bit.


Most DNS registers avoid verifying customer information as long as the payment clears (for a short time). DKIM (and DNSSEC) is built on top of trusting tokens from third-parties which disclaim all liability.

Right. The only promise that DKIM makes is that if you have a stream of mail signed by the same domain, you can praise or blame the same entity for it. It's a handle that recipient systems can use to build a reputation system, not a whitelist. DKIM has worked this way since 2006, the documentation is entirely clear that's what it does, and I'm kind of surprised you haven't gotten the memo.

Phone companies and advertisers have already demonstrated they can't be trusted to act as third-party introducers.

No kidding. I've talked to people at big telcos who are in the middle of STIR/SHAKEN and they tell me they plan to use it pretty much the same way that mail providers use DKIM. Some senders will have a good reputation and their calls will be delivered, some won't, and not so much. As with mail, it also provides a handle to push back on people sending unwanted junk.

Eventually we'll have STE/STU-equivalent end-to-end verification on our smartphones.

That's known not to work for e-mail spam, so I can't imagine why anyone would expect it to work for phone calls.

John Levine,, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail.

Totally agree with you there, I run a mail server/monitoring server on OVH. With TLSA records, DKIM, and MTA-STS, I’ll still see junk filters on it if I accidentally email someone other than myself. Yes my space has been SWIP’d and I send so low email volume so it’s reputation would be neutral at best which very much justifies the spam filters due to OVH’s reputation. Somehow I don’t think SHAKEN/STIR would be any different.

I wonder how far this would go on VoIP transit. I purchase from for my house, which purchases from some other providers, which probably aggregates to others. It doesn’t seem like this is quite as easy as looking up a whois from ARIN.

This is similar to the BCP38 problem of spoofed packets making their way onto the internet. The recipient has no way of knowing which packets are spoofed, but with (sampled) netflow/sflow, the origin of a flood of traffic can be traced, even if spoofed. And, once traced, it can be filtered. The fact transit providers don’t do this traceback and filtering today is simply because it would cost money, and they make more money carrying the traffic (and also the amplified DDoS traffic it causes). The only solution is to make it more expensive to facilitate criminal activity than to prevent it. I think we’re seeing the beginnings of this in the telco industry, and I hope it carries over to the internet.

In the robocall case, there is something the end user can do to fight the abuse: answer every call, and keep them on the line as long as possible. They are paying for connected calls, for the connection duration, and for the humans to scam people. If everyone tarpitted them, the business model would fail.


Send them all to Lenny!

If Apple and Google implemented a “Forward to Lenny” option in their OSes, robo calls would drop dramatically. :slight_smile:

Telcos have been described as vast and efficient billing systems with
some minor voice service functions attached.