Last Call Review of draft-ivov-xmpp-cusax-06
review-ivov-xmpp-cusax-06-secdir-lc-hoffman-2013-07-18-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ivov-xmpp-cusax-06-secdir-lc-hoffman-2013-07-18

Greetings. I have reviewed this document for security issues, and have mixed feelings. I apologize for the lateness of this review.

The draft specifies a non-normative way to make clients (and to a small extent, servers) mostly-transparently combine the use of SIP for voice and video with XMPP for instant messaging. It is informational, and talks about the various things that applications developers of software that makes this combination should think about.

Security is barely discussed, likely because a client that is presenting two different protocols that each have their own security frameworks is not going to make the security of either protocol worse. However, user perception of security will be significantly affected by the combination. There is one paragraph that alludes to this in the Security Considerations, but there should be more.

The first sentence of that one paragraph describes mis-matched crypto between the SIP part and the XMPP part, which is fine but mostly invisible to users.

The second sentence is much more worrying: it describes the case where one of the protocols is cryptographically protected and the other has none. This is an all-too-common case with IETF protocols: the user doesn't have to turn on crypto, and once it is not turned on, that fact is forgotten. The document blithely says that the application developer should ensure that such mis-matches are avoided to prevent downgrade attacks, but says nothing about how that could be avoided. A stronger statement would be "if both protocols are not protected by similar levels of cryptographic protection, the user MUST be informed of that and given the opportunity to bring both up to the same level".

There should also be at least a paragraph describing the difference in commonly-used authentication mechanisms for SIP and XMPP. A user may have authenticated one of the two channels with an easily-attacked password, but the other channel with a strong cryptographic mechanism such as TLS client certificates. When you combine two similar functions into one application without making that clear, a user might assume that their IM and voice communications are similarly protected when in fact they are not.

It would also be valuable if the document mentioned the possibility of security mis-match in the introduction, given the high chance for user confusion on the issue.

--Paul Hoffman