On Tue, Jun 4, 2013 at 10:34 PM, Peter Saint-Andre <stpe...@stpeter.im>wrote:
> I have one additional question: do both of the authors (re-)affirm > that they are contributing this specification in conformance with the > XSF's IPR Policy? > > http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ Reaffirmed. I request that the authors describe whether transmission timing > attacks are possible even if message encryption is used. > Stream level encryption wouldn't be any more/less prone to timing attacks than any other XMPP extension that sent message stanzas at a regular interval. The presence/abscence of data being transmitted, may reveal information about whether or not the user is currently actively composing or not, but will be clouded/muddied by other transmissions (presence updates, other extensions, etc). If privacy of keypress interval information is the intent -- then, no -- you would not gain accurate inter-keypress delay information due to the regular transmission interval of 300ms-1000ms, since the keypress interval information is hidden by encryption by having multiple keypresses kept into the same message stanza transmitted at very regular intervals. So the key press delays are not accessible. An interval of 0ms, transmitting each keypress immediately in separate stanzas, can be a different matter altogether. Now -- I am not familiar enough with message level encryption (e.g. XEP-0200), but any timing attack concern would affect other XMPP extensions. Section 4.2.1: "Recipients MUST monitor the seq value as an integrity > check on received real-time text." In what sense does the seq value > provide integrity, and what kind of integrity does it provide? > A very, very, basic, and very very lightweight correctness integrity check, preventing collisions between duplicate "seq" values between multiple simultaneous logins trying to simultaneously compose a message to you. (If you're running a client that implements only the ability to keep one real-time message buffer per window). It is not a guarantee, much like CRC32 isn't (because it's only 2^32 and you can get false CRC32's). If each simultaneous login starts at 0, then collisions of similar seq values can occur, causing one simultaneous login's real time text fragment to be appended to a different simultaneous login's real time text. Sender simultaneous login 1 sends "HELLO" (seq=0) ....real time message buffer = "HELLO" (in sync) Sender simultaneous login 2 sends "GOOD " (seq=0) ....real time message buffer now out of sync ("Keeping Real-Time Text Synchronized" Sender simultaneous login 1 sends message refresh "HELLO THERE" (seq=0) ....real time message buffer = "HELLO THERE" (in sync) Sender simultaneous login 2 sends "BYE" (seq=1) ....real time message buffer = "HELLO THERE BYE" (undetected conflicting rtt) You can see that simultaneous login 1 did a message refresh at seq=0; But simultaneous login 2 sends a new element at an incrementing seq from previous element from the same simultaneous login 2. So seq=0 followed by seq=1 is a valid increment, but seq=0 came from login 1, and seq=1 came from login 2. Now, this corruption will undo itself during the regular message refresh cycle: http://xmpp.org/extensions/xep-0301.html#message_refresh So the corruption will be brief. This issue, is in the case where you don't have full JID (e.g. simultaneous logins into the same MUC), or if you're using a client that only supports one real-time message buffer per window (e.g. you write a simple RTT decoder processing that is based only on bare JID). But, if you randomize seq, this problem typically does not happen (unless you have a rare chance collision between two random numbers within 2^31). And on top of this, simultaneous logins typing simultaneously, and using RTT, will also be a rare situation. So, the seq, ends up being a sufficiently lightweight correctness sequence integrity check. Now, if terminology "integrity check" is not appropriate, let me know what terminology is appropriate. It just helps prevents the potential false-correct colliding <rtt/>'s in the rare case of simultanous logins, and those that happen to type simultaneously (two different people usinfg the same XMPP login; something normally frowned on anyway), during bare-JID-only processing situations. Thanks for your feedback; I'll incorporate these very minor changes that you've asked. (I assume I'm supposed to provide a 1.0 towards the end of the LAST CALL). There's also some minor grammatical/correctness corrections: - One "]" typo character, needs to be removed - Change "per <localp...@domain.tld>" into "per bare JID (<localp...@domain.tld>)" - Change "per <localp...@domain.tld/resource>" into "per full JID (<localp...@domain.tld/resource>)" Thanks! Mark Rejhon
