ARPA2.net

Haarlebrink 5 Enschede Overijssel 7544 WP The Netherlands rick@openfortress.nl

TLS connections can be run over various transports, and can in turn carry many application protocols. All current transports and at least some application protocols are capable of running between symmetric end points, in what could be called peer-to-peer mode, but the use of TLS introduces a requirement to always assign a client and server role. This specification defines a TLS Extension to remedy that stringency of TLS.

TLS secures many application protocols, some of which can be run symmetrically between peers, possibly after discovery through a mechanism such as mDNS. The introduction of TLS as a security layer underneath application protocols enforces the assignment of asymmetric client and server roles, something that not all protocols were designed to negotiate. Examples of application protocols that do not suggest client and server roles for end points include XMPP and SIP in peer-to-peer mode, or some uses of the symmetric MSRP protocol. In addition, there are many non-standard protocols that have been designed to operate symmetrically from the ground up because they are meant for peer-to-peer operation. TLS and its DTLS variation can be carried over transports UDP, TCP and SCTP. It is commonly understood that UDP can be initiated from both sides at the same time; and though less well-known, TCP and SCTP can also be setup between two active end points; in this situation both end points initiate the connection, and as a result of network communication delays these attempts cross midway. And indeed, this is even a practically possible situation when one or both end points have a known address, for instance as a result of prior exchange of transparent addresses. Furthermore, firewalls and other middle boxes tend to faithfully implement the TCP state diagrams [Figure 6 of ] that enable this connection setup between two active end points. Lacking an obvious active and passive side for at least some transport connections means that this is not always available as a tie-breaker to assign TLS client and TLS server rolese. The need to authenticate a remote peer may help to decide which side must play the role of client, and which is to be the server. But in situations with mutual authentication using a more-or-less symmetric CipherSuite, this last reason for asymmetric client/server role separation may also be unsuitable. To remedy that, this specification introduces a TLS Extension that can be used to indicate that the client/server role assignment is open for negotiation as part of the TLS handshake. It can also be used by a TLS server that wants to actively initiate a connection to a TLS client, and even by a TLS end point that wants to open a hole in its local firewall. The modified protocol flow lets both end points send a ClientHello containing the new TLS Extension, and based on a tie-breaker value in that extension each party reaches the same conclusion on which TLS end point continues as a client, and which continues as a server. The following figure demonstrates how the resulting TLS flow looks.

ClientHello +role_preference +role_preference ServerHello ServerKeyExchange <-------- ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data ]]>

The role_preference extension carries a byte sequence of at least 1 byte and at most 32 bytes in its extension_data field; each of the bytes must have a value of at least 33 and no more than 126; this makes the byte sequences suitable for treatment as case-sensitive ASCII strings; it should however be noted that these strings have no terminating NUL character. These role_preference values may be compared on a byte-by-byte basis to determine whether one is ordered before another. The first byte value that differs determines which of the strings is ordered before the other; and if one string equals the other but has additional bytes then the shorter is ordered before the longer one. When one role_preference values is exactly the same as another, they are said to be ordered as equals. When one role_preference value is neither ordered before, nor as an equal to another, then the one is said to be ordered after the other. An easy way to remember these ordering rules is that an extension value "client" is ordered before extension value "server"; and this hints at the intention: if one role_preference value is ordered before another, then the party who sent the one value should take on the role of TLS client, whereas the party that sent the other value should take on the role of TLS server. When two role_preference are ordered as equals then the surrounding TLS handshake fails, on grounds of not being able to establish a client/server role distinction, which should be reported through a handshake_failure alert.

This section defines procedures for sending ClientHello and processing the reception of one.

A ClientHello with the role_preference extension may be sent once by each of the peers, as the initiation of a TLS handshake. The order in which the sides send this extension is arbitrary. It is only possible to send a ClientHello with the role_preference as the first record in a TLS handshake, either on a fresh connection or during (secure) renegotiation. It is considered an error condition when both sides send a ClientHello but not both incorporate the role_preference extension. This situation MUST result in a handshake_error alert, and may be the cause for a new attempt over a new connection. A more conservative approach would be for a TLS end point to wait for a ClientHello from the remote end point and see if the extension is present; this can work if the remote TLS end point is known to be able to act as a client. Context, historic behaviour and the application protocol can all be helpful determine the most useful approach here. The normal practice, used when sending a ClientHello without caring about the role that one will fulfil, is to generate 32 bytes in the range from 33 to 126, and send those in the role_preference extension. The role_preference value comprising of a single byte valued 33 will never have a value ordered before it; this can be sent to require a client role. The role_preference value comprising of 32 bytes, all valued 126, will never have a value ordered after it; this can be sent to require a server role. When both sides send the same role_preference value, a handshake_error alert will be the result; this will normally be the result of using these role-insisting, non-random values in a conflicting manner. When a TLS end point is neutral about its role as a client or a server, it can send any value in between, and it should send a random value to achieve a high probabily of being compatible with any remote TLS end point. The probability of running into a random value from the remote that happens to be the same will be negligable for long enough extension values. Other details in the ClientHello, such as a Server Name Indication and listed CipherSuites, SHALL be representative only of a potential client role; the TLS end point that ends up in the server role will send a ServerHello with new information and its initial ClientHello SHALL NOT be processed further.

