Skip to main content

Appendix B. Performance of Multiple DTLS Handshakes

Appendix B. Performance of Multiple DTLS Handshakes​

Standard practice for security protocols such as TLS, DTLS, and SSH, which do inline key management, is to create a separate security association for each underlying network channel (TCP connection, UDP host/port quartet, etc.). This has dual advantages of simplicity and independence of the security contexts for each channel.

Three concerns have been raised about the overhead of this strategy in the context of RTP security:

B.1 Public Key Operation Overhead​

The first concern is the additional performance overhead of doing a separate public key operation for each channel. The conventional procedure here (used in TLS and DTLS) is to establish a master context that can then be used to derive fresh traffic keys for new associations. In TLS/DTLS, this is called "session resumption" and can be transparently negotiated between the peers.

B.2 Network Bandwidth Overhead​

The second concern is network bandwidth overhead for the establishment of subsequent connections and for rehandshake (for rekeying) for existing connections. In particular, there is a concern that the channels will have very narrow capacity requirements allocated entirely to media that will be overflowed by the rehandshake. Measurements of the size of the rehandshake (with resumption) in TLS indicate that it is about 300-400 bytes if a full selection of cipher suites is offered. (The size of a full handshake is approximately 1-2 kilobytes larger because of the certificate and keying material exchange.)

B.3 Additional Round-Trips​

The third concern is the additional round-trips associated with establishing the second, third, ... channels. In TLS/DTLS, these can all be done in parallel, but in order to take advantage of session resumption they should be done after the first channel is established.

For two channels, this provides a ladder diagram something like this (parenthetical numbers are media channel numbers):

Alice                                   Bob
-------------------------------------------
                  <-       ClientHello (1)
ServerHello (1)    ->
Certificate (1)
ServerHelloDone (1)
                  <- ClientKeyExchange (1)
                      ChangeCipherSpec (1)
                              Finished (1)
ChangeCipherSpec (1)->
Finished         (1)->
                                            <--- Channel 1 ready

                  <-       ClientHello (2)
ServerHello (2)    ->
ChangeCipherSpec(2)->
Finished(2)        ->
                  <-  ChangeCipherSpec (2)
                              Finished (2)
                                            <--- Channel 2 ready

So, there is an additional 1 RTT (round-trip time) after Channel 1 is ready before Channel 2 is ready. If the peers are potentially willing to forego resumption, they can interlace the handshakes, allowing channels to be ready contemporaneously.

Last updated on