[Freedombox-discuss] FOAF developers taking FreedomBox into their equation

[Boaz]

I'm so glad that we on this list are now turning our attention to the
issue of public key authentication, because I see this as being at the
heart of the change that we must make to the world.  Allow me to
explain.

I view our mission regarding the forms of electronic communication
that people use in their lives in three parts:
1. That they should use free and open protocols, so they could run
their own servers.
2. That they actually do run their own servers.
3. That they encrypt their traffic from end to end.
Surely, parts 1 and 2 have value in their own right, even if part 3
goes unfulfilled.  But the third part is where the knife meets the
matter as far as freedom goes.  Great if everyone owns their own
little server with all their data and communicating with their friends
through their friends little servers.  If the government can intercept
all the traffic, we've not really achieved freedom.  I therefore see
encryption as being the heart and soul of the benefit that the freedom
box can create.  And so I am very happy that we are now turning our
attention to this.

I'm somewhat of what someone on this list has called an “arm-chair
geek”.  I've never written a line of code in my life, and I'm
cognizant of the fact that I'm about to propose something which I
don't have the skills to write.  So you should take what I say with a
grain of salt.  I'm just this guy who yearns for freedom and thinks he
has some insight into the technology that we need to create it.  I
hope something I say here people find useful.

In our mental framework, I urge that we keep a separation between
addressing and authentication, and between both and message content.
By addressing, I mean the mechanism by which Person A's box can
physically locate in the network the box of Person B (someone person A
knows or has just met) and route a message to it, in a way that is
quick convenient and easy for Person A and Person B.  By
authentication, I mean the mechanism by which Person A's box can be
sure that the public key which it is using to encrypt messages to
Person B is actually the public key the corresponding private key for
which actually rests on a box which belongs to Person B, in a way that
is quick convenient and easy for Person A and Person B.

I think that if we had kept this separation, we might have prevented
for example the confusion wherein some people were proposing that
WebID is an authentication mechanism.  As has already been noted, it
is not.  This document:
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_with_FOAF.2BSSL.3F
cuts to the core of the issue when it says: “The strength of this
verification then depends essentially on
the trust one has in public key cryptography
the trust one has that one did indeed get an uncorrupted meaning for
the Web ID.
If the WebID is an https URL, and the server's certificate was itself
signed by a trusted CA, then this is the security that is accepted for
reasonably sized business transactions. With DNSSEC being rolled out
now, this part will be even more trustworthy.”
While many people (including other parts of the same document!) had
been speaking about WebID as being a solution to authentication, it
actually is a solution to other problems which at present relies on
the same poor authentication solutions which most of the rest of the
world's encrypted internet traffic presently relies on: trust in the
centralized certification cartels with X.509.

Or we might have prevented the confusion where some people felt that
adding an authentication feature (DNSSEC) to a centralized system of
addressing, solves the problem that authentication is centralized.  Of
course, it doesn't.  It just recruits DNS providers to act as
certificate authorities.  Good, fine, but it doesn't solve our
problems.

Because our problems are how for two people who know each other in
real life, without relying on any central authority (as any central
authority can be co-opted by those in power), to open a channel of
encrypted communication over a network that is impervious to
man-in-the-middle attack, assuming that the attacker is in complete
control of the network that they're using to talk to each other
(which, as the purpose of this project is empower people to defend
themselves against oppressive governments, is exactly what we should
be assuming).

And it seems to me that no really workable solution has been proposed
on this list so far (at least, since I started following it about two
and a half weeks ago).  But I do think that a workable solution can
exist.

The solution of “no problem, I'll just publish my public key on a web
page” is not a solution, nor are “self signed certificates”.  Nor is
the use of X.509's single-issuer anyone-single-one-trusted-completely
“trusted” authorities, and nor is DNSSEC, which just recruits a
different central authority to be “trusted”.

The OpenPGP web of trust is a tremendous and awesome thing.  Like
everything else relating to this freedom box project, it will not be
used until it's as easy to use for very non technical people as the
various unfree technologies that are currently so popular.

But it suffers from a bigger and deeper rooted problem.  In the
demographic of interest, the web is a green field.  Blank.  Nothing
there.  You can be sure that you and I are not going to use a web of
trust to authenticate our key exchange if neither you nor I know one
single person in the web.

I am convinced (though I'm receptive to and would like to discover
that it is not true), that there is only one way, one way, that two
people who know each other in real life, without relying on any
central authority, without needing to be able to trace a route through
a web of trust, can, from a thousand miles apart, open a channel of
encrypted communication with each other and be secure against a
man-in-the-middle attacker who controls the network they're using.
And that that is voice.

Of course, ordinary people will not read to each other key finger
prints long enough to be cryptographically strong.  They will not sit
on the phone and say “one, four, delta, eight, eight, two, echo,
delta, seven, bravo...”; this they will not do.

But I do think that there can be an excellent solution to this
problem.  There's a protocol called ZRTP, proposed as a standard to
the IETF, which has been mentioned on the list already.  More
information can be found at: http://zfoneproject.com/faq.html the faq
for the project.  Also, several videos of Phil Zimmermann, who wrote
the protocol, talking about it:
http://www.youtube.com/watch?v=2AQH9GOjwC0
http://www.youtube.com/watch?v=oc5kAVZ_dP8
http://www.youtube.com/watch?v=euK3m9y4xcs , you can probably find
more.

ZRTP solves exactly this problem quite elegantly.  The links above
explain it much better than I can, but I'll describe it briefly.  You
do a Diffie-Hellman exchange, but before either side sends its public
key, first they send a hash of the its public key, effectively
committing to what it is before the other side (or the attacker) gets
to see it.  Then, after the key exchange is done, both sides hash the
result and show both end users two words called a “short
authentication string”.  If the words that the two people see are
different, then there's a man-in-the-middle attack, if not, then there
isn't (the two users verify that they're the same by voice).  The two
words have very little entropy (only 16 bits), but this still prevents
a man-in-the-middle attack because, since the sides are committing to
what their public keys are before telling, the attacker would need to
guess what information to send along in order to result in the two
words being the same, with only a 1 in 2^16 chance of getting it
right.

This is something that I think ordinary people can actually do.  You
make a phone call, up on your screen it says “clockwork pegasus”.  You
say “hey Bob, does your screen say 'clockwork pegasus'?”, and Bob
responds “yeah, mine says 'clockwork pegasus'”.  And you only ever
need to do this once, at any time during the phone call, on your first
call or any subsequent call, to ensure that all your calls are secure.
 Ordinary people will not hold key signing parties, they will not.
But I think they will do this.

Now Zimmermann specifically had VoIP in mind, and he's been going
around plugging ZRTP as a solution to VoIP security.  And in this
Zimmermann is being very short sighted.  Once we've solved this
difficult problem of authentication, why not use that as the basis to
encrypt every kind of traffic?  Sure, it has to start with VoIP, but
after that there's no reason to use a different key exchange mechanism
for other types of traffic.

Here's what I envision.  Two people connect through their freedom
boxes.  Their boxes try to find a path to authenticate each other
through the web of trust.  If they succeed, great, if not, their boxes
use self signed certificates for now, which is at least no worse than
not encrypting at all.  In either case, the first time they make a
phone call to each other, their boxes do a ZRTP exchange (maybe the
people actually bother to verify the short authentication string,
maybe they don't, at least the strings were up on their screens and
they had the option to do it, which should deter attackers).  Now
these two people's boxes are authenticated to each other.  Thus the
web of trust grows one strand.  And all of this happens behind the
scene, the real people don't need to do anything, except maybe verify
the short authentication string.

What does everyone think about all this?


Boaz