There may be special circumstances in which both end points know of themselves and the remote party that both are able and willing to serve as a client and as a server. This would include application protocols that are willfully programmed to be symmetric, and to use a Symmetric TLS layer. The most notable use case for these are so-called peer-to-peer systems. Under such special circumstances, other defaults may apply, and even in absense of a role_preference extension the logic of this specification could be followed. It is then possible to accept a ClientHello without a role_preference extension and treat it as one that had this extension. It is even possible that one endpoint sends a role_preference extension, while the other leaves it implicit. All this is left to such special applications, and not specified here, other than to mention that there might be more liberating considerations than the general situation described in this specification. Under implicit role_preference, the value that would otherwise be carried in the role_preference TLS extension will in these cases be taken from the random information included in the ClientHello message. Specifically, the first 32 bytes of the random_bytes field in the Random structure. Note that this is the part following after the gmt_unix_time field in the Random structure, but that it does not include the timestamp itself. In this implicit alternative to the role_preference TLS extension, there is no way to enforce the client or server role with a specific value, as that would deteriorate the quality of the random_bytes. Since the use case for implicit role_preference is for parties that are willing and able to perform both roles, this should not feel as a restriction. The implicit role_preference approach is relatively straightforward to wrap around any existing TLS implementation. An end point may be setup as a client, its ClientHello passed from TLS stack out over the network connection to the remote peer, and the remote's ClientHello received but not directly forwarded. Then, the role_preference bytes are extracted from both ClientHello's, and roles assigned. If the local endpoint ends up in the client role, then the remote ClientHello is dropped and further TLS exchanges will be passed on between remote peer and local TLS stack without further intervention. Alternatively, if the local endpoint ends up in the server role, the local TLS client connection is torn down and replaced by a TLS server connection. At that point the ClientHello from the remote peer will be forwarded to the local TLS stack, and further TLS exchanges will be passed on between remote peer and local TLS stack without further intervention.

When a ClientHello with the role_preference extension is received and a ClientHello has not been sent yet, then a ClientHello with the role_preference should still be sent by supporting implementations. Only TLS implementations or configurations that do not support the role_preference extension would not send this ClientHello. After a ClientHello with role_preference is both sent and received, their values can be ordered. When the extension value sent is ordered before the extension value received, the local side will continue as a TLS client and the ClientHello sent continues as the ClientHello record for the TLS handshake, whereas the ClientHello received is strikken from the TLS handshake. When the extension value sent is ordered after the extension value received, the local side will continue as a TLS server and the received ClientHello continues as the ClientHello record for the TLS Handshake, whereas the ClientHello sent is strikken from the TLS handshake. When the extension values sent and received are ordered as equals, a handshake_error alert is locally processed as though it had been received over the TLS connection. When a ClientHello mesage is strikken from the TLS handshake, the following can be said: All the information contained in the strikken ClientHello message is forgotten. The random material in the strikken ClientHello message is therefore also dropped; the same random material may however be used in the ServerHello, since that is sent by the same party and because it impacts further security mechanisms in the same manner. The strikken ClientHello message has no security impact; even the selection of the role is not a security matter, since that is already customarily done outside the protected scope of TLS. As a result, the strikken ClientHello message is not taken into account when constructing the handshake_messages for the Finished message [Section 7.4.9 of ] or other messages. In other words, the handshake_messages are formed from the traditional sequence ClientHello, ServerHello, ...

When a ClientHello with the role_preference extension has been sent, but the remote TLS end point respondes with a ClientHello without role_preference extension, then a handshake_error alert MUST be raised, as the handshake procedure was not properly adapted to this specification. When a ClientHello with the role_preference extension has been sent, but the remote TLS end point responds with a ServerHello, it is clear that no ClientHello is to be expected. The conclusion is then that the remote TLS end point does not implement the role_preference extension. In this case, the handshake continues as it would have without the role_preference extension; the TLS end point that sent the ClientHello continues as a client and the TLS end point that responded with a ServerHello continues as a server. As an exception to the last paragraph, there is the situation where the role_preference was set to require a server role. In this case, a ServerHello response from the remote TLS end point SHOULD be considered an error, and will raise the handshake_error alert. Note that this is actually a new use case, where a server sends a ClientHello and expects the other side to initiate a client connection on its initiative; this is not part of the usual TLS flow, so it does not dismantle any of the normal TLS usage patterns.

