[messaging] Sesame spec

[Tom Ritter]

Hey Trevor:

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? We've already
established that we're looking at a non-stale UserRecord for the
recipient we care about. Above, we use 'relevant' to refer to a record
identified by a (UserID, DeviceID, public key) tuple, but here that
doesn't seem to be the case.



3.3 Bullet #3: "and the sender's list of DeviceIDs is current for the
recipient UserID" - this is attackable. 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. This would let me silently collect metadata about the old
user's contacts - that'd be a pretty powerful attack.

-tom





On 31 March 2017 at 15:56, Trevor Perrin <trevp at trevp.net> wrote:
> Hi all,
>
> A spec for the "Sesame" algorithm, which handles session management in
> the Signal Protocol, is available at [1].
>
> Feedback welcome, as usual.
>
> Trevor
>
> [1] https://whispersystems.org/docs/specifications/sesame/
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging