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

[Trevor Perrin]

On Thu, Apr 9, 2015 at 7:14 AM, Tankred Hase <tankred at whiteout.io> wrote:
>
>> 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.

Depends on what it's used for.  It's not clear from the video whether
the Yahoo code is also used for multi-device setup, or just backup:

"Please copy down this backup code in a safe place.  You can use it to
restore your encryption keys if you ever delete them accidentally."

Your explanation states there's a dual role (backup and multidevice):

"Your backup code can be used to securely backup and synchronize your
encryption key between devices. [...] Please write down your backup
code and keep it in a safe place."

These explanations are vague about why backup/restore of "your
encryption key" is important.  I think the answer is to allow
decryption of all messages you've received that are stored at the
service, so people don't lose access to old messages?

I expect some users won't bother to write the backup code down, or
will lose it, or will store it someplace hard-to-access, or won't have
the code with them when they purchase a new device.  If new-device
setup requires the backup code, it seems like these users will be
inconvenienced.

Also, some users might decide they don't *want* a backup code since
they prefer forward-secrecy for old messages instead of
recoverability.  Would they have to sacrifice multi-device support?

So I'm still unsure how this fits into an overall key management
system, and whether it makes sense to combine multidevice support and
key backup.


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

It's certainly possible to display a short text string or QR code from
a web app.


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

Good point that password managers tackle a similar problem, so could
be leveraged or at least learned from.

I believe 1Password allows sync via services like DropBox or iCloud,
or device-to-device via Wifi.  For the former, security comes from the
user-chosen "master password", for the latter one device displays a
"secret code" which is entered into the other during the sync process
(and appears ~40 bits):

https://guides.agilebits.com/1password-ios/5/en/topic/sync-over-wifi

Is there any data on how many people use different sync approaches (or
use *any* sync approach)?  I'd also love to know what the protocol is
for Wifi sync, anyone know?


> Agreed. The option of allowing user-supplied passphrases could be removed from the spec.

Agreed, but looking at the example strings from Yahoo and Whiteout I'm
not sure that leaves you with good useability:

Yahoo:
spurrey wanner eligible outgrown diversification hushed adapter hammerer 1

Whiteout:
OA9J-IK9J-TZ2W-LEGP-ASWN-K24B


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

I've seen other people cite Firefox Sync and Brian Warner's "Pairing
Problems" blog as arguments against device-pairing.  For example, the
CONIKS paper:

"Unfortunately, device pairing has proved cumbersome and error-prone
for users in practice"
https://eprint.iacr.org/2014/1004.pdf

But the UI Firefox tried was too awful to support these conclusions, IMO:

https://blog.mozilla.org/warner/2014/04/02/pairing-problems/

Note that users had to register with the Firefox Sync server prior to
running the pairing protocol, and choose (and confirm) a password
which is then "never entered again" (?!)

After this, it's not surprising users would expect that their data was
retrievable from this server based on the password, which was a huge
breakdown between expectations and what the system actually provided.

When you then tried to run the pairing process, you get a short secret
code, but are also given a link "I don't have the device with me"
which then tells you to enter a "Sync Key" which you've never heard of
before and can get from your other device (which you've just said
isn't with you), and then if you click "I have lost my other device"
it lets you erase all data and generate a new "Recovery Key" which I
guess is the same as the "Sync Key"?

Anyways, this is UI design by Kafka, I don't think it argues for or
against any mechanism...

Trevor