[messaging] TOFU to ease PGP key discovery

[Trevor Perrin]

On Mon, Feb 9, 2015 at 7:06 AM, Mike Hearn <mike at plan99.net> wrote:
> To quickly double check my understanding, your users can get public keys
> from two sources:
>
> Whiteout acts as a CA for its own users
> Or, the app will accept any key that claims to own that email address and is
> uploaded to a key server
>
> Given this model, I'm not sure why you are using PGP. It seems like the
> wrong tool for the job.
>
> In the first approach you're basically doing the PKI, but smaller, with less
> competition/decentralisation and with less software compatibility. You could
> as well just use S/MIME and team up with an existing CA that offers free
> S/MIME certs.

I don't think Whiteout's proposal is the same as CA offerings.
Whiteout is proposing a key directory where you can lookup public
keys.

I think a few CAs issue S/MIME certs (for pay, though there seem to be
free offerings for personal use); but CAs don't run lookup services
that I'm aware of.

Also, the PKI trust model assumes all trust flows through CAs.  The
Whiteout approach, as I understand it, is just trying to make key
distribution automated instead of manual, and provide opportunistic
encryption.  Nothing prevents users from applying traditional PGP
authentication (fingerprints or signatures) to Whiteout-provided keys.


> 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.

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".


> 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.


> If you got out of the CA business and used stuff that's more widely
> implemented than PGP, you could focus 100% on building the best S/MIME UX
> and fixing up some of its warts with proprietary extensions e.g. encrypting
> the subject field. That would be a truly valuable product, plus it would
> come with a built in business model as S/MIME is much more widely used in
> corporate deployments than PGP, so you could sell into the enterprise with
> greater ease.

This is tangential to Tankred's point - all these issues apply to
S/MIME as well as PGP.

But is it really true that S/MIME is "much more widely used in
corporate deployments than PGP"?  Do you have numbers on that, or more
info on who/where all this S/MIME adoption is?

Trevor