Re: A peer-to-peer trust system model (was: Re: spam)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



g'day,

Einar Stefferud wrote:
> 
> Hello  Peter --
> 
> I hate to be the one to tell you that the following is provably false:
> 
> "The unlying (sic) assumption here is that trust is a transitive relationship,"
> 
> Which leaves a bit of a gapping hole in your entire logical build...

Not at all, since the assumption of transitive trust is used merely to
"prime the pump". Once you start to develop evidence that disagrees with
your assumptions, you are expected to change your trust rules
accordingly. That's actually the heart of the system.

For example, I might start off by trusting mail from a particular
mailing list, and all its participants (say, anyone from my family
mailing list). I would then accept trust tokens from anyone who submits
a valid token from anyone on that mail list. Of course, if anyone used
such a tokento feed me spam, I'd hit the "Junk This" button on my MUA,
which would in turn tell my MTA to remove both the sender and that trust
token from my "trusted" list.

Put simply, I'd use a rule that says something like "fool me once, shame
on you, fool me twice, shame on me".

Note that this wouldn't prevent any of the folks on that mailing list
from reaching me, it would only prevent my MTA from trusting the
offender's token in the future. You could even tune that by putting
additional policy info in the trust token (you could put in a "degree of
trust" number, indicating how well you know the bearer, for example).


Now, suppose I wanted to send mail to Paul Vixie. I might just try to
send him mail, but from recent experience, I would expect that to go
something like this: "Hi, Paul!", "Mail System Error - Returned Mail".

Hmmm...

So, my MTA checks Paul's list of trusted buddies in the new, improved
DNS++, but doesn't recognize anyone in the list as somebody who's issued
me a trust token recently. So, off it goes to the Token Oracle, and ask
her for a trust path between myself and Paul Vixie (trust me, this can
be done. I have a proof of this, but the margins of my screen are too
small to contain it. It's enough for the purposes of this exposition to
note that this is something that can be precomputed so it can be
obtained somewhat efficiently).

So, back comes the Oracle, with the path:

  Peter Deutsch -> Einar Stefferud -> Randy Bush -> Paul Vixie


In other words, there is a trust chain from Einer Stefferud (who trust
me), to Randy Bush (who trusts Einar), to Paul Vixie (who trusts Randy).

Well, that's okay then, since I have a trust token from Einar Stefferud,
because I earned a trust token from you last week and you'd kindly
supplied me with one. Okay, so my MTA again contacts Paul's MTA and
offers it the trust token I have from you, as well as the trust chain.
Now, Paul can elect to accept mail from me, since the path checks out
and the token's good, and we'd be in business. Parenthetically, his MTA
would add the trust token from Einar Stefferud to his keychain for the
next time somebody comes a'calling.

Of course, if Paul reads my mail and decides that I really am as much of
a bozo as he'd feared, he's free to hit *his* "Junk This" button. This
would revoke my credit, and your trust token to me in his eyes, so he's
free to go back and finish reading the IETF mailing list without any
further direct interruption me. If I really want to reach him again, I
could try to find other paths from the tokens I've got left, until
either I've used up all my friends and acquaintences in a vain attempt
to get Paul's attention, or perhaps until I finally (through constant
allusions to Tom Lehrer) convince Paul Vixie that I'm not so bad after
all ("heck," he says, "this guy's a dope, but I do like 'Poisoning
Pigeons in the Park'...")


So, trust can be assumed to be transitive to prime the pump. Where you
find that this assumption is not valid, you can use the evidence that
it's not to tune and adjust your list of trusted sources. It's this
tuning over time that would make them more effective and lead to the
predicted success of the technique. 


As a final observation, the transitive nature of the trust is not the
key part of the system. To me, it's the ability to put policy decisions
in the hands of the recipient based upon past experience with trusted
sources, without having those trusted sources participate in the
interaction in real time. This seems to offer simplicity and scaling,
and means we can build this beast and get it out without requiring such
things as a single globally populated PKI, or universal takeup on the
scheme (the degenerative case is to accept everything, as folks do today
- the benefits accrue to the participants proportional to their
participation, but it begins paying off the first time you reject an
unknown sender without a trust token).


So, in summary, trust may not be transitive, but it makes a useful axiom
to kick things off. To paraphrase somebody's point a few hundred
postings ago, something can be an axiom without being true... ;-)


				- peterd



-- 
---------------------------------------------------------------------
    Peter Deutsch                       pdeutsch@gydig.com
    Gydig Software

                        "Bungle..."
               "That's an 'i', you idiot..."
                  "Oh, right. 'Bingle..."

                            - Red versus Blue...

---------------------------------------------------------------------


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]