[messaging] Are we pursuing real solutions for security?

[Daniel Kahn Gillmor]

On 03/11/2014 04:31 PM, elijah wrote:
> On 03/11/2014 03:33 AM, Tony Arcieri wrote:
> 
>> I don't think these solutions are providing effective security. I feel
>> we need to start from the real needs of real users, and work backwards.
> 
> 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).

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

The answers seem to be a choice of one (or more) of the following evils:

 0) TOFU (e.g. ssh-style) -- not protected against first use; requires
large amounts of client-side state; no clear way to distinguish
legitimate key transition from an attack; no global view

 1) CA-style infrastructure (e.g. "X.509 PKI") -- untrustworthy parties
put in trusted positions; horrible revocation semantics

 2) public logs (e.g. Certificate Transparancy) -- expensive to run and
audit; zone enumerability; "phoning home"; no real-world experience yet

 3) certification network (e.g. OpenPGP "Web of Trust") --
complicated/confusing user experience; non-global view of "validity";
possible social graph leakage

(there's probably some other major scheme that i'm missing in this rough
sketch)

The trouble is, all of these schemes have places where they break down
and fail in bad ways.  Manual verification fills in these gaps.  Without
it, you either fail closed (locking users out of their services
unnecessarily) or fail open (exposing users' communications to an
adversary).

So i think it's worthwhile to talk about good ways to do manual
verification under common constraints.

> That said, I recently created a ton of ssh
> keys for testing purposes and I was reminded of the beauty of Adrian
> Perrig's randomart hash visualization:
> 
> +--[ 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 -- we've
discussed it here before [0]; no one was advocating it and several folks
expressed pretty deep skepticism that this is a useful representation
for users.  do you think it's a good idea?  if so, in what contexts?
surely it's terrible over the phone or on a cocktail napkin.

	--dkg

[0] see, for example, multiple mentions in the "useability of public key
fingerprints" thread

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140311/ad38e1a5/attachment.sig>