[guardian-dev] WOT and Authentication Research

Hans-Christoph Steiner hans at guardianproject.info
Thu Jan 3 18:21:25 EST 2013


Hey Patrick,

I'm still wading thru the backlog from my paternity leave.  I read through the
epic post and the thread.  I'll start with a quick summary, then some replies
inline below.  There is a lot there, I'm wondering if you've condensed what
you're particular questions are since then?

I like the quote that you started with, that makes a lot of sense.  The math
of cryptography has been very well addressed in the past couple of decades,
but the human-math interface is really largely uncharted territory.  And
that's the part I think will bear the most fruit in terms of providing real
security for the largest audience.


On 12/18/2012 11:29 PM, Patrick Baxter wrote:
> Thanks for the response! I'm glad you have similar interests in this.
> I have some responses inline:
> 
> On Sat, Dec 8, 2012 at 11:45 PM, elijah <elijah at riseup.net> wrote:
> 
>> If I read correctly, a few of your main points are:
>>
>> (1) We need well defined and expanded trust metrics
>> (2) Everything would be better if we enforced a 1:1 mapping of public
>> keys and UIDs (e.g. alice at example.org)
>> (3) There are many different behaviors users engage in that demonstrate
>> trust, and many different cryptographic formats this can take. Why not
>> combine them in order to build a much more complete sense of trust?
>>
> 
> I think that is a really good summary. I could also divide this into
> two goals, by stating.
> 
> 1) We must improve the ability for anyone to participate in end-to-end
>    encryption WITH strong authentication:
> 
>   a. This means leveraging many different social interactions and
>      protocols that can capture key validation.
>   b. Improved ability to manage a private key
>   c. When possible, rely less on public key servers.
> 
> 2) Must create a flexible standard for a public data structure that
>    enforces this one-to-one mapping:
> 
>   a. It needs to balance the flexibility and usability tradeoff
>      intelligently.
>   b. Least possible authority
>   c. Is adaptable to different types of identities
>   d. "Trust agnostic"
>   e. Keys can be duplicated among multiple types of identities. Use
>      this to opportunistically to increase ability to enforce and
>      update mapping by using the validations from each domain
> 
>> If I understand correctly, another way to think of this same problem is
>> in terms of Zooko's triangle:
>> *snip*
> 
> Agreed!

As a kind of aside, I think that the Zooko's triangle analogy is not very
good.  It does not map the problem very well because it portrays the three
elements as equally affected by each other, when I think that's clearly not
the case.  Security and Human Memorable seem pretty much directly inversely
related to me, while decentralization has a much more vague, non-linear
relationship to the other two.


>> Essentially, I think the goal is decentralized human
>> memorable public keys. No one wants to type an OpenPGP fingerprint as a
>> destination address!
> 
> Agreed as well, having a key to encrypt and sign should be a natural
> thing to possess for every UID you have. People shouldn't have to
> think much about keys, but can probably understand it as a password
> that must be physically available. "you are using an unsecure
> connection on this login because you do not have access to your
> password"
> 
>> I probably missed a few, but it is a good starting list. Ideas that rely
>> on a single central authority are excluded.
> 
> As a side, unless you consider something like Sovereign Keys a
> centralized solution, I'd actually make the argument AGAINST
> federation. Rather, I think having a single 'centralized structure'
> that is replicated under distributed control is more desirable.
> Federation puts a single authority in place of a certain group of
> people. A central solution controlled by varying groups arguably must
> be more accountable and must collude to violate user's trust.
> 
> Still, a key server should only be responsible for keeping track of
> valid mappings. A user can do that on their own to varying degrees and
> accept changes in identity only if they want. Ultimately, keyservers
> must still present valid user signatures to be validated by a user.
> 
>> WOT: Alone, the current approach to WOT has problems with usability,
>> reachability, and what exactly counts as trust. Despite this, it works.
>> In my mind, however, WOT should not be considered as the primary method
>> of proof of control if the signatures are made public. Otherwise, the
>> user has exposed their entire social graph--data that can be more
>> sensitive in many cases than even the content of communication. WOT
>> might be very useful in modified form and in conjunction with other
>> schemes. Systems for automating key signing with mobile devices could
>> make WOT more practical in the real world.
> 
> This can be a tough trade off. I am aware of the problem of exposing
> social graphs thanks to William Binney. This is partially a different
> problem then solving authentication, but it matters to most people.
> However, I think anonymity is better solved in other ways that don't
> cost us the ability to make public signatures. Too many things expose
> you social graph to make it worth it to not publish signatures.
> 
> 1) Exposing your social graph as a list of people you've signed isn't
> as problematic as the real-time data of how often you contact a
> person, when, and what location is associated with that communication
> link.

I think its possible to use the WOT without publishing your social graph
publicly.  The keyservers can be used only for keys and revokation, then
people can exchange local signatures in a p2p fashion without ever publishing
them to keyservers.  This is very hard to do right now, but it is something
that can definitely be automated and with little user interaction needed.  I
hope to work on this as part of PSST this year.

That's all that's in me right now, but I hope we can continue this discussion,
hopefully in smaller, more bite-sized chunks :)

.hc



