Internet DRAFT - draft-vanrein-tls-symmetry
draft-vanrein-tls-symmetry
Network Working Group R. Van Rein
Internet-Draft ARPA2.net
Intended status: Standards Track March 11, 2016
Expires: September 12, 2016
Symmetry for Transport Layer Security
draft-vanrein-tls-symmetry-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Van Rein Expires September 12, 2016 [Page 1]
Internet-Draft TLS Symmetry March 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The role_preference TLS Extension . . . . . . . . . . . . . . 3
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Sending ClientHello with role_preference . . . . . . . . 4
3.1.1. Variation with implicit role_preference . . . . . . . 5
3.2. Receiving ClientHello with role_preference . . . . . . . 6
3.3. Not Receiving ClientHello with role_preference . . . . . 7
3.4. Sending ServerHello . . . . . . . . . . . . . . . . . . . 8
4. Configuring TLS for Symmetric Behaviour . . . . . . . . . . . 8
5. Efficiency Considerations . . . . . . . . . . . . . . . . . . 9
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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
[RFC0793]] that enable this connection setup between two active end
points. Lacking an obvious active and passive side for at least some
Van Rein Expires September 12, 2016 [Page 2]
Internet-Draft TLS Symmetry March 2016
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 <-------> ClientHello
+role_preference +role_preference
ServerHello
ServerKeyExchange
<-------- ServerHelloDone
ClientKeyExchange
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
2. The role_preference TLS Extension
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
Van Rein Expires September 12, 2016 [Page 3]
Internet-Draft TLS Symmetry March 2016
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.
3. Procedures
This section defines procedures for sending ClientHello and
processing the reception of one.
3.1. Sending ClientHello with role_preference
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.
Van Rein Expires September 12, 2016 [Page 4]
Internet-Draft TLS Symmetry March 2016
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.
3.1.1. Variation with implicit role_preference
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
Van Rein Expires September 12, 2016 [Page 5]
Internet-Draft TLS Symmetry March 2016
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.
3.2. Receiving ClientHello with role_preference
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.
Van Rein Expires September 12, 2016 [Page 6]
Internet-Draft TLS Symmetry March 2016
When a ClientHello mesage is strikken from the TLS handshake, the
following can be said:
o All the information contained in the strikken ClientHello message
is forgotten.
o 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.
o 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 [RFC5246]] or other messages. In other words,
the handshake_messages are formed from the traditional sequence
ClientHello, ServerHello, ...
3.3. Not Receiving ClientHello with role_preference
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.
Van Rein Expires September 12, 2016 [Page 7]
Internet-Draft TLS Symmetry March 2016
3.4. Sending ServerHello
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.
4. Configuring TLS for Symmetric Behaviour
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
Van Rein Expires September 12, 2016 [Page 8]
Internet-Draft TLS Symmetry March 2016
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.
5. Efficiency Considerations
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.
6. Privacy Considerations
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.
7. Security Considerations
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
Van Rein Expires September 12, 2016 [Page 9]
Internet-Draft TLS Symmetry March 2016
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.
8. IANA Considerations
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.
9. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
Van Rein Expires September 12, 2016 [Page 10]
Internet-Draft TLS Symmetry March 2016
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Appendix A. Acknowledgements
This work was conducted under an SIDNfonds grant for the "p2p
toolkit" project.
Author's Address
Rick van Rein
ARPA2.net
Haarlebrink 5
Enschede, Overijssel 7544 WP
The Netherlands
Email: rick@openfortress.nl
Van Rein Expires September 12, 2016 [Page 11]
