<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><html>On Apr 13, 2008, at 5:36 PM, Edward B. DREGER wrote:</html><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>Bottom line first:<br><br>We need OOB metadata ("trust/distrust") information exchange that scales<br>better than the current O(N^2) nonsense, yet is not PKI.<br><br></div></blockquote>Not sure why PKI should be excluded, but, so far, this is too abstract</div><div>to know what the question is...</div><div><br><blockquote type="cite"><div>And now, the details... which ended up longer reading than I intended.<br>My apologies.  As Mark Twain said, "I didn't have time to write a short<br>letter, so I wrote a long one instead." :-)<br><br>When it comes to establishing trust:<br><br>* The current SMTP model is O(N^2);<br><br></div></blockquote>I don't see SMTP as even a "trust" model since there's pretty much</div><div>nothing trustworthy in SMTP.</div><div><br><blockquote type="cite"><div>* I posit that the current IP networking model is sub-O(N);<br><br></div></blockquote>Again, I'm not seeing IP as a trust model, but, YMMV.</div><div><br><blockquote type="cite"><div>* PKI models are pretty much O(1).<br><br>Polynomial-order just doesn't scale well.  It's mathematical fact, and<br>particularly painful when the independent variable is still increasing<br>quickly.<br><br></div></blockquote>Sure.</div><div><br><blockquote type="cite"><div>Many operators seem to reject PKI as "power in too few hands".  I'll not<br>disagree with that.<br><br></div></blockquote>Depends on the PKI.  For example, the PGP/GPG Web of Trust concept</div><div>pretty much lets each individual build their own trust model to whatever</div><div>O(x) they choose where greater values of x require more effort and also</div><div>provide greater security/trust granularity and lower values of x involve</div><div>greater trust of others that you claim you can trust and less direct effort</div><div>on your part.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>Let's also draw upon operational lessons from a couple old-timers.  I<br>recall using a critter known as "NNTP".  And once upon a time, before my<br>days on the Internet, lived a funny little beast called "UUCP".<br><br></div></blockquote>I remember UUCP.  It was pretty much O(n^2).</div><div><br></div><div><blockquote type="cite"><div>We track email quality from all mailservers that hit us.  I can whip up<br>a list of MXes/organizations that I'm willing to "trust" -- and let's<br>leave that term imprecisely-defined for now.<br><br></div></blockquote>Uh, OK.  Starting to understand what the question might be aiming</div><div>towards.</div><div><br></div><div><blockquote type="cite"><div>Here's what I propose:<br><br>Establish a "distrust protocol".  Let path weight be "distrust".  The<br>"trust path" is of secondary importance to "path weight", although not<br>completely irrelevant.  SMTP endpoint not in graph?  Fine; have some<br>default behavior.<br><br>Let _trust_ be semi-transitive, a la BGP -- a technology that we know,<br>understand, and at least sort of trust to run this crazy, giant network<br>that dwarfs even a 50M-user provider.<br><br>Let actual _content_ still be end-to-end, so that we do not simply<br>reincarnate NNTP or UUCP.<br><br></div></blockquote>Now I'm lost again.  You've mixed so many different metaphors from</div><div>interdomain routing to distance-vector computaton to store-and-forward</div><div>that I simply don't understand what you are proposing or how one</div><div>could begin to approach implementing it or what problem you seem</div><div>to think it solves (although it sort of seems like you're wanting to attack</div><div>the trustworthiness of email to battle SPAM through some mechanism</div><div>that depends only on the level of trust for the (source, arrival path)</div><div>tuple from whence it came.</div><div><br></div><div>What am I missing?</div><div><br></div><div>Owen</div><div><br></div></body></html>