Re: [stir] Potential security vulnerability in STIR/DIV

[Paul Kyzivat <[e-mail]>]

See below

On 7/23/20 9:22 AM, Jack Rickard wrote:
> I agree that div does make this kind of attack more difficult, and 
> requiring that there is some trust of every retargeting entity does make 
> sense. My assumption was that by only trusting the signers of the 
> passports I can trust the orig is the entity calling me, I now see you 
> have to trust the signers and the diverting parties. To clarify this I 
> propose that something like your explanation is added to the spec, i.e.
> 
> It is Carol who needs to decide if a forwarded call from Bob should be 
> trusted or not – “div” is certainly not suggesting that trust is 
> automatic, nor that the presence of a “div” that correctly chains to the 
> original PASSporT is a substitute for the policy and trust decision made 
> on the terminating side of a call. As with baseline STIR, just because 
> something validates at a protocol level doesn’t mean you should trust 
> it, nor that local policy does not determine how you treat calls.
> 
> To be clear, my original email was based on the belief that div 
> passports would provide a "chain-of-trust", allowing you to essentially 
> ignore that diversions had occurred once you had established there was a 
> valid chain of div passports from the originator to the final 
> destination. Although, after reading your response I realise that's not 
> the case.
> 
> My worry is that this model makes div difficult to use and police in 
> practice, specifically:
> 
>   * This model makes implementations more complicated as you can't
>     separate verification from policy decisions. You have to filter out
>     untrusted parties before doing the chain finding step of
>     verification, as otherwise you might decide upon a chain containing
>     an untrusted party when there does exist a valid chain containing
>     only trusted parties (granted this situation is unlikely).
>   * This model introduces complexity in what should be displayed to a
>     user, the simple verified/not verified can't be used unless you
>     require complete trust of all diverting parties, and that could
>     cause false negatives.
>   * If a diverted call does get reported as a robocall, it's not clear
>     whose reputation should be tarnished. It may have been that the
>     original caller was a robocaller and the call got legitimately
>     diverted to you, or it was the below attack where the caller is
>     trustworthy but the diverter was the robocaller.

When a call is diverted, isn't it possible for the diverting party to be 
in the media path? If so then you ought not accept diverted calls unless 
you really trust the diverting party.

	Thanks,
	Paul