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

[Boaz]

> Point is, you already put a lot of trust in the _system_ and those _selling_ it to you.

Okay perhaps I'm naïve to imagine that because software is free means
you don't need to trust the people writing it.  After all, when
updates to the freedom box are distributed to you they come as binary,
and because this system needs to require no sysadmin, the updates are
delivered trusted and installed automatically.

I still somehow can't help feeling that there's a difference between
the trust you place in the developers of a distribution and the trust
you place in a certificate authority.  But since I can't identify why,
let's work from your premise that freedom box users must place
complete trust in Debian.

> that we offer them to trust not only our box and its software, but also our actual pre-established Web >of Trust.

How is a Debian developer (or multiple independent Debian developers,
unless we want to lose most of the value of a “web” of trust) supposed
to reliably verify: 1. the public key and 2. the identity, for some
value of identity that will be useful for someone who wanted some
assurance of it, of a freedom box user?  Millions of users?

Maybe I don't understand your proposal, but it seems to me that this
requires Debian to act in a capacity that has nothing to do with
developing an operating system: as a certificate authority.

That it doesn't require trusting anyone but the person you're talking
to isn't the only reason that I favor ZRTP-style authentication,
although I do like that aspect.  One major advantage of ZRTP, one that
Zimmermann is rightly quick to brag about, is that it avoids the
complexity of needing to rely on any kind of public key
infrastructure.

>Point is, all of them require user interface design if nothing else, which makes them tough to >implement (read: takes time).  Hooking existing Wot (Debian Developers) together >using existing glue (Monkeysphere) should take less time, I assume.

The need for rapid deployment of freedom box is clear and compelling.
I would never suggest delaying the creation and distribution of any
individual component of freedom box or any working box that does part
of what freedom box should, waiting for some super ambitious
undertaking that will delay the whole project.

But, ZRTP-capable VoIP clients already exist, and the freedom box
should do VoIP, so it stands to reason that the freedom box can
include ZRTP for VoIP.  And, once I've used ZRTP to talk to a friend
of mine and I know a public key that I know belongs to my friend, why
should I not use it as an OpenPGP key and use it to encrypt emails or
whatever to that friend?

Like I mentioned before, I don't have the experience to know what's
easy and what's difficult to program, so I don't want to be so
arrogant as to insist that one solution is easier or harder than
another when I don't really know what I'm talking about.

But consider: maybe ZRTP-style authentication for encryption of all
types of media can actually save time and work that now doesn't need
to be spent building and maintaining a pki which can handle rapid
integration of millions of users with no background in cryptography.

>On Sat, 2011-03-12 at 16:20 -0500, Boaz wrote:
>> 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.
>David Sugar (of the GNU Telephony project) has written about applying
>ZRTP-type social authentication to non-social protocols (even though
>pure ZRTP would work in this case):
>
><http://ubuntuwicohan.blogspot.com/2010/09/beyond-social-key-verification.html>

Okay, by “social key verification" I take it he means verification by
the voice of someone whose voice you recognize.  And by “non-social”
protocols, I take it you mean protocols that don't involve voice?

The main thrust of his piece seems to be that ephemeral/session keys
for perfect forward secrecy (as done in ZRTP) is desirable for
applications beyond just real-time VoIP.  I couldn't agree more.

As he describes, a single static key which is authenticated should be
able to be used to verify session keys for “things like email exchange
(smtp, imap, etc), vpn’s, etc. In fact anything SSL is used for”
leveraging whatever authentication that has already taken place over
and over again while maintaining perfect forward secrecy for
individual transmissions (in the same vein as how ZRTP maintains both
key continuity and perfect forward secrecy).

So he's pointing out that key continuity and perfect forward secrecy
need not be exclusive, and that this same principle and the same key
material can be applied to many different or even any arbitrary form
of communication.  All very true.

What he's describing requires that the two users have already
authenticated each other in some way.  As he writes:

>The approach I am taking is to directly exchange the hashes of the per-session generated public keys between the endpoints by signing them with a digital signature as a means >to guarantee the hashes are actually valid.

He goes on:

>...the signing keys for the hashes can be static and used to verify users and sessions through a web of trust.

So he envisions that the actual event of authentication takes place by
means of a WoT, not by “social authentication” as I advocate.

But, near the end, he does broach the possibility that the initial
event of authentication that could be further leveraged going on into
the future for all manner of “non-social protocols”, could be social
key verification ZRTP style.  As he writes:

>Verification need not be done “in-session”, as it can also be done in real-time communication sessions entirely separately with ZRTP style social key exchange if that is desired.

That is what I advocate.  That users initially authenticate each other
using "social" authentication when they communicate in real-time
voice, and then use that authentication to encrypt every manner of
communication that they have with each other from that point on.

I think Mr. Sugar is barking up very much the right tree here.


Boaz