[messaging] Sesame spec

[Trevor Perrin]

On Tue, Apr 4, 2017 at 6:03 AM, Tom Ritter <tom at ritter.vg> wrote:
>
> Nit: In 3.3 bullet #1: "If a relevant non-stale UserRecord exists for
> the recipient UserID, then for each relevant non-stale DeviceRecord
> containing an active session"
>
> What is the word 'relevant' intended to convey here?

Relevant DeviceRecords here are those contained within the UserRecord.
I agree it would be a bit clearer to spell that out.


> If I register someone's
> expired UserID, I can purposely register devices with their old
> DeviceIDs. I can't read the plaintext of course though. Actually, I
> might be able to register someone's UserID (and DeviceIDs) using their
> old public keys if the registration process doesn't require proof of
> possession.

Good observation:  If a UserID changes ownership, people sending to
that UserID who had communicated with the old owner might not want any
possibility of the server giving their UserID to the new owner, as
part of the new owner fetching an undecryptable message.

One approach, as you point out, is for servers to require
proof-of-possession of identity key pairs on account registration, so
that an account ownership change always causes a key-change
notification.

Another mitigation is to not have the server communicate sender
UserIDs to recipients.  If message encryption systems move towards
metadata-hiding architectures, then server(s) might not even know
sender UserIDs, so this issue would be largely eliminated.

A third mitigation would be making it so that UserIDs were more
difficult to re-register, e.g. additional authentication factors such
as passwords that are required to re-register a UserID.

This is worth treating in a Security Consideration, which I'll add
next week (in case there are other clarifications worth adding).


Trevor