[stir] Re: [art] Re: For those of you who follow this kind of stuff.

[Pierce Gorman <[e-mail]>]

I love a good e-mail thread.  Beats the daylights out of the foo-fer-rah going on in the IETF.ORG distribution.  Oy.

I think tying “identity” to telephone numbers has always been a mistake.  It is an unhelpful abstraction.  TNs are fantastically valuable for routing phone calls to anyone on the planet, but suck as a source of identity.  Large enterprises have 10s or even 100s of thousands of telephone numbers and multiple service providers, and trying to encode that in certificate constraints and using the right certificate for the right number is almost a complete waste of time.

The WWW operates perfectly fine on domain-validated identity in certs.  It is trivial and cheap to get those certs.  We should make it the same way for callers who wish to identify themselves, and no TNs in the cert are needed.

The benefit to them is analytics providers at the termination of the call can identify their calls with very low effort, and protect those calls from accidental mislabeling or call blocking.  If those calls deserve labeling and blocking, that can happen too, and there is a clear indicator of who that is applied to without having to get their originating service provider(s) involved either to identity them or to issue them certs with TNs.

Organizations, agencies, enterprises will, eventually, understand that they want and must have a vetted digital identity that they control to authenticate digital transactions of every sort.  Take a look at the eIDAS 2.0 law passed by the European Commission last year affecting more than 400 million EU citizens and organizations.  Just like STIR/SHAKEN created the foundation for authenticated call signaling, the eIDAS laws and the EU Digital Identity (EUDI) Wallet program are going to transform digital communications of every sort, not just driver’s licenses, e-Passports, and age verification for gambling and getting into bars.

We in the telecom industry should be paying attention to and leveraging how digital identity was established decades ago for the World Wide Web, and understanding and using how it is evolving globally, especially in the EU.

Kind regards,

Pierce



CONFIDENTIAL
From: Roman Shpount <[e-mail]>
Sent: Wednesday, October 8, 2025 10:44 AM
To: Pierce Gorman <[e-mail]>
Cc: Chris Wendt <[e-mail]>; Brett Nemeroff <[e-mail]>; Richard Shockey <[e-mail]>; IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] Re: [art] Re: For those of you who follow this kind of stuff.

You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Pierce,

I never called STIR/SHAKEN a success.

If you look at it as a mechanism to reduce the number of robocalls, it failed completely. It can easily be used to combat robocalls, but I don't know if anyone implementing it actually cares about it. It was always more about going through the motions, regulatory compliance, and possible deniability.

If you look at it from the point of view of ease of deployment, it was horribly designed with complete disregard for how current carrier networks operate. It is a networking, implementation, and administrative nightmare. I would not blame this group for creating a sub-par standard, but it was driven more by political necessity than by reasonable design considerations.

If you consider it in terms of providing helpful information in combating robocalls, it has clear utility. The most useful information is the information about the certificate used by the signer. It can easily be used to limit valid signers for phone numbers, preventing call spoofing. CNAM can be used for this with minimal effort. Adding a campaign registry to register high-volume originating numbers will provide a way for legitimate call centers to whitelist their calls and for terminating carriers to throttle the traffic. Snowshoeing would still be an issue, but I am unsure how to address this without conducting a content analysis.

I think the primary reason for the Rich Call Data push is not to combat robocalls or to present end users with the identity of the remote party. It is a financial incentive for the wireless carriers, which can charge for presenting Rich Call Data from the call originator, versus paying for a CNAM database dip. Wireless carriers attempted to charge their customers for displaying the caller's identity, but were unsuccessful in selling this feature. So, they pushed for a new network protocol where they can charge the call originator for this feature. In my case, I can send a SIP call with call data directly to a wireless carrier. The wireless carrier deliberately strips the caller's identity from this call. They are asking for money (not the caller KYC) to keep it. So, this is not about users. It is about revenue.

I believe a lot of people in this group are driven by their best intentions, but it ends up in an administrative quagmire and telecom revenue fiefdom anyway.

Best regards,
_____________
Roman Shpount


On Wed, Oct 8, 2025 at 9:53 AM Pierce Gorman <[e-mail]<mailto:[e-mail]>> wrote:
Well, this is a lively STIR discussion!

Dear Roman,

