On 6/4/13 9:13 PM, Mark Rejhon wrote: > On Tue, Jun 4, 2013 at 10:34 PM, Peter Saint-Andre <stpe...@stpeter.im > <mailto: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.
True. My point was it might be nice to have a sentence or two about that. > 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. For sure. > 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). <snip/> > 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. I think 'integrity check' brings to mind actual security guarantees. How about: "Receiving clients MUST monitor the seq values as a lightweight check on the synchronization of real-time text messages." > Thanks for your feedback; I'll incorporate these very minor changes that > you've asked. Please note that I checked some minor editorial fixes into git. I can send you the most up-to-date XML if you can't retrieve it from source control: http://xmpp.org/about-xmpp/xsf/xsf-source-control/ > (I assume I'm supposed to provide a 1.0 towards the end > of the LAST CALL). Well, depending on the extent of changes, you'll probably need to submit 0.10 before the XMPP Council vote. The actual 1.0 is published by the XEP Editor (c'est moi). > 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>)" Feel free to fix those, or I can do it before we publish 1.0. Thanks! The spec is in really good shape, so you are to be congratulated for all your hard work. Peter -- Peter Saint-Andre https://stpeter.im/