> 2) All that real-time information is still exposed for the time being.
> When you email someone you will never encrypt the headers and so
> hiding signatures is a moot point until a general anonymous routing is
> fully in place. Even hiding your IP with Tor won't help this since you
> exit to the general internet and still expose you headers. Unless some
> sort of anonymity system for each type of communication is made or a
> general darknet replacement for the Internet becomes viable I don't
> see this going away. CJDNS seems like a promising idea.
> 
> 3) I think the correct way to obtain anonymity/privacy would be to use
> strict psuedonyms that are only accessed/created over something that
> anonymizes your TCP/IP layer (Tor). This way you may still expose you
> social graph, but if you always use encryption, that pseudonym should
> be able to fully separate from your 'real' identity you wish to
> protect. Definitely not perfect though.
> 
> 4) Without making public signatures, third parties really can't help
> authenticate you and you are left with a fully distributed system or a
> system that completely relies on third parties to authenticate you. If
> going the distributed route it would look similar to GPG without the
> keyservers. This works locally, but anytime you need to authenticate
> with a person you haven't met, you most likely don't have a path to
> that person.
> 
> 5) Since this is such a small scope of the anonymity problem you could
> almost label it as a privacy problem. One alternative is to send
> signatures to the person you signed and let them choose to publish
> them. This way no one publishes that they signed your key unless you
> are OK with it.
> 
>> DNSSEC: There are RFCs for discovery of user's public keys via DNS,
>> could be use with DNSSEC... If you love the idea of putting trust in the
>> domain name system. Ugh.
> 
> It seems necessary and inevitable to work with DNSSEC for the time
> being. Its been in the making for so long and if DNSSEC provides at
> least some faith in which keys belong to which domains then that may
> be useful as another authority to help enforce an initial mappings in
> the DNS world. Convergence and Sovereign Keys both provide methods for
> relying on this.
> 
>> Biometric Feedback: In synchronous communication, you can use non-verbal
>> clues (like the sound of someone's voice) for both parties to mutually
>> validate identities (when used in combination with a challenge, like in
>> ZRTP).
> 
>> Shared Secret
> 
> Yes! I think this type of stuff is really fascinating. The more valid
> protocols like this that are available to people, The more people can
> sign keys with out knowing precisely whats going on. If using a WOT
> this means more paths. If you just collect signatures, this means a
> stronger consensus on a mapping.
> 
>> Mail-back Verification:
>> Network Perspective:
>> Authority Binding:
> 
> Agreed, all good things!
> 
>> Federated WOT: Rather than force users to practice good WOT hygiene, the
>> idea with a Federated WOT is to force service providers to do proper
>> key-signing and then have service providers sign the keys of their
>> users. This allows for end-to-end WOT trust path without exposing the
>> social graph, although it requires cooperation from the service
>> providers (but not faith in them, see network perspective).
> 
> Interesting Idea! This puts some structure on the WOT. I'm not sure
> though.  Could a single federated structure corrupt/MITM a path for
> one of its users?
> 
>> I have labeled what I think you are proposing "Trust Agnosticism". No
>> doubt, you have a better name, but I needed something to call it
>> something for the purpose of this email.
> 
> I have no better name, thats as good as any :)
> 
>> I agree with #1 and #2, but ultimately have some reservations about
>> parts of #3.
> 
>> I absolutely agree that some linkage between different key formats would
>> be a big improvement, as proposed by PSST. As for improving the WOT by
>> including different sources of linkages, ultimately I think the WOT is a
>> dead end for the use cases that many of us would like to support.
>>
>> Specifically:
>>
>> (1) To be useful, a WOT exposes a user's social graph.
> 
> See the other response about this above.
> 
>> (2) In order to address the rapid rise of mass surveillance, in either
>> repressive or democratic contexts, we need to dramatically increase the
>> rate of adoption of end-to-end message encryption. I think there is a
>> lot of evidence that current schemes are too complex (since so few
>> people use them correctly). My claim is that this complexity cannot be
>> fixed with better tools, but is a problem in the inherent conceptual
>> complexity of OpenPGP and OTR, etc. A lot of people will take issue with
>> that last statement, but these people have probably never tried to get
>> activists in the field to use existing secure communication tools
>> correctly and consistently. But our goal cannot just be to achieve
>> adoption among people who are motivated enough to pay a privacy-tax. To
>> be effective against mass-surveillance, we must work to reduce the
>> privacy-tax to nothing.
> 
> Most definitely. I think the accessibility is what is really
> interesting about LEAP. However, I still think you can make a WOT
> usable by updating our keyserver structure and changing the end-user
> software to be a better experience. Remove trust decisions and
> automatically capture signatures through some of the aforementioned
> things.
> 
> I'm not convinced the WOT is bad, but its still a bit open as to the
> correct way to use it. I like the idea of preserving the ability for
> users to authenticate without any trust in a third party when
> possible.
> 
>> We are early in our design and coding process, and would absolutely love
>> to dialog and collaborate with other people interested in this problem
>> space. Depending on what funding we are able to put together, our work
>> in this area may progress faster or slower.
> 
> Cool stuff, lets keep up the dialog!
> 
> -Patrick
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info
> 


More information about the Guardian-dev mailing list