Vulnerable to a third party

As Nick Szabo points out in TTPASH, the word “trust” itself is a bit overloaded, and can in fact mean almost its own opposite. Well-informed trust is, rather than a security hole, typically the very source of your security.

Alan Karp, Mark Miller, and others have observed the confusion over words like “trust” and “trusted” as used in the security community, and proposed replacing the verb “trusts” with “is vulnerable to”. This substitution is a great way to radically clarify security protocol designs. “Trusted third party” as used in this essay becomes “vulnerable to a third party”, and the point of this paper, that this is a security hole, becomes obvious.

This section on terminology ends with a dense trio of sentences:

Whether a designer thinks he does or must trust some generic class of parties is one thing. Whether a particular user will actually trust a particular entity in that class when the protocol actually runs is quite another matter. Whether either the user’s trust or the designer’s trust is well informed is yet another matter still.

Let’s tease this apart. I think we’re on the verge of some sort of trust chart.

1. Does the designer think / admit his system includes TTP?
2. Does the user actually know about / trust those TTP?
3. Is the designer’s trust well informed?
4. Is the user’s trust well informed?

To rephrase these one more time:

When building a system, we should be up front with our users about where trust exists (where they’re vulnerable to us or others), and yet endeavor to prove that trust is well-placed.

When using a system, we should be clear-eyed about which parts of that system we’re vulnerable to, and choose our TTP with wisdom and faith.

Maybe the “wisdom” part of the advice to the user is obvious, but why faith? Well, without faith in the TTP there’s no TTP. So either as a user you forgo use of that particular system, or you step out in faith. There’s no middle option when trust is required.