[Security] [Standards] Proposed changes for ESessions
stpeter at stpeter.im
Mon Aug 4 14:36:04 CDT 2008
Jonathan Schleifer wrote:
> 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.
We talk some about end-to-end encryption at the XMPP Summit recently
(nothing formal -- just a dinner discussion among people who are
interested in the topic). The rough consensus was that we'll work to
implement and deploy end-to-end streams and upgrade using TLS. It's a
bit of a hack, but has some good features. I'll post about that in a
> 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
That is good input to the definition of a session (or chat session),
which is still a bit unclear.
> 2.) I'm not completely satisfied with the security of ESessions. They
> give an attacker pretty much possibilities for known plain-text and
> timing attacks.
> 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
> about later).
> * 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
> receipt request)
I don't we have that problem with an end-to-end stream, do we?
> * 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
> possible content.
> 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
> so instant.
What exactly is the timing attack?
> 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
> current deficiencies?
I've been doing some research on Short Authentication Strings (SAS), and
I think the usage of SAS in ESessions may be close to worthless. But
I'll post about that separately.
> 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.
Given that Ian Paterson seems to have disappeared, you could become a
maintainer for the ESessions specs.
> 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
> in mind.
Sure, we can discuss other approaches, too. But it seems that not so
many people are interested on this list. Perhaps we'd get a more active
conversation going on the security at xmpp.org list (cc'd here)?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080804/f79fcf47/attachment.bin
More information about the Security