# Performance of the Transport Layer Security Handshake Over 6 TiSCH
## 2 Background
### The (D)TLS Handshake Protocol  
Both TLSv1.2 and DTLSv1.2 are hybrid cryptosystems. They combine symmetric-key cryptography (for bulk encryption of application traffic) and public-key cryptography (to establish keys for the symmetric algorithms) in a single protocol. They consist of four subprotocols: the record protocol, the handshake protocol, the change cipher specification, and the alert protocol. The record layer encapsulates the three other subprotocols. The RFCs specifying (D)TLSv1.2 [4; 5] also use the term fragment to refer to the body of a record layer message. To avoid confusion with messages that are the explicit result of a fragmentation mechanism--possibly on other layers of the networking stack--in this article we use the term record fragment to denote the body of a record layer message.  
The handshake protocol is responsible for negotiating a session that contains a session identifier, an optional peer certificate (X.509v3), a compression method, a cipher suite, a master secret, and a boolean value stating if the session is resumable. The handshake happens in different phases. We illustrated the message flow in Figure 2.  
Initially, the peers exchange hello messages (_ClientHello_ and _ServerHello_) to agree on a compression method and cryptographic algorithms. The messages also contain randomness and state the support for session resumption. The client can request additional functionalities by including extensions in its hello message.  
Figure 2: The (D)TLS handshake protocol. The initial two messages are only available when DTLS enforces Denial-of-Service protection.  
In the second phase, the peers transfer cryptographic parameters to derive the shared master secret. They also swap credential information to perform (mutual) authentication. Depending on the authentication method and the selected cipher suite, for example, when they use ECDHE_ECDSA as a key exchange method, the server sends a _ServerCertificate_ message. This message contains a list of X.509v3 certificates. The first certificate in the chain is the server's certificate, the last one is a self-signed certificate, potentially from a root Certificate Authority (CA), and represents the trust anchor. TLS and DTLS also support Pre-shared key (PSK) and raw public key (RPK) authentication. Following the server's certificate chain and if the client and the server negotiated an ephemeral key exchange mechanism, the server sends a _ServerKeyExchange_ message. In the case of a static key exchange algorithm, the client already has all the information necessary to continue with the key establishment. When the server wishes to perform mutual authentication, the server requests a client certificate through a _CertificateRequest_ message. The server then notifies the client with the _ServerDone_ message that it is done sending. In response to a _CertificateRequest_ message, the client immediately sends its certificate chain. The client then follows up with the _ClientKeyExchange_ and the _CertificateVerify_ messages. The last two messages provide the server with the client's key share and a signature calculated with the client's private key over the message transcript. The server can verify the authenticity of the client and derive the shared master secret.  
In the final phase of the handshake protocol, the client sends a _ChangeCipherSpec_ message, indicating that the newly derived session key was installed. This message must arrive before the client's last message, the _Finished message_. The latter contains the shared master secret, a string, and a hash of the entire handshake encrypted with the negotiated encryption algorithm and the new session key. The server responds with its _ChangeCipherSpec_ message and _Finished_ message. The final round-trip allows both peers to verify all handshake steps were successful.