[Standards] Proposed changes for ESessions
js-xmpp-standards at webkeks.org
Fri Jul 18 17:54:20 UTC 2008
I'm a Gajim developer and we have implemented ESessions. However, as
we're currently the only XMPP client to my knowledge implementing it
and the XEP is currently deferred, we plan to make a few changes and
like to get them back in the XEP.
1.) While the Sessions XEP explicitly states that session should NOT be
regarded as ended, we think that this is fine for normal sessions,
but not for ESessions.
The reason is quite simple: If a contact changed his status to
unavailable, the reason might be that the connection was lost due
to lost TCP packages. That also means that maybe messages we sent
got lost. As ESessions don't work when a message was lost and thus
decrypting of further messages is not possible, we would like to
regard an ESession as terminated when a contact signs off and
re-establish a new ESession as soon as that user becomes available
We also thought about keeping the thread ID and sending
unencrypted. However, I'm against that as it could be that the
other client reconnected and still think it's in an ESession and
gets problems with this. That's why I prefer to use a new thread ID
2.) I'm not completely satisfied with the security of ESessions. They
give an attacker pretty much possibilities for known plain-text and
Thus, I propose the following changes:
* Add a <random> tag to every stanza before encryption to make
sure an attacker never knows the full plain-text. With the
current version of the XEP, an attacker would know the full
plain-text for example on typing notifications, which can be
spotted very easily on their size (another issue I'll talk
* Typing notifications make it easy for an attacker to do a
timing attack. There are attacks that lets an attacker guess
the content of a message by looking at how long was typed and
the timing distance to the last message.
The solution I'd propose is to send a bogus stanza from time to
time, only including a <random> tag, but with a value a bit
longer than proposed in the first point of 2.).
Additionally, a XEP-0184 receipt request should be added to
SOME of those bogus packets - whether or not that receipt is
added is random. If the client does not support XEP-0184, a
receipt is never requested, of course, therefore the bogus
packets won't request it as well then.
* XEP-0184 receipt requests are always answered instantly. So an
attacker knows by just the timing that a packet is an answer to
a XEP-0184 receipt request. That's why I propose to ALWAYS
answer XEP-0184 receipt requests unencrypted, as the attacker
would only get data for a known full-plain-text attack from
Additionally, bogus XEP-0184 receipt requests should be sent
from time to time - this would already be covered by the point
before this one (bogus stanzas that randomly include a XEP-0184
* Add padding with a random length, so it's impossible to analyze
the message on it's length. Without this, it's easy to guess
from the length of a packet if it's for example a typing
notification, allowing the before mentioned timing attack. Plus
the size of an encrypted message already gives a clue about the
3.) This suggestion is optional and I personally would NOT implement it,
as IMHO, this is against the idea of instant messaging:
Add a random delay to packets, not a big one, only a small time.
This would make timing attacks even harder.
I would add that as an optional thing to the XEP, maybe something
the clients can enable on demand when messaging doesn't need to be
I'd be glad to hear some opinions to these proposals before we
implement them. Maybe someone got even better ideas on how to solve the
However, we are very likely going to do something against these
deficiencies and of course it would be nice if the XEP could be
enhanced by fixes for these deficiencies, so we don't have to give up
being XEP-complaint for ESessions.
It's not that we're only going to implement it exactly in the way I
described above, but we'd really like to see something similar to these
proposals. Of course, we're open to better approaches then those I had
PS: I know that there's no known plain-text attack against AES yet, but
why depend on that so hard? This might change eventually.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the Standards