I will offer my view as the network design engineer that led the implementation of STIR/SHAKEN at Sprint, and former active participant of the FCC’s Call Authentication Trust Anchor working groups of the North American Numbering Council.  The fundamental reason STIR/SHAKEN exists is because unethical, immoral, or inept service providers are admitting illegal robocalls into the PSTN.  RCD, alone, will not change that.

During the first CATA wg I warned Henning Schulzrinne when he was CTO of the FCC that the TRACED Act and STIR/SHAKEN would not be successful in bringing about a material decline in illegal robocalls unless the US could accomplish “critical mass” of signing and verification.

I didn’t give a specific metric for critical mass in the context of STIR/SHAKEN but suggested something north of 90% of all call originations needed to be successfully signed and verified.  Even then success presumed analytics meaningfully identified bad calls, traceback based on analytics determinations was automated, and that the FCC Enforcement Bureau and/or other law enforcement agencies used the information to act swiftly and decisively.

Obviously, that has not happened, and I question whether it ever can.  I believe it is impractical to make significant headway against illegal robocalling using cryptography and punitive measures alone.

STIR/SHAKEN as conceived and implemented based on legislative and regulatory mandates is a costly and so far, failed, experiment.

All that said, the TRACED Act and STIR/SHAKEN proved call authentication in the PSTN can be successfully accomplished, at scale.  That is very good, however, the misses still are:

1. We should have started with an Out-Of-Band (OOB) approach, possibly not even based on SIP, so that we could avoid the problems caused by transit networking and heterogenous inband call paths.

2. We should have focused on the sources of illegal robocalls, not ALL calls.  i.e., we should have focused our efforts on caller identification from call centers, as well as service providers (although the definition of “service provider” has proved damnably difficult.  Nobody, including and especially the FCC, knows how many VoIP call originators exist or how many originators aren’t even aware they would be considered a “service provider”).

3. Caller identification of non-service provider organizations should be done by professional KYC vetters who cryptographically attest as to the identity of the caller which is what iconective does when issuing an SPC token to a registered SP.  This reduces the possibility of collusion between service providers and their enterprise customers, and reduces the field of vetters that need to be accredited/authorized and held accountable by analytics, traceback, etc.

4. Caller identification schema need to recognize and accommodate the layered identities of modern telecommunications.  Few companies operate their own call center, but instead outsource the work to call center providers.  Digital identity and trust attribute (e.g., licensed? Insured?) credentials can expose the layers of identities and authorizations.  And, privacy-preserving proofs are possible where needed.

5. We should have lowered the barrier (as you also recognize) to permit callers (mostly call centers, but also enterprise mobiles, etc.) to register and access STI certificates attesting to their domain-verified identity (as a minimum).  Self-registered callers’ calls could be signed with RCD, not for the purpose of branded calling, but for the purpose of voluntarily identifying themselves as a measure to assist analytics providers more than anything to protect those callers’ calls from accidental labeling or blocking.  Further, with the identity of the caller (at least, and their service provider or providers, plural), robocall mitigation takes on a whole new level of capability.

Respectfully,

Pierce Gorman



CONFIDENTIAL
From: Chris Wendt <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, October 8, 2025 1:44 AM
To: Roman Shpount <[e-mail]<mailto:[e-mail]>>
Cc: Brett Nemeroff <[e-mail]<mailto:[e-mail]>>; Richard Shockey <[e-mail]<mailto:[e-mail]>>; IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>
Subject: [stir] Re: [art] Re: For those of you who follow this kind of stuff.

Removing art mailing list and only keeping stir mailing list on cc.  Let’s keep this on stir list only to avoid spamming art participants.

RCD, I’m a fan, i guess the party is really kicking in to gear.

-Chris

On Oct 8, 2025, at 12:19 AM, Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:

Brett,

FCC was very deliberate in not specifying the KYC requirements. This being said, all carriers introducing traffic to the US phone network should have a KYC policy described in the RMD database. Carriers that did not provide an adequate policy have been removed from the RMD database and are no longer permitted to originate traffic. Additionally, if, as a carrier, I can set the A-level attestation for the call based on my KYC policy, I should be able to specify the Rich Call Data accordingly, especially if this is required when A-level attestation is provided.

