Re: [stir] STIR/SHAKEN Privacy Concerns

[Alec Fenichel <[e-mail]>]

FYI, the new version of ATIS OOB SHAKEN (not yet published) does not require a third-party STI-CPS or any STI-CPS to STI-CPS communication. I anticipate it will be published early next year.


Sincerely,


Alec Fenichel


________________________________
From: stir <[e-mail]> on behalf of Peterson, Jon <Jon.Peterson=[e-mail]>
Sent: Friday, December 1, 2023 14:05
To: Josh Brown <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [stir] STIR/SHAKEN Privacy Concerns

Some people who received this message don't often get email from jon.peterson=[e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

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)