As explained in RFC 3920 (section 5), a machine will send the "
<starttls>" tag to indicate that it supports SSL/TLS, and then, when the final "
>" of a subsequent "
<proceed/>" XML element is sent and received, the underlying connection is immediately hijacked to begin a TLS handshake. The handshake consists in TLS messages (which are not XML at all), beginning with
ClientHello (from the TLS "client") and then
ServerHello (from the TLS "server") which includes cipher suite negotiation.
There is no method in XMPP to advertise specific TLS cipher suite support before the TLS handshake. From a packet capture view, you will see the
ServerHello right after the "
<proceed/>" tag, not where the "
<starttls>" element occurs.
A consequence is that machines who use XMPP to talk to each other cannot know whether they will be able to find a TLS cipher suite that they both support before actually committing to TLS usage. It is not a big issue in practice, because SSL/TLS implementations support some fallback cipher suites which all implementations know of (RSA+RC4+SHA-1 and RSA+3DES+SHA-1, namely), even if they usually prefer some other cipher suites.