[Standards] Proposed changes for ESessions

Jonathan Schleifer js-xmpp-standards at webkeks.org
Fri Jul 18 12:54:20 CDT 2008


Hi!

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
    again.
    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
    then.

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
        this.
        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)
      * 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.

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?

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
in mind.

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.

-- 
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20080718/f1197d46/attachment.pgp 


More information about the Standards mailing list