Re: [GNU/consensus] [SocialSwarm-D] Zooko's Triangle

[Guido Witmond]

On 25-07-13 17:47, carlo von lynX wrote:
>> On 25-07-13 10:02, carlo von lynX wrote:
>>> hi there eli.. well if saying 7yuogiqxgrak36kk is all it takes to
>>> achieve Identity <> key mapping and as hard as human unfriendly gets,
>>> I am positive people out there are going to deal with human unfriendly
>>> for the sake of a truly reliable communications infrastructure.
> 
> On Thu, Jul 25, 2013 at 12:04:33PM +0200, Guido Witmond wrote:
>> I think that's too optimistic. People choose easy over secure anytime.
>> Even if it threatens their lives.
> 
> point granted.
> 
>>> - socialist millionaire's shared secret while having a beer together
>>> - public key in a QR code on a business card (printed paper is harder to 
>>> mitm)
>>> - a slice of the hash confirmed by voice on the phone
>>
>> 1. Having a beer together is fun but doesn't scale over distance. How do
>> I set up a secure channel with people 50 km away? There is no such thing
>> as virtual beer.
> 
> let's discuss the scenario of a phone conversation while at the same time
> typing the shared secret into the prompt. this requires a MITM to be ready
> to act immediately - that is, agencies must have a VERY high interest in
> you if they are monitoring you in real-time, not just recording your stuff.
> THIS to me sounds like an acceptable compromise if you can't take the
> classic walk in the park and keep an eye on people following you.

This will surely work, I think ZRTP already does this. But it is just
one scenario.

> i'm not trying to achieve perfection, i just want surveillance to cost as
> much effort as it had in stasi days, back in the 80s.

Me too!

I want to be able to browse the net without being tracked left, right
and center to feed me more advertising.

I want all the data encrypted all the time.

I don't want to have to provide my email address each time I have to
create an account. And using temporary email providers is also an extra
hassle. Email address can be personal identifiable information. Mine is.

I don't want to have a single identity online. I want as many identities
as I have passwords at sites.

I want to stay anonymous when buying something on the net. They get my
money, I get the product/service. (Paying and shipping anonymously is
hard). But with a throwaway identity, it makes tracking that order to my
other activities harder.

I want a way to exchange encrypted messages (sort of email) just as easy.

I want to put the control of anonymity in the hands of the users, not
having to trust a company.

I don't want to prescribe these ideals to others. If someone uses my
protocol to log in to facebook, why not. Its their freedom. At least,
they are safe when facebook gets hacked. There is nothing to gain at
facebook to impersonate them at gmail.

I want to deploy it into the current web infrastructure.

With everything encrypted the spooks will have to hack the endpoints,
not hoover at the center.

Right now, that's where my quest for perfection stops. End user systems
are notoriously bad at protecting the users. Capability designs help
tremendously.


>> 2. Public key fingerprint or QR codes are not Zooko-proof. It's fails
>> the human memorize-able property. I can't read it from the side of a bus
>> and type it in at home.
> 
> granted concerning fingerprint, not acknowledged concerning a QR code you
> received on paper from that person. in that case it's irrelevant that you
> can't memorize its pattern - you just show it to your camera.

Agreed, QR codes on business cards are an excellent way to distribute a
key/certificate. Can't MitM that.


>> 3. A slice of a hash only proofs that you have a secure channel when you
>> know the identity of the other person.
> 
> what's wrong with that?

It only works when you can identify the person by voice. If I call the
help desk of my bank, I can be mitm'ed without me detecting it.




>>> Tor is leading the way. Simply by spelling out 7yuogiqxgrak36kk to you

>> Not so fast, mister 7yuoqigxqrak36kk,

Did anyone notice that I replaced the 'q' and 'g' characters in here?
That's the human memorizable property in action. Or the lack of it. :-)




>> Feel free to check out my attempt at solving Zooko's triangle. It uses
>> DNSSEC/DANE to validate the domain and it uses a network perspective to
>> validate each CA at the domain. Users are anonymous.
>>
>> Check out:
>> http://eccentric-authentication.org/eccentric-authentication/five-minute-overview.html
> 
> i like the CA root key taken offline...  :)   it's like our identity
> recovery strategy described in http://secushare.org/threats
> 
> pretty advanced strategy.. not bad. so the achilles heel would be if
> US government does something with the DNSSEC root? but all it could
> do would be to break the certification system, right? 

DNSSEC is used to *introduce* the correct certificate at first contact.
Validate all DNS results until you reach the ICANN Root Key that is
pinned in the client software. Fail hard if you fail validation.

After you've created a client certificate at the sites' CA,
you can verify that the sites Root CA is the same as your client
certificates Root CA. The sites' CA is the identity. That's why each
site needs its own CA.

If the registrar is coerced and replaces the sites IP-address and DANE
certificate to some spooks' site, spooks cannot impersonate the sites
Local CA root key unless they break RSA or capture that key from your
crypto-stick. Raising the price to a home break in.

Existing users would fail to validate the spooks CA Root against their
client certificates. And blog about it on another site.

It would 'fool' new users who don't read that blog. They could detect a
problem with it when they try to communicate with others on the site.
But that's dependent on the type of site and the paranoia of the user
agent software.




> i'm not sure
> if i'm grasping the full implications of this. the UDP limit for keys
> is evil. is it true that DNSSEC only provides URL download for larger
> keys? does that mean the keys are no longer protected by DNSSEC in
> that case?

I don't see a problem here. Good DNS resolvers switch to TCP when UDP
won't fit.

bash$ dig any _443._tcp.www.ecca.wtmnd.nl
;; Truncated, retrying in TCP mode.
.....
;; Query time: 31 msec
;; SERVER: 2a00:d00:ff:129:94:228:129:129#53(2a00:d00:ff:129:94:228:129:129)
;; WHEN: Thu Jul 25 21:17:36 2013
;; MSG SIZE  rcvd: 3231



Cheers, Guido.