[messaging] Fwd: TOFU to ease PGP key discovery

[Tankred Hase]

Sorry, forgot to CC the mailinglist on this one as well.


---------- Forwarded message ----------
From: Tankred Hase <tankred at whiteout.io>
Date: 2015-02-10 10:20 GMT+01:00
Subject: Re: [messaging] TOFU to ease PGP key discovery
To: Trevor Perrin <trevp at trevp.net>


Hi Trevor,

>> In the second approach you're dodging the key management problem entirely,
>> whilst opening up a DoS attack - anyone can block your app from sending mail
>> to any user by simply uploading a bogus key to a PGP keyserver.
>
> The DoS issue seems a valid criticism - if you're going to
> automatically encrypt to public keys you have to be sure you have the
> right keys.  If your system frequently encrypts to old or incorrect
> public keys, users will be annoyed at the undecryptable messages, and
> the crypto won't be "invisible" at all.

That's correct. We're not saying we have all the answers here. We
launched OE for HKP to see how it works for users in the real world.
Maybe we're wrong and we'll have to roll it back. But in the onsite
user tests that we've done, average users were able to send encrypted
message to non-whiteout GPG users. If anything that's the value we are
trying to add with out service.

In my opinion there is not one right answer here. There is room enough
in the PGP space for different solutions for different types of users.

> As you point out, HKP keyservers may not be a reliable-enough source
> of "good" public keys to build opportunistic encryption on top of.  I
> think OE works best with provider-based key directories, since the
> provider is inherently in a position to cause delivery failure.
>
> Another reliability issue in Tankred's system is that the directory is
> only queried on sending the first message, not subsequent messages.
> But users change keys - if the Whiteout system doesn't pick this up,
> this would also result in undecryptable messages.  Again, this is
> easier to handle with provider-based key directories, as the provider
> is in the message delivery path and can return an error "you encrypted
> to an old key, here's the new key, try again".

We query the whiteout key server to check for outdated keys. The same
meta-data leakage argument applies here as described by Daniel.

>> Opportunistic crypto is fine, but it feels like this second approach is not
>> any better than just telling people to use Gmail. Both ends have TLS on the
>> wire and it's only susceptible to a targeted attack, so the security level
>> is the same.
>
> I don't see that - if you do end-to-end OE, users can check
> fingerprints to ensure there's no MITM.  This isn't possible with
> Gmail.

Thanks for the feedback. It helps a lot to hear that I'm not
completely crazy here :)

Tankred

-- 
Whiteout Networks GmbH c/o Werk1
Grafinger Str. 6
D-81671 München
Geschäftsführer: Oliver Gajek
RG München HRB 204479