[guardian-dev] WOT and Authentication Research

[Abel Luck]

Patrick Baxter:
> On Thu, Jan 17, 2013 at 10:46 AM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
>>
>> Whether its a worthwhile exchange to publish signatures publically depends a
>> lot on what the repercussions are.
>>
>> I could see three "modes" related to this:
>>
>> * paranoid: always use lsign, only exchange signatures face to face, no
>> exchange of signatures other than my own
>> * peer-to-peer: never export signatures to the keyservers, exchange all
>> signatures I know about when I meet face-to-face
>> * keyserver: export everything to the keyservers
>>
>> Ideally, this mode would be tagged in the signature itself so when a
>> 'paranoid' exchanges signatures with a 'keyserver' all signatures involving
>> the 'paranoid' do not get uploaded to the keyserver, and so on and so forth.
>> I suppose that if the peer-to-peer mode works well, then nobody should really
>> use the keyserver.
>>
> 
> I agree there would have to be some method to opt-out or opt-in to the
> publishing of signatures and those modes make sense. No one should be
> forced to participate the publishing of signatures. One advantage of
> publicly publishing signatures is that there is a much higher
> probability that you can independently verify a path through the WOT
> to a new contact. Otherwise, you are relegated to trusting the
> keyservers.
> 
> For authentication used by the masses, having contact with a
> distributed set of keyservers (owned by different parties of interest)
> through a cert-pinned SSL connection offers much more security then
> present. Particularly since these servers can be audited for
> consistency and user's could also check for persistence of keys among
> their contacts. Strict regulation for changing mappings combined with
> proof of ownership for new user's would be enforced.
> 
> I think that may be the best security a centralized key-structure can
> provide. Beyond that, it won't get in the way for those interested in
> truly Independent verification.
> Its a matter of enabling clients to rely on that infrastructure as
> little as possible. Publishing signatures will help with that and
> should be encouraged for those who aren't at risk by having published
> signatures. Also, those exchanging signatures in a distributed manor
> can benefit from the keyservers as well. Any mappings they receive
> should also reflect that same mapping as exists in the keyservers.
> 
> Lastly, having a persistent and public listing of name-key mappings is
> a valuable and important addition to a distributed WOT. In a
> distributed environment, I don't see how you can enforce unique
> mappings. This way, when you receive some new keys from a friend you
> can check that they exist properly in centralized data-store. At the
> least (for those who don't wish to upload at all), you could expect
> not to see that person's public key or email tied to anything else.
> 
>>
>> Why do you want to push verification to the keyserver?  I suppose it could
>> provide another channel of authenticity data for bootstrapping.  But it seems
>> once you've verified the fingerprint and its connection to a UID, then you
>> don't need the keyserver to verify anything.  That keeps the keyserver simple.
>>
> 
> Mostly for the reasons above. To reiterate, improved centralized
> keyservers would only augment the ability to securely authenticate
> another user. Independent verification is still the ultimate goal, but
> this can be facilitated by a better keyserver infrastructure and the
> widespread publishing of signatures for those who agree to it.
> Additionally, weaker levels of verification would be more accessible
> for user's with more transient names or poor ability to store and
> maintain access to private keys. Its not a matter of pushing
> verification to the keyserver, but creating the best keyserver
> infrastructure that can be provided without stepping on the ability to
> independently verify another person's mapping of key to name.
> 
> Ultimately, this may make it easier for people to participate in a WOT
> and this would be a step in the right direction for accessible
> authentication. Client infrastructure (GPG for everyone!) can improve
> over time across different platforms, but there are a lot of steps in
> getting there and it could be awhile before everyone can securely
> maintain and use a private key. Trusted computing modules in phones
> would be cool.
>


Finally jumping into this thread. Honestly, I'm not sure I agree with
where this is going at a high level.

(from above, emphasis added)
> Publishing signatures will help with that and
> should be encouraged for *those who aren't at risk by having published
> signatures.*

Threats change with time and circumstance and risk changes, but a public
WOT is permanently public.

IMO, everyone is at risk when their social networks is publicly available.

Welcome to Hotel WOT. You can checkin, but you can't checkout.

William Binney has shown us that metadata analysis is just as good at
providing intelligence as cleartext. By mapping associations over time
with other available data, statistically significant conclusions can be
inferred.

Traffic and metadata analysis research is lightyears ahead of the
corresponding anonymity research. We're still fumbling with encrypted
email, failing to explain asymmetric crypto to users, while massive
appliances and datacenters have been built to suck up and analyze three
simple fields: To, From, Date.

On the less paranoid side, look at privacy behavior on Facebook. While,
yes there are those with public profiles, or publicly searchable
profiles, there are many that value the setting "Friends only" or
"Friends of friends only". Remember the uproar when Facebook defaulted
to making your Friends list public?

Future authentication systems should start with the premise that the
social graph is AT LEAST as vital to protect as the social interaction
itself, rather than taking it as an edge case.

> Also, a separate idea, but as part of PSST has anyone heard of or
> looked into possibly storing keys on a server through some type of
> open-source and zero-knowledge client? That way you get to your keys
> with something like google's two-factor auth. You could dump your keys
> on dropbox, a personal server, or a VPS without relieing on those
> places being secure. Maybe a bad idea, but just a thought

This is definitely possible. Look at Spider Oak, Tarsnap, and TahoLAFS
(don't look at Mega).

Key backup is definitely important, something not specifically addressed
in PSST, but something we should look at.

> _______________________________________________
> 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/abel%40guardianproject.info
> 
> You are subscribed as: abel at guardianproject.info
>