[messaging] Secure OpenPGP Key Pair Synchronization via IMAP (RFC)

[Tankred Hase]

Hi Trevor,

> Thanks for sharing!  Could you say more about the use case(s) for
> this?  Your blog and spec focus on the "multidevice" case (Alice has a
> laptop and tablet and phone), but you also call the password a "backup
> code" and mention the user losing their device.

We used to call it "keychain code", but that name didn't really make much sense to users. When we looked at the Yahoo E2E UX we saw that they used to term "backup code", which made more sense.

http://yahoo.tumblr.com/post/113708033335/user-focused-security-end-to-end-encryption

> For the multidevice case, did you consider device-pairing protocols
> like PAKE (SRP etc), Short-Auth Strings (SAS), or other (QR, NFC)?
> These could allow the user to deal with much shorter strings, or
> dispense with entering / comparing strings altogether.

Pairing via a PFS scheme would be ideal security wise, but we had to consider the constraints of the web platform. It's not obvious how to get QR codes or NFC to work there.

> They also allow the private key to be transfered between devices,
> without storing an encrypted version on a server.  While the latter is
> secure if encrypted by a high-entropy secret, I'd worry that:
> 
> (A) You encourage users to write down the 24-character secret, which
> is an additional item someone could steal.
> 
> (B) Having to dig out this secret and enter it on phones / tablets is
> not a friendly UI.

We looked at the workflow of users. It turns out people use password managers like 1password to copy/paste the code. So it's not as bad as one would think UX wise.

> (C) The spec allows user-supplied passphrases.  I suspect
> implementations will find that more user-friendly and ignore your
> "please consider the downsides" warning, resulting in crackable
> private keys being backed up to servers:
> """
> The passphrase SHOULD be a random high-entropy uppercase alphanumeric
> string of 24 characters, generated from a cryptographically secure
> pseudo-random number generator (CSPRNG). Should you choose to go with
> a user-supplied passphrase, please consider the downsides of deriving
> the key from a user-supplied passphrase due to a lack of entropy in
> user passwords.
> """

Agreed. The option of allowing user-supplied passphrases could be removed from the spec. Whiteout doesn't offer this option atm anyway.

> Maybe you chose the password instead of device-pairing so it could do
> double-duty for the lost-device case?
> 
> It's not obvious these cases should be served with the same mechanism.
> Per above, I think device-pairing is a better solution for the
> multidevice case.  But this isn't obviously the best solution for
> lost-device case either, since it depends on the server holding the
> encrypted key - if you want reliable access to your data even if the
> server deletes your account or locks you out, you'll need something
> more.

There are definitely more optimal ways to handle different use cases. We just chose to go with the simplest solution possible.

> I also wonder whether multidevice support removes much of the need for
> a separate lost-device mechanism, since users are unlikely to lose all
> devices simultaneously?

Mozilla made an interesting point in a post about Firefox sync. Basically users were confused by pairing between devices and expected to be able to recover their data even if all devices are lost:

https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/

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