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

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