SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

Mailman List Mirror (Read Only)
1

I don't think SHAKEN/STIR really addresses the root problems with spoofing phone numbers, anymore than any of the BGP proposals for spoofing IP addresses.

Nevertheless, the FCC wants to be seen as doing something. So Chairman Pai is having a summit to show all the progress.

On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit focused on the industry�s implementation of SHAKEN/STIR, a caller ID authentication framework to combat illegal robocalls and caller ID spoofing. Chairman Pai expects major voice service providers to deploy the SHAKEN/STIR framework this year. The summit will showcase the progress that major providers have made toward reaching that goal and provide an opportunity to identify any challenges to implementation and how best to overcome them.

https://www.fcc.gov/SHAKENSTIRSummit

Time: Unknown, the public announcement did not include the time. Usually these summits start around 9am EDT.
Location: Commission Meeting Room at FCC Headquarters, 445 12th Street, S.W. Washington, D.C. 20554.

It will also be streamed at the FCC�s web page at www.fcc.gov/live.

2

Well, y'know, it's been 10 years since I originated calls to LD carriers.

But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls
that weren't for 10D calling numbers *they had assigned us* (and hence I
had to work that out with them to prove that *someone* had)...

nd the other 2 didn't give a crap. I could send them anything -- even calls
with CNID that wasn't a valid NANP address (4th digit 1, frex).

Since nearly all of this is being originated over PRIs to LD carriers, right;
maybe if the FCC just threatened the LD carriers who do not do the calling
number legitimacy enforcement the regs (I think) already require them to do...?

Cheers,
-- jra

3

Summary:

SHAKEN/STIR does nothing but sign a call by a carrier that can be verified
by another carrier that they signed it. It does nothing to stem Robocalls.

Discussion:

All SHAKEN/STIR does is have the originating carrier of a call to
cryptographically attest, to some degree, that the call originated from
their network.

One example given was that SHAKEN/STIR can verify that it is really the IRS
calling.

But that would require knowledge of which carrier currently serves the IRS,
and that the IRS use that same carrier for both inbound AND outbound
calling, and that the carrier publishes some record that it is the carrier
of record for the given phone number. THIS DOES NOT EXIST in SHAKEN/STIR.

If Carrier A is taking calls from a spammer and implements SHAKEN/STIR, and
their termination Carrier B have also implemented SHAKEN/STIR verification
and trusted Carrier A's certificate, all that occurs is that Carrier A says
"this call is trustworthy" and Carrier B verifies that Carrier A said so
and completes the call.

Carrier A can lie all they want, as they do now, providing a false "Full
Attestation" that the "service provider has authenticated the calling party
and they are authorized to use the calling number." But there's no proof
that they are telling the truth, and no way for any other intermediate
carrier to verify anything other than the originating carrier.

Now if Carrier B decides not to trust Carrier A anymore, they can stop
trusting their cert and drop calls. Which Carrier B can do today by
terminating the relationship with Carrier A.

I still don't see how this will stop CallerID spoofing or Robocalls.
Carrier B can block Carrier A at anytime. Carrier A can attest that any
call originating from it is authorized to use that number. Plus then
there's a ton of intermediates that aren't even addressed here. Do all the
Intermediates also need to implement SHAKEN/STIR such that the SIP Identity
header is passed onto the next leg? If the intermediate drops the header,
does the call fail?

And spammers already use real, leased phone numbers for Robocalls. We
had a client come to us who wanted 5,000 new/different and not recycled
phone numbers across the US each month. When prompted about how they'd be
used, they just needed inbound calls and SMS messages routed to their
switch hosted at a cloud provider, outbound calls would be made through
another carrier.

With SHAKEN/STIR, these calls would show up as "Authenticated" as the
client could tell their Carrier C that these 5,000 phone numbers were
theirs, and Carrier C could do a "Full Attestation" SIP Identity header and
the spam calls would show up as "Verified." But still Robocalls, just
Verified Robocalls.

We declined to do business with this client.

In summary, SHAKEN/STIR seems to do nothing but be some extra technical
work.

Please correct me if I'm missing a key piece of this.

I'm in DC, I'm going to try to attend this summit.

https://transnexus.com/whitepapers/understanding-stir-shaken/

Beckman

4

when we did DKIM back in the day, almost nobody was requiring SMTP auth which meant the providers could say "blame me" via the DKIM signature, but couldn't really take much action since they didn't know who has doing it. we sort of took a leap of faith that that would happen. nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i have no idea whether DKIM was in any way a motivating factor, but it did happen in the meantime.

