Re: Defining Trust and Reputation

Ed Gerck <[email protected]> Thu, 18 Mar 2004 17:18:23 -0800
Newsgroups gmane.ietf.asrg.smtpverify
Message-ID <[email protected]>
Yakov Shafranovich wrote:
> 
> And the trust model that somebody uses would depend on his definition of
> spam.

Yes -- and, in general, the threats that need to be considered. 
However, before we can define spam (the threat), we need to define 
what we trust. This may seem ilogical to some. Some people like
to think of the risk model first, and it works for them most of
the time. There are good reasons, however, to define trust first. 
Risk can only be defined after one defines what is at risk, and 
what is at risk must be that which is trusted to some extent -- 
otherwise, there would be no risk. In other words, risk has to 
do with loss and probability of loss but only the loss of what 
is trusted would affect the system. 

The general process of establishing trust in the presence of risk, 
goes from its Initiation (Absence of Trust) to the final Verification 
Decision (Trust or Not Trust?). Trust refinement and risk refinement 
are two independent internal feedback loops -- one set of processes 
that "make trust" and other processes that "break trust". To ensure 
trust, we need to look at what breaks it. 
This is shown in the diagram at http://nma.com/image/trustprocess.gif
 
> It seems to me that we have two approaches here:
> 1. We can try to define a trust model that is reasonable for fighting
> spam. However, with the divergent spam definitions, that might be
> unrealistic.

We can start with a simplied model -- trust no one. And refine as
we go -- for example: yes, we can trust the information if a number
X of MTAs in different networks (defining 'different' is a challenge 
by itself) agrees with a margin of Y.

> 2. We can try to define a framework for exchanging and queing trust
> information, and let receivers pick their own trust models that they
> want to use. Part of this would be a protocol for providing hints from
> the sender. This might be more realistic, but is still a lot of work.

Having incompatible trust models would be... incompatible. Your suggestion
can work well though, and I go back to my example above, if we parametrize
the trust model and let different users pick their own parameters
(for example, X, Y and 'different' above). The model is the same, the
instantiation is different.

Cheers,
Ed Gerck