Re: [stir] STIR/SHAKEN Privacy Concerns

[Josh Brown <[e-mail]>]

Hi Jon,

Happy New Year and thank you for your detailed response! I have a few 
follow up questions.

> 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

Could you explain why a signed PASSporT would not be sufficient and what 
"external corroboration" would be required?

> speaking broadly, regulatory environments and carrier infosec policies 
> shape the data governance constraints under which such services operate
Could you elaborate on this section? If you don't believe this mailing 
list is the appropriate place, please feel free to reply directly.

Best,
Josh

On 12/1/23 2:05 PM, Peterson, Jon wrote:
>
> 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)
>