[xmppwg] Review of draft-meyer-xmpp-e2e-encryption-01

Dirk Meyer dmeyer at tzi.de
Sat Mar 21 13:53:16 CDT 2009

Eric Rescorla wrote:
> This leaves us with SAS and shared passwords. The important interface
> differences here are as follows:
> - The SAS must be verified *after* the connection is set up. The password
>   must be set up before hand.
> - You can use the same password with multiple people semi-safely.
>   The SAS is new for every message.
> - SAS probably requires modifying TLS. There are existing mechanisms
>   for passwords.
> - The SAS is "optional" in the sense that you can generate it and not
>   check it. The password is "mandatory" in the sense that if it's
>   specified, it must be supplied or the connection will not be set up.

SAS has one big disadvantage: the two clients must be able to verify it
over a different channel. If you have dump devices similar to Bluetooth
devices, it may be a problem. Some Bluetooth devices have a fixed
password because they have no real user interface, only one button to
put it into peering mode. Using SAS here is complicated, passwords are
easier: one has a fixed password and the other has to know it.

> It's probably a bad idea to use the term "session" here because it has
> a technical meaning in TLS.

I know, there is a TLS session and an XMPP session and we create another
one. But session seems to be the best fitting name.

>    o  A more sophisticated active attack would involve a cryptanalytic
>       attack on the keying material or other credentials used to
>       establish trust between the parties, such as an ephemeral password
>       exchanged during an initial certificate exchange if Secure Remote
>       Password [TLS-SRP] is used.
> The whole point of TLS-SRTP is that this kind of attack is not practical.


> S 5.
>    4.  When an entity wishes to encrypt its communications with a second
>        entity, it sends a Jingle session-initiate request that specifies
>        the desired application type, a possible transport, the sender's
>        X.509 fingerprint, and optionally hints about the sender's
>        supported TLS methods.
> So, I think the fingerprint here represents a bit of confusion vis-a-vis
> my previous notes about the threat model. It principally makes sense
> if you trust the servers... So, it's important to be clear on what
> we're trying to achieve.

We want at least to know if the servers are lying to us.

> I'm pretty skeptical of this stuff where we signal what cipher suites
> we're willing to use in the XMPP. The TLS negotiation design is
> reasonably complex and trying to replicate it (or worse, summarize it)
> here seems problematic.

I know. It would be the best way to work without it, but it may not be
easy to implement with existing TLS libraries. E.g. my TLS lib wants to
know the password before we start. But if the certificates work, why
bother the user with asking for a password? And TLS-SRP requires the
password on server side before the client sends its certificate. We do
not know if we need SRP or not. The only solution would be to try TLS
with certificates and if it fails reset the whole stream.


More information about the xmppwg mailing list