[messaging] Are we pursuing real solutions for security?

[elijah]

On 03/11/2014 02:12 PM, Daniel Kahn Gillmor wrote:
> On 03/11/2014 04:31 PM, elijah wrote:

>> For me, the goal needs to be zero-click encryption, as Schneier has
>> recently called it, so I get very uncomfortable with any discussion of
>> fingerprints or even SAS.
> 
> we're not actually talking about encryption here, though; we're talking
> about authentication.  if we don't bother authenticating the peer,
> zero-click encryption is trivial (and we should be doing that already,
> though there are many places that we do not).

Although I generally appreciate your pedantic nature, you know me well
enough to know that I think authentication is the major issue we face.
So, *of course*, when I say zero-click encryption I mean from the user
experience point of view, not in terms of breaking down the different
infosec properties (zero-click integrity?).

> do you have proposals for how to do "zero-click authentication"?  the
> key management problem is a much harder than the encryption problem.

Again, you know damn well that I do: https://leap.se/en/nicknym
(basically TOFU+provider-endorsement+network-perspective). In hindsight,
I would like to modify this proposal to fix certain problems by adding a
balance of powers.

> The answers seem to be a choice of one (or more) of the following evils:
>  0) TOFU (e.g. ssh-style)
>  1) CA-style infrastructure (e.g. "X.509 PKI")
>  2) public logs (e.g. Certificate Transparancy)
>  3) certification network (e.g. OpenPGP "Web of Trust")
> (there's probably some other major scheme that i'm missing in this rough
> sketch)

I think that you could add:

4) Single authority (aka DNSSEC, a subset of #1)
5) Endorsement (a subset of #3 but where certifications are not based on
social contact)
6) Network perspective: not a method of authentication, but can be
useful in auditing. Could be an open or closed set of notaries, or
simply Tor.

#4 and #5 are arguably subsets, but with different benefits and problems.

> The trouble is, all of these schemes have places where they break down
> and fail in bad ways.

Maybe there is some other dkg? I feel like you and I have talked about
this at length: my position has been that the only way to get
authentication easy enough for common use is to combine approaches into
a design that is institutional as much as cryptographic. As the Gipper
says, "trust, but verify". In other words, depend on a finite set of
certification entities, but ensure that their work can be publicly audited.

Yes, each method has serious failings, but they fail in *different*
ways. This opens up the possibility for symbiotic combinations.

>> +--[ RSA 2048]----+
>> |  . . .   .      |
>> | . . . E o       |
>> |.       + o      |
>> |..  .  o * .     |
>> |.. o    S o      |
>> |. o  ... .       |
>> | . . oo          |
>> |    o..          |
>> |     .o+.        |
>> +-----------------+
> 
> I can't tell if this is a serious advocacy of randomart

Nope, I think the whole exercise is quixotic. The only real manual
verification that makes sense to me is the biometric feedback + friendly
SAS in ZRP. I think Zooko said the original idea behind this was that
you could eventually chain all your other authentication needs off this.
It is easy enough for common users and you can do it at any time.
Sublime. Now if only I could get pulse audio working.

-elijah