Subject: [stir] the role of trust in stir

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jul 2015 07:05:20 -0400

I couldn't make myself clear via jabber during the discussion, so I'll 
try again. This is similar to a point that Henning made.

There seem to be a few models for how verifier determines whether a cert 
actually covers the number it signs:

- the message contains the cert

- the message contains a ref to the cert

And then, regardless of how the cert is obtained:

- the cert contains the TN.

- the cert contains a reference to a list of covered TNs.

- the cert has neither (is that a real possibility?)

This then leads to several possible cases for the verifier:

1) there is no signature

2) there is a signature, but the cert can't be obtained

3) cert has been obtained, no attempt is made to determine formal 
coverage of the TN (because policy doesn't require it).

4) cert has been obtained, but coverage of TN by cert can't be determined

5) cert has been obtained, and it explicitly does NOT cover the TN.

6) cert has been obtained, and coverage of TN has been verified

I think all of those cases are possible regardless of policy. It then 
becomes a matter of policy how to treat calls in each case: allow or 
not, display calling TN or not, indicate warning or not.

But if certain policies become widely used they could have the effect of 
making other policies unusable. And that can have the effect of 
encouraging oligopolies.

In particular, if a common verifier policy is to just whitelist certain 
signers without checking coverage, and block the id from everybody else, 
then anybody who gets service from a provider who isn't on the whitelist 
runs the risk of not having their calls answered.

Also, when providers know most verifiers follow that policy, then they 
can also sign calls from favored peers not on the whitelist. (IOW, they 
can *lie*, assuming the lie won't be checked, instead reinstituting a 
transitive trust model.) That will allow them to further extend their 
business lock in and discriminate against whoever they want.

It seems especially bad to enable an environment where signatures can be 
made by signers who don't have authority over the signed TN.

I would like to see a system where verification doesn't depend on 
whitelists. (However blacklists could be used to reduce verification 
cost for bad actors.)

(I guess ultimately whitelists must exist at some level, but better be 
only at the very top of the delegation chain.)

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 Jul 2015 21:12:30 -0400

I agree. The trust model is key to what we need to do.

If the model is anyone can manage a TN, then we already have a system in place. It’s called X.509 certificates. If one only allows for rooted certificate chains, then one can presumably track down who is making a call, and you can whack them if they are bad. No need to have convoluted, trusted third-party verification of TN ownership (whether a Neustar/iconectiv/OFCOM model or a distributed model).

If the model is, in Martin’s words, only people who can be punished can manage TNs, then the mere presence of a signed message is good enough. If a carrier lies, they get fined $10,000 per occurrence, or some such regime that ensures they do not lie.

I could see a hypothetical regime where anyone can manage a TN but they go directly to their government with a credit card or e-Residency card to sign for it. In that case, you already have a trusted third-party: the government itself. If the certificate is not signed by the government, you know it’s bad. Again, no need to look at the TN itself, because the government presumably did some identity verification to generate the certificate.

So, I still do not see the need for per-call or even per-certificate verification. The chain of trust in the certificate itself should be sufficient.

> On Jul 21, 2015, at 7:05 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> I couldn't make myself clear via jabber during the discussion, so I'll try again. This is similar to a point that Henning made.
> 
> There seem to be a few models for how verifier determines whether a cert actually covers the number it signs:
> 
> 3) cert has been obtained, no attempt is made to determine formal coverage of the TN (because policy doesn't require it).
> 
> I think all of those cases are possible regardless of policy. It then becomes a matter of policy how to treat calls in each case: allow or not, display calling TN or not, indicate warning or not.
> 
> But if certain policies become widely used they could have the effect of making other policies unusable. And that can have the effect of encouraging oligopolies.
> 
> In particular, if a common verifier policy is to just whitelist certain signers without checking coverage, and block the id from everybody else, then anybody who gets service from a provider who isn't on the whitelist runs the risk of not having their calls answered.
> 
> Also, when providers know most verifiers follow that policy, then they can also sign calls from favored peers not on the whitelist. (IOW, they can *lie*, assuming the lie won't be checked, instead reinstituting a transitive trust model.) That will allow them to further extend their business lock in and discriminate against whoever they want.
> 
> It seems especially bad to enable an environment where signatures can be made by signers who don't have authority over the signed TN.
> 
> I would like to see a system where verification doesn't depend on whitelists. (However blacklists could be used to reduce verification cost for bad actors.)
> 
> (I guess ultimately whitelists must exist at some level, but better be only at the very top of the delegation chain.)
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Jul 2015 14:47:24 +0000

There are two separate policy issues:

(1) The call was made by somebody who is authorized to use the number.

(2) The call is/is not a nuisance/fraud call.

I suspect local policy and white/blacklisting is mainly involved in the second one (which is outside the STIR concern).

I agree that having a uniform signing behavior seems least likely to lead to have to code special cases, maintain lists, etc. We know from experience that maintaining the CA list in browsers (a whitelist, if you like) has not been a happy experience, and there are only a handful of browsers, not thousands of carriers, who have to make that decision. Similarly, wildcard certs (beyond domain-specific wildcards like *.example.com) also have not had a good track record.

You could call this the categorical imperative of signing: it's not a good idea if it can't be made the law of the land.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, July 21, 2015 7:05 AM
To: <[email-masked]> <[email-masked]>
Subject: [stir] the role of trust in stir

1) there is no signature

	Thanks,
	Paul