I have a strong feeling that certain providers care more about creating new sources of revenue for themselves through regulatory arbitrage than about creating a healthy infrastructure to prevent robocalls. A glaring example is iConnectiv providing SPC tokens, but not the signing certificates, which artificially creates business for specialized certificate authorities. Ironically, this business opportunity is so small and labour-intensive that no one actually wants to do it, trying to shepherd carriers towards the hosted signing solution.

To summarize, if, as a carrier, I am entrusted with an SPC token, I should be trusted to provide the Rich Call Data. If I am not trusted to provide Rich Call Data into the network, I should not be introducing any traffic into it. If the FCC mandates Rich Call Data, it should mandate that carriers accept it without creating walled gardens, with each carrier charging a fee to actually accept the data.

Finally, if we intend to mandate the transmission of personally identifiable data with every call, we need to update SIP with a scalable and secure transport protocol. Most current carrier SIP implementations still use UDP. SIP-over-TLS suffers from head-of-the-line congestion issues. SIP is in dire need of a secure datagram-based protocol, such as QUIC. I am surprised that no one from the STIR group brought this to the SIPCore, so that a more scalable and secure protocol capable of carrying Rich Call Data could be standardized.

Best Regards,
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 8:42 PM Brett Nemeroff <[e-mail]<mailto:[e-mail]>> wrote:
Hello Roman,

In my opinion, US Carriers are unlikely to accept vanilla RCD data because of the lack of defined KYC.  RCD is a very good vehicle for delivering the RCD, but it depends upon implicit trust of the originating service provider. “Vanilla” RCD offered like this to terminating service providers gives no assurance to the terminating service provider that the originator performed any specific KYC.

CTIA’s BCID is based on RCD but details an ecosystem with specific KYC requirements. Participating in this ecosystem will allow for the delivery and native presentation of RCD.

It’s worth noting that without a defined ecosystem for RCD such as BCID, RCD provides little (trust)  benefit over traditional CNAM other than the fingerprints of the originating service provider for enforcement purposes.

-Brett




Brett Nemeroff
VP of Engineering - Voice
[e-mail]<mailto:%7BE-mail%7D> | 1-512-203-3884
<C2_signature_logo_ccb8cfe8-4171-4801-978c-931782d067de.png><https://www.numeracle.com/>


Empowering Calls with
Identity Management<https://www.numeracle.com/insights/entity-identity-management-to-empower-your-calls>


CONFIDENTIAL
From: Roman Shpount <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 7, 2025 at 7:24 PM
To: Richard Shockey <[e-mail]<mailto:[e-mail]>>
Cc: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [stir] Re: [art] Re: For those of you who follow this kind of stuff.
You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
In my day job, I see a lot of robocalls coming through the LEC local switches as TDM, as local re-origination with spoofed ANI.

I would also love to sign Rich Call Data with my SPC token and not have wireless carriers discard this data. If I provide the information about my customer, I am unsure why I need to pay someone else to sign this information.
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 8:11 PM Richard Shockey <[e-mail]<mailto:[e-mail]>> wrote:

It wont . You mean the legacy TDM/SS7 crap…this is the beginning of mandating all SIP in the US realtime US voice network as the British have done.

I would not want to own a Tandem Access network.

The US industry is pretty clear on this.  You only need to read the FCC 17-97 docket at the FCC ECFS website to understand where the players actually are.

This again is my day job.


Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us<http://www.shockey.us/>
www.sipforum.org<http://www.sipforum.org/>
richard<at>shockey.us<http://shockey.us/>
Skype-Linkedin-Facebook –Twitter  rshockey101
PSTN [phone]


From: Roman Shpount <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 7, 2025 at 7:37 PM
To: Richard Shockey <[e-mail]<mailto:[e-mail]>>
Cc: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Subject: [art] Re: [stir] For those of you who follow this kind of stuff.

How would this work with PSTN links?
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 6:59 PM Richard Shockey <[e-mail]<mailto:[e-mail]>> wrote:

The United States government is going to mandate Rich Call Data in the network.

https://docs.fcc.gov/public/attachments/DOC-415059A1.pdf


Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us<http://www.shockey.us/> <http://www.shockey.us<http://www.shockey.us/>>
www.sipforum.org<http://www.sipforum.org/>

richard<at>shockey.us<http://shockey.us/>
Skype-Linkedin-Facebook –Twitter rshockey101
PSTN [phone]






_______________________________________________
stir mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________ art mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
art mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>