Re: [Asrg] 6. Email Path Verification (hashcash benchmarks)

Jonathan Morton explained:
> You're right, highly centralised authentication systems are censorship 
> waiting to happen.  That's one reason why the system I suggested 
> recently is moderately decentralised - there is no mandated group of 
> "root servers" as in DNS, instead the recipient's MAA chooses a trust 
> directory, and the recipient chooses the MAA.
> Key is the fact that the recipient chooses who verifies the sender's 
> chain of integrity.  That means he can choose what groups of senders to 
> not listen to.  If one trust directory goes "bad", MAAs and/or 
> recipients can switch to a new one.  There's also not much barrier to 
> entry to setting up a new trust directory or MAA, if you think one's 
> needed.
than we should have a conversation of line if you don't mind because what you're 
describing could potentially be very good but dammed hard to fit into a simple 
human factors model.  Embedding public keys in messages and setting up 
opportunistic signatures/encryption within camram was an attempt to create a 
less forgeable white list and to provide envelope grade content protection.  But 
I'm starting to wonder if may be it might be more useful in the mechanism you've 
hinted at.  That maybe there's a way to publish your key, get it "blessed" from 
some authority people are willing to trust (i.e. the hotdog vault and trust 
company).  Then that would give us a way to change keys should a disk go poof 
sans backup.
> Most of my ramblings in this thread really have to do with how hashcash 
> might be useful as a supplement to my own authentication system, and how 
> it would impact users *that I know* who have somewhat lacking hardware.  
> There's a surprising number of older machines out there which are 
> entirely adequate for their users.
unfortunately hashcash isn't a useful authentication tool.  It is a useful 
introducer however.  The protocol I was trying to support is the basic e-mail 
protocol of today which is "hello, you don't know me but I would like you to 
read my message."  I have had wonderful connections established because of this 
protocol.  Hashcash adds the step "and this is how much it is worth to me for 
you to see my message".  That's it.  It says nothing about who you are or 
whether or not your identity is valid or anything that nature.  It also 
preserves end to end connectivity on the net for servers like mine (at the end 
of a speakeasy DSL line).
Sometime later we should probably talk about my vision for the future which is 
that personal e-mail and Web+++ servers will be set up in the home just like 
answering machines are today.  And they should be somewhat easier to operate.
> In other words, I'm convinced the technical hurdles can be overcome - in 
> the context of my own system.  I'm less sure of other systems, 
> particularly those that seem to require coprocessing hardware for the 
> low-end users when the postage costs escalate.
I have more faith and spoken with more average users about this topic.  In the 
best of all possible worlds, camram would exist inside of every e-mail client 
shipped.  Many of the scaling issues go away because it's designed to be 
distributed.  There are some cases where cooperation with a more central service 
would be beneficial such as public key verification or propagation but for the 
most part, it can stand alone and do so quite nicely.
> BTW, I do have some Java skills, but I find using them gives me COBOL 
> fingers.
it's only a little applet, it's mostly written but just needs to be modified... 
you might only get COBOL fingernails from that.
---eric



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg