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 <tr...@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@moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
