On 6/30/21 12:17 PM, Paul Timmins wrote:
On 6/30/21 2:56 PM, Michael Thomas wrote:
Just because you can know (fsvo "know") that a call is allowed to
assert a number doesn't change anything unless other actions are
taken. With DKIM which is far simpler than STIR it would require
reputation systems that don't seem to have been deployed, submission
auth which thankfully was deployed, policy enforcement (ie ADSP)
which is not deployed, and user indicators which are sporadically
deployed.
In any indication, the carrier closest to the originator is signing
the call metadata with their digital certificate. While this won't
mean much to the active user, for those tracking down robocalls, this
is the holy grail - finding the carrier who is letting the calls into
the network and being able to reach out to them to stop the
abusive/illegal traffic.
As I said, STIR solved the wrong problem. I know domains as a user. I
have no clue about e.164 address ranges. Also: this is 2021 and e.164
address need to go the way of the dodo.
From an automated standpoint, I really don't care about whether a phone
number is authentic, I care about the domain that onramped it so I can
theoretically punish it. It's the people who are allowing the spoofing
that is the real problem which directly analogous to email open relays.
Also: reputation is nice in theory but I am dubious that it is deployed
in reality. Given the entire ARC farce which was driven by Google -- who
owns gmail -- to supposedly "solve" the mailing list traversal problem
but boils down to a reputation system, that strongly suggests that they
don't have one either. I'm not sure why we should be optimistic about
that for STIR which solves for a much harder problem which is inherently
not entirely secure given SS7 gateways.
That it might say we've taken the time to verify the end user is who
they say they are is just icing on the cake. The goal is to make the
calls accountable to someone, which despite the patchwork of systems
in the US that might prevent the signature from coming through, can
help a lot since the biggest wholesalers have implemented it
(Inteliquent and Lumen among many others)
The other big deal is that now all carriers are actually expected to
police their network for spoofed callers who are exhibiting
robocalling behavior. This is a big deal! For the first time, carriers
are going to be held responsible for proactively finding the abuse,
and showing what their plans are to do such a thing, and sharing
information with each other (via the FCC) who can be contacted to
chase down robocall traffic if another carrier sees it.
I'm not trying to say that it's not a good thing to have authentication,
but as implemented by STIR it's ridiculously more complex than it needed
to be had they chosen the right problem to solve which is to know the
domain that is onramping the call. This could have been trivially rolled
out a decade ago and I even experimented DKIM signing SIP message about
15 years ago.
It's never been entirely clear whether DKIM was the impetus for cleaning
up open relays. I'd like to think it was, but the more likely
explanation was that it was in the water at the time. The FCC could have
at any time just clamped down on that from a regulatory standpoint
without going to all of the rigamarole of STIR. Email doesn't have a
similar regulatory body to lean on so we had to take it into our own hands.
Given the giant security holes caused by solving the wrong problem
(ie trying to authenticate the e.164 address rather than the
originating domain) it's just going to push spammers to exploit those
holes. It's very much to be seen whether victory can be declared, IMO.
Fortunately, positive identification of the caller isn't the intent.
Preventing people from pretending to be the IRS is the intent.
e.164 addresses don't allow me to know if something is from the IRS.
irs.gov does. Also, papers have shown that UI identification is a net
positive which is a shame given how sporadically they are done and how
inconsistent the UI's are. If they were widespread it would probably
much better.
Mike