i know the parallels here are not exact (is it really PRI's that are the source of most of the spam?) , but it's maybe a little premature to completely write off the providers for doing the Right Thing. putting the "blame me" badge on might give them some incentive to clean up their act. as with email spam, there is no silver bullet of course.

fwiw, the stir/shaken problem statement is a good read.

https://datatracker.ietf.org/doc/rfc7340/

Mike

5

when we did DKIM back in the day, almost nobody was requiring SMTP
auth which meant the providers could say "blame me" via the DKIM
signature, >but couldn't really take much action since they didn't
know who has doing it.

This is because DKIM was a solution to a problem that did not exist. You always know the identity of the MTA sending you a message, there never was a need for DKIM. It was a solution to a problem that does not and did not nor will ever exist.

we sort of took a leap of faith that that would happen.
nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i
have no idea whether DKIM was in any way a motivating factor, but it
did happen in the meantime.

This happened long long long before DKIM was even a wet spot on the sheets.

i know the parallels here are not exact (is it really PRI's that are
the source of most of the spam?) , but it's maybe a little premature to
completely write off the providers for doing the Right Thing. putting
the "blame me" badge on might give them some incentive to clean up
their act. as with email spam, there is no silver bullet of course.

The solution is to disallow spoofing. If the "pretty overlay information" does not equal the "billing information" then do not permit the call to be made. Easy Peasy. However, this will interfere with the carriers ability to make money since the ability to make money depends on being in cahoots with the fraudsters. Making it such that the Directors and Officers those carriers in cahoots suffer the death penalty (or life imprisonment) will solve the problem in an afternoon, but it will not happen because the cahooteers' (those Directors and Officers) own the slimy politicians needed to implement the cure.

fwiw, the stir/shaken problem statement is a good read.

RFC 7340 - Secure Telephone Identity Problem Statement and Requirements

Not a bad work of complete fiction!

Of course, the "root cause" can be found at the very beginning of the thing where it is pointed out that there are reasons for providing false data, and that since "the other guy" allows the presentation of false data, we should too otherwise we will go out of business. Once this "root cause" is accepted, then the inevitable ensues ...

6

::eyeroll:: pray tell, how do you "always" know the identity of the MTA sending you a message?

Mike

7

Wow!

You must not know much about networking or programming if you do not know how to ask the OS to tell you the address/port associated with the "other end" of a TCP connection. Obviously you know who is sending the message since they are in bidirectional communication with you at the time you are receiving the message, and you need to know where to send the "carry on James" prompts to get them to send more data...

Therefore you always know who submitted a message.

8

It's more subtle than that - you always know the "identity" of the purported
MTA, because you know their IP address. Whether "purported" is the same as
"legitimate" or "authorized" is a whole different kettle of fish....

Remember - port 25 is widely blocked precisely because there were always a
plenty supply of MTAs whose identity you knew, sending you spam from consumer
living rooms....

9

Jon Callas, Eric Allman, the IETF security geek contingent and even me disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with you. Trillions of signed messages disagree with you. Steve Bellovin probably disagrees with you too since you seem to be under the illusion that a reverse DNS lookup tells you anything useful.

::eyeroll::

Mike

10

Like I said, what DKIM brought is the ability to "blame me". knowing the IP address doesn't give you that in any useful way. Recall that trust is mainly a social construct, not a technical one. Bruce Schneier has written about that endlessly.

Mike

11

You are the only person who has mentioned reverse DNS lookups.

However, it is true that you do in fact need to already know the identity of the sending MTA/MSA before you can do a "reverse DNS lookup". What does this have to do with the price of tea in China?

And what value do you think a reverse DNS lookup adds to the identity information you already (obviously) have?

12

I'm only trying to guess what enlightens your misinformed world.

Mike

13

DKIM brought nothing of any value since it cannot be used to refuse messages or abort before entering the DATA phase of the SMTP conversation. You are, no matter what, committing resources to receiving the message and accepting responsibility for its delivery. All you can do is fart about AFTER THE FACT, after it is already too late to reject the message.

Presently 99.999999% of the SPAM that gets through to me is DKIM signed, yet it is still spam. In fact, that DKIM signature provides absolutely nothing of value whatsoever, except to validate that the SPAM was unmolested between the sending MTA and me (which is unlikely anyway, and even more unlikely since the transport is almost always over a TLS channel which prevents tampering between the sending MTA and my MTA anyway).

Like I said, DKIM does nothing of value and is directed to solve a problem that does not, never has, and never will, exist in the real world.

Contrast this with SPF which does do something of value. It enables the dropping of the session BEFORE the DATA phase if the envelope-from domain is not on the list of authorized MTA to be sending messages for that domain. The only real problem with it is the allowance of prevarication in the data.

14

You claimed that the "root problem" was not knowing who the originator was.

I claimed that you ALWAYS must know who the originator is -- they are at the other end of the connection.

You want to do a "reverse DNS lookup" for some reason.

I still do not understand how doing a "reverse DNS lookup" will help with the identity at the other end of the connection, since you already have to know that identity in order to perform a reverse DNS lookup...

15

when do we get back to stir/shaken?

16

I have claimed no such thing.

Mike

17

that would be nice. i have a lot of questions about stir/shaken. attacking a problem statement rfc seems rather bizarre and unhinged to me. it outlines a lot of the objections i had to p-asserted-identity i had way back when.

Mike

18

back on track to stir/shaken

would a service provider also need to implement this? or its for the big carriers to do ?

19

The agenda for the SHAKEN/STIR robocall summit was published today.

Time: 9:30 a.m. to 3:30 p.m.
Location: Commission Meeting Room at FCC Headquarters

It will also be live-streamed on the FCC web site.

https://www.fcc.gov/document/chairman-pai-announces-agenda-shakenstir-robocall-summit

The agenda looks like lots of happy, happy talk from industry representatives.

Unfortunately, like other third-party problems, its not about the technology. Its really about changing the incentives for all the actors involved. But the first and second-party players don't want the incentives to be changed for them.

20

This is correct. We have always known the IP address of the connecting
MTA, therefore we have always known the network it resides in, therefore
we have always known who is responsible for what transits that connection.

Worse, this (poorly) attempts to wallpaper over the problems of
compromised systems/accounts. Do recall that not long ago we learned that
EVERY Yahoo account was compromised. Anyone who thinks that Microsoft
or Google or Comcast or anyone else are doing any better is naive:
it's not a question of whether they've also suffered mass compromises,
only a question of how many and when they'll publicly admit it.

This isn't surprising. The real underlying problems here are tough and
expensive, thus it's far easire to do (nearly) meaningless feel-good work,
declare the problems solved, and engage in a round of self-congratulation.
It *appears*, and that's a preliminary assessment on my part, that
SHAKEN/STIR is following this same track.

---rsk