[Security] [Standards] Proposed changes for ESessions

[Peter Saint-Andre]

Jonathan Schleifer wrote:
> 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. 

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 
separate thread.

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

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

True.

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

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)?

http://mail.jabber.org/mailman/listinfo/security

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080804/f79fcf47/attachment.bin