&xmppcore; specifies the use of Transport Layer Security (TLS; see &rfc4346;) for encryption of XML streams, and TLS includes the ability to compress encrypted traffic (see &rfc3749;). However, not all computing platforms are able to implement TLS, and traffic compression may be desirable for communication by applications on such computing platforms. This document defines a mechanism for negotiating the compression of XML streams outside the context of TLS.
+&xmppcore; specifies the use of Transport Layer Security (TLS; see &rfc5246;) for encryption of XML streams, and TLS includes the ability to compress encrypted traffic (see &rfc3749;). However, not all computing platforms are able to implement TLS, and traffic compression may be desirable for communication by applications on such computing platforms. This document defines a mechanism for negotiating the compression of XML streams outside the context of TLS.
XMPP networks use TLS (&rfc4346;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.
+XMPP networks use TLS (&rfc5246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.
To secure communications between serverless entities, it is RECOMMENDED to negotiate the use of TLS and SASL for the XML stream as described in RFC 3920. However, subject to client configuration and local service policies, an entity MAY accept an unauthenticated and unencrypted channel, in which case the client SHOULD warn the human user that the channel is unauthenticated and unencrypted.
It is true that in this case the packets are significantly larger in the pubsub realization than in the old-fashioned presence realization. This is the price of elegance. Implementations SHOULD use native Transport Layer Security compression (see &rfc4346;) or &xep0138; at the application layer to conserve bandwidth.
+It is true that in this case the packets are significantly larger in the pubsub realization than in the old-fashioned presence realization. This is the price of elegance. Implementations SHOULD use native Transport Layer Security compression (see &rfc5246;) or &xep0138; at the application layer to conserve bandwidth.
Note: This specification has been retracted by the author because the problem is not compelling and a real solution would be too complicated.
When two XMPP users communicate, one or both of them may want to know the status of the XMPP communications path (i.e., of all the hops) between them. While the primary motivation is to determine if all the hops are secured via Transport Layer Security (see &rfc4346;) as specified for XMPP in &rfc3920;, more general information about the communications path may also be of interest.
+When two XMPP users communicate, one or both of them may want to know the status of the XMPP communications path (i.e., of all the hops) between them. While the primary motivation is to determine if all the hops are secured via Transport Layer Security (see &rfc5246;) as specified for XMPP in &rfc3920;, more general information about the communications path may also be of interest.
This document describes a protocol for discovering such information, similar in spirit to the traceroute protocol specified in &rfc1393; but specific to XMPP.
The 'delay' attribute is OPTIONAL. If included, it represents the time in milliseconds that it took for the respondent to receive a reply from the target or intermediate respondent.
The 'ip' attribute is OPTIONAL. If included, it represents the IPv4 or IPv6 address of the target or intermediate respondent.
-The 'encrypted' attribute is REQUIRED. It is a boolean &BOOLEANNOTE; that represents whether the hop in question is encrypted via Transport Layer Security (see &rfc4346;) or at a legacy SSL port.
+The 'encrypted' attribute is REQUIRED. It is a boolean &BOOLEANNOTE; that represents whether the hop in question is encrypted via Transport Layer Security (see &rfc5246;) or at a legacy SSL port.
The 'auth' attribute is REQUIRED. It represents whether and how the hop in question is authenticated, in particular via one of the following means:
&xep0114; defines a protocol that enables a server component to connect to an XMPP server. However, there are a number of perceived limitations with that protocol:
The mere exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. The entities SHOULD upgrade the channel to an encrypted stream using the XMPP STARTTLS command defined in &xmppcore; using &rfc4346;, optionally followed by SASL negotiation for mutual authentication (see &rfc4422;).
+The mere exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. The entities SHOULD upgrade the channel to an encrypted stream using the XMPP STARTTLS command defined in &xmppcore; using &rfc5246;, optionally followed by SASL negotiation for mutual authentication (see &rfc4422;).
End-to-end XML streams can be negotiated between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a remote &xep0045; room), or between two remote XMPP services. Therefore, if standard X.509 certificates are used then a party to an e2e XML stream will present either a client certificate or a server certificate as appropriate. If X.509 certificates are used, they MUST at a minimum be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc6120;; however, applications of end-to-end XML streams MAY define supplemental guidelines for certificate validation in the context of particular architectures, such as XEP-0174 for link-local streams and XEP-0247 for direct or mediated streams negotiated through XMPP servers.
To ease the transition from the PGP-based object encryption method specified in &xep0027;, clients using TLS for e2e streams MAY use the OpenPGP TLS extension defined in &rfc5081; (if available).
-Use of other TLS extensions MAY be appropriate as well, including those defined in &rfc4346; and &rfc5054;.
+Use of other TLS extensions MAY be appropriate as well, including those defined in &rfc5246; and &rfc5054;.
For secure client-to-client (C2C) communication the clients can use &xep0174; or &xep0247; to open a connection between the two clients. To open an XMPP connection &xep0246; defines a stream setup similar to the setup used by client-server communications. To secure the communication the extension defines the use of Transport Layer Security as defined in &rfc4346; for encryption and authentication. XEP-0246 suggest to use the OpenPGP TLS extension but does not specify how to negotiate if both peers support the extension and if they are able to verify the OpenPGP key. It makes no sense to use OpenPGP instead of X.509 certificates if there is also no trust on OpenPGP level. This document describes how to negotiate how to use TLS to exchange possible extensions and key fingerprints before the actual TLS handshake.
+For secure client-to-client (C2C) communication the clients can use &xep0174; or &xep0247; to open a connection between the two clients. To open an XMPP connection &xep0246; defines a stream setup similar to the setup used by client-server communications. To secure the communication the extension defines the use of Transport Layer Security as defined in &rfc5246; for encryption and authentication. XEP-0246 suggest to use the OpenPGP TLS extension but does not specify how to negotiate if both peers support the extension and if they are able to verify the OpenPGP key. It makes no sense to use OpenPGP instead of X.509 certificates if there is also no trust on OpenPGP level. This document describes how to negotiate how to use TLS to exchange possible extensions and key fingerprints before the actual TLS handshake.
After the TLS handshake both communication partners MUST be sure that they are communicating with the correct person without a man-in-the-middle.