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