On Mon, Feb 9, 2015 at 7:06 AM, Mike Hearn <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
