[messaging] Whiteout Secure PGP Key Sync

[Daniel Kahn Gillmor]

On 07/09/2014 02:30 PM, Tom Ritter wrote:
> Not mine, it's actually Tankred's (cc-ed), but it looked interesting,
> and as there's been a number of similar things posted lately I'd
> thought I'd send out a ping about it.
> 
> https://blog.whiteout.io/2014/07/07/secure-pgp-key-sync-a-proposal/

Thanks for pointing this out, Tom.  It's an interesting project.

I have some questions about parts of the spec that seem unclear to me.
Tankred, maybe you can clarify?

A) Device Registration Scope says both of these:

 * The device configuration protocol MUST NOT allow a device to
impersonate another one just with the knowledge of its DeviceSecret.

 * The device configuration protocol WILL NOT protect the user from an
attacker stealing the DeviceSecret from the server and impersonating the
device for that DeviceSecret.

The two statements seem in conflict to me, but maybe i'm not
understanding them.

B) the diagrams use Ea(X,Y) and Es(X,Y), i think meaning "Encrypt Y
asymmetrically with key X " and "Encrypt Y symmetrically with key X",
but that's not documented anywhere.

C) it's not clear how Device Registration (as described here) implements
"The device configuration protocol MUST NOT allow multiple devices with
the same DeviceSecret."  -- is this true per user?  or globally?  what
happens if i submit a DeviceSecret that someone else already has used?

D) how is the communication between the client and the server secured
(if at all)?  I'm assuming from context and the 2XX responses that this
is a traditional HTTPS tunnel, presumably anchored with traditional
X.509 trust chain.

E) in all of the documented exchanges, the session keys appear to be
dictated entirely by the server.  This suggests that a possibility for a
poorly-implemented or compromised server to regularly use weak or known
keys.  Is there a reason to avoid, say, a DH-style exchange where both
parties contribute some entropy to establish a novel session key?  I
don't have a specific attack in mind, but it does seem unusual to me to
have an asymmetric arrangement like this.  It also occurs to me that a
rogue server can force a client to decrypt arbitrary session keys for
use in any of these communications.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140710/dcb88c61/attachment.sig>