When one of the TLS end points has been selected to fulfil the server role, it will send the usual ServerHello. ServerHello messages MUST NOT include the role_preference extension, as this has already been acknowledged in the ClientHello response preceding the ServerHello. In fact, the ServerHello and all follow-up messages conform to the existing TLS procedures. Only when renegotiating TLS with a new handshake will the possibility of change of roles come up again.

The role_preference extension MUST NOT be sent by default by a general TLS implementation. Only when it is implemented with the possibility of symmetric peers in mind, or when it is explicitly configured to permit this mode of operation, SHOULD the role_preference extension be sent. Most current applications of TLS are aware of client and server roles, and will specify their authentication and encryption requirements in those terms. For example, it is often assumed that a client does not offer authentication, but that a server will authenticate to the client. The client thereby becomes the responsible party to detect man-in-the-middle attacks, because the server cannot distinguish an honest client from a rogue one. Note that this protocol flow is asymmetric, and as a result so is its configuration. When welcoming both client and server roles, the TLS implementation conceals the actual client and server role assignment, and the application using it will be considered as a symmetric peer. This has an impact on the configuration, which must now speak in terms of local and remote configuration, instead of in terms of client and server configuration. Not all CipherSuites are equally suited for this mode of operation, but use cases that require mutual authentication are reasonably well-supported, and are also the most likely for symmetric peer-to-peer applications of TLS. During renegotiation of the handshake, the roles of client and server may be swapped. This process is asynchronous to the application-level protocol, and MUST NOT be permitted by default, unless it is explicitly configured from code that is aware of the application protocol's assumptions. TLS implementations that can end up being either a client or a server SHOULD permit separate configuration of the various parameters that are negotiated during the ClientHello, ServerHello handshake. They should permit separate CipherSuite lists for the two roles, for instance, and their use of Server Name Indications and other extensions may also differ between the two roles.

The TLS changes specified here introduce one more message to the TLS handshake. When this message is generated asynchronously, there is no need for an extra roundtrip, as both sides simply start sending it as soon as the connection comes up. Whether this is safe depends in part on the application protocol; symmetric peer-to-peer protocols will often be able to assume support for the extension. When the extension is negotiated by a side that defaults to the client role, then a side that defaults to the server role would await it and be required to send the additional ClientHello in its response to indicate support for the role_preference extension. If this response lets the sides take on their default roles, then no extra roundtrip is required because the additional ClientHello can be sent together with the ServerHello that immediately follows it. If the response switches sides, then half a roundtrip is added, as the sides switch their roles. The added flexbility of making this switch may be considered sufficiently valuable to invest this half roundtrip time. The generated random values for the role_preference extension need not be cryptographically secure values; they merely exist as a tie-breaker in the client/role appointment. This can be achieved with a lower quality random number generator, which can be implemented more efficiently than a secure random number generator.

The ClientHello sent by the server provides additional information, such as the CipherSuites acceptable to the server when it ends up in client mode, and extension information such as a Server Name Indication.

This specification introduces more dynamicity to TLS, and that is automatically a concern. The additional flexibility is not advised as a default mode of operation for general TLS implementations, to avoid interfering with the assumptions made by current applications about strict client/server behaviour of TLS. Applications that are aware of their potential to be either a TLS client or a TLS server should be mindful, and select separate configuration settings for each role. It may be helpful to permit configuration to take place in terms of requirements of authenticating the remote end. And, just as any TLS configuration should take the possibility of NULL CipherSuites into account, it should also be aware of the impact of the various CipherSuites on the two roles to be played. In a symmetric peer-to-peer application, it makes some sense to consider both the client and server role, and setup for both. This work is otherwise done separately on each end, but symmetric peer-to-peer protocols tend to connect in both directions and therefore already require both configurations to be defined. This has not changed; what has changed is that the application is not necessarily aware of which applies. Having said that, most TLS implementations will not conceal the chosen role completely, because many application protocols need to know about it. A concern that TLS end points must be aware of when permitting changes of role, is that there may sometimes be a reason to renegotiate the handshake, in which case the client has a decisive role, whereas the server can only ask the client. Whether this could be problematic is an application-level decision to be taken into account before enabling Symmetric TLS through the role_preference extension. It is also worth noting that the renegotiation provides an opportunity for change of the assignment of client and server roles. This may happen in a manner that is asynchronous to the application-layer protocol. This may or may not be a desired effect, which is why it is recommended as an explicit option to configure, defaulting towards the conservative option of not permitting a change of the roles.

This specification defines a TLS extension, to be registered by IANA in the TLS Extensions Registry, ExtensionType Values subregistry. The Extension Name to be used is role_preference.

This work was conducted under an SIDNfonds grant for the "p2p toolkit" project.