Re: [stir] STIR/SHAKEN Privacy Concerns

[Richard Shockey <[e-mail]>]

 

Beyond my previous remarks let me generally agree with Brother Peterson here in part. As someone that deals with national regulators on a near daily basis the general regulatory posture is to require more, not less transparency in call/message origin.  This is an ongoing fight to combat robocalls and now robotexts and the regulators are adamant that they can and will use any power they have to compel compliance.  In the US that has typically been authority under section 251 (e) 1 involving NANP numbering and the mandates under the US TRACED act.  Canadian and UK Communications Acts are different but their plenary authority is actually even more extensive than the US. The Dockets in the US FCC are 17-59 17-97 if you are interested.

 

The other aspect is there is a substantial move to permit Rich Call Data to be moved across the SIP signaling to formally identify who the calling party actually is. This is being driven by the desire of large enterprises to get you to actually answer the phone. Its voluntary now… we really don’t know what Apple is going to do with that data since they have plenary control over the UE/UX on their handsets.  

 

Film at 11

 

 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN [phone]

 

 

From: stir <[e-mail]> on behalf of "Peterson, Jon" <Jon.Peterson=[e-mail]>
Date: Friday, December 1, 2023 at 2:05 PM
To: Josh Brown <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [stir] STIR/SHAKEN Privacy Concerns

 

Hi Josh,

 

Best wishes for your work, this could all use more eyes on it than it has had, I’m sure.


“Our first concern lies with non-repudiability in the STIR/SHAKEN protocol. In the absence of STIR/SHAKEN, there exists no cryptographic mechanism to definitively prove the occurrence of a call - only someone observing the call as it happens knows it took place. However, with the implementation of STIR/SHAKEN, originating providers sign call metadata during the creation of the PASSporT. This means that a party possessing the signature can now convince anyone a call took place - or, more precisely, convince anyone that the originating provider said the call took place. (For context, a similar non-repudiability property of DKIM signatures for emails is now regarded by many researchers as a serious design flaw.)”

 

At a high level, I’d say there’s a disconnect between STIR as specified in the IETF and the historical use of logged PASSporTs you seem to be envisioning.

 

The baseline metadata captured by STIR (calling number, called number, and timestamp) has long been retained by a variety of parties for a variety of purposes across the global telephone network. The difference between saving PASSporTs and simply logging the metadata of calls sent or received is indeed the signature, as you say. But a PASSporT is an object that is supposed to rapidly expire after call processing, and I would not consider it a reliable historical artifact in isolation; the use case of presenting a PASSporT to “convince” someone that a call occurred at some time in the past is not in our scope, and would in fact require external corroboration for it to be reliable, for reasons I can go into if it would be helpful. If something needs to be fixed here, it is perhaps letting people know that STIR doesn’t support that use case.

 

(As an aside, email has a store-and-forward requirement that telephone calls and similar real-time communications do not. Also, because the metadata of telephone calls is decoupled from the contents of the call, I’m not sure the situation is entirely analogous to email, but that would be a longer conversation.)

 

Overall, I don’t believe just signing this metadata erodes the privacy properties of the overall telephone system (which were far from ideal to begin with). For the most part, the entities with access to PASSporTs are “observing the call” in the signaling path, and can (and probably do) log the same metadata in the absence of PASSporTs. I gather the main concern here arises from the possibility that PASSporTs might leak to entities extraneous to the call path – and so we go to…

 

“Our second concern is with the wide popularity of third-party authentication and verification services. Numerous companies offer these products as a service. Originating providers use the third party authentication service to generate signatures for their call metadata. Terminating providers use the third party verification service to verify said signatures and other information pertaining to the call metadata. Put simply, when using STIR/SHAKEN these third parties have complete access to all call metadata. This is concerning because call metadata is often very sensitive and the working group even has proposals to expand the amount of metadata included.”

 

Metadata associated with calls has long been shared by carriers with a variety of analytics providers, service bureaus, agencies, and other third parties – including for everyday functions like number portability, mobile roaming, freephone translation, caller name applications, and billing. This is not an appropriate venue to discuss laws or business agreements, but speaking broadly, regulatory environments and carrier infosec policies shape the data governance constraints under which such services operate. I don’t think it would be news to anyone in this working group that “call metadata is often very sensitive”; expressing “concern” about that does not reveal a protocol defect that needs to be rectified.

 

I would also say “complete access to all call metadata” is not required for baseline STIR, nor any or all of the proposed extensions to it, even. Third party authentication and verification services can integrate with carrier equipment in a variety of ways, but common HTTPS APIs used for this purpose share only the subset of signaling that is necessarily for the STIR authentication and verification services to do their work. Casting this as if these third-party vendors have unfettered access, let alone utilization rights, to “all call metadata” would not reflect the deployment reality.

 

I might add that in our era of cloud-based microservices, the boundaries between vendors, third-party service providers, and indeed carriers have gotten a lot less crisp. The distinction between something running on “carrier equipment” and a cloud service is not so stark as it was a decade or so ago. Ultimately, carriers decide to license or author AS/VS code to run themselves, or to rely on hosted solutions, based on a variety of business and operational factors unrelated to the protocol design work we do here at the IETF.

 

“Our third concern is in the Out-of-Band SHAKEN protocol, which is used for legacy providers that use pre-digital telephony infrastructure. Out-of-Band SHAKEN requires the use of a third party that stores metadata about calls in pre-digital telephone networks. This third party has access, again, to all call metadata.” 

 

OOB SHAKEN is an ATIS specification, which is not under IETF change control. RFC 8816, the IETF OOB specification, does not require revealing PASSporTs to third party services operating a Call Placement Service, provided that encryption keys can be exchanged between parties (which admittedly is not trivial). But more recent work here on OOB has focused on making its data collection risks equal your second concern above – effectively by coupling the CPS with the verification service function. 

 

Hope that helps, happy to follow up,

 

Jon Peterson

TransUnion (Neustar)

_______________________________________________ stir mailing list [e-mail] https://www.ietf.org/mailman/listinfo/stir