Anhang B. Leistung mehrerer DTLS-Handshakes

Die Standardpraxis für Sicherheitsprotokolle wie TLS, DTLS und SSH, die Inline-Schlüsselverwaltung durchführen, besteht darin, für jeden zugrunde liegenden Netzwerkkanal (TCP-Verbindung, UDP-Host/Port-Quartett usw.) eine separate Sicherheitsassoziation zu erstellen. Dies hat die doppelten Vorteile der Einfachheit und Unabhängigkeit der Sicherheitskontexte für jeden Kanal.

Drei Bedenken wurden hinsichtlich des Overheads dieser Strategie im Kontext der RTP-Sicherheit geäußert:

B.1 Public-Key-Operations-Overhead

Das erste Bedenken ist der zusätzliche Leistungsoverhead, eine separate Public-Key-Operation für jeden Kanal durchzuführen. Das konventionelle Verfahren hierfür (verwendet in TLS und DTLS) besteht darin, einen Master-Kontext zu etablieren, der dann verwendet werden kann, um neue Verkehrsschlüssel für neue Assoziationen abzuleiten. In TLS/DTLS wird dies "Session Resumption" genannt und kann transparent zwischen den Peers ausgehandelt werden.

B.2 Netzwerkbandbreiten-Overhead

Das zweite Bedenken ist der Netzwerkbandbreiten-Overhead für die Etablierung nachfolgender Verbindungen und für Rehandshake (für Rekeying) für bestehende Verbindungen. Insbesondere besteht die Sorge, dass die Kanäle sehr enge Kapazitätsanforderungen haben werden, die vollständig für Medien zugewiesen sind, die durch den Rehandshake überlaufen werden. Messungen der Größe des Rehandshakes (mit Resumption) in TLS zeigen, dass er etwa 300-400 Bytes beträgt, wenn eine vollständige Auswahl von Cipher-Suiten angeboten wird. (Die Größe eines vollständigen Handshakes ist aufgrund des Zertifikats- und Schlüsselmaterialaustauschs ungefähr 1-2 Kilobyte größer.)

B.3 Zusätzliche Round-Trips

Das dritte Bedenken betrifft die zusätzlichen Round-Trips, die mit der Etablierung der zweiten, dritten, ... Kanäle verbunden sind. In TLS/DTLS können diese alle parallel durchgeführt werden, aber um Session Resumption zu nutzen, sollten sie nach der Etablierung des ersten Kanals durchgeführt werden.

Für zwei Kanäle ergibt sich folgendes Leiterdiagramm (Zahlen in Klammern sind Medienkanal-Nummern):

Alice                                   Bob
-------------------------------------------
                  <-       ClientHello (1)
ServerHello (1)    ->
Certificate (1)
ServerHelloDone (1)
                  <- ClientKeyExchange (1)
                      ChangeCipherSpec (1)
                              Finished (1)
ChangeCipherSpec (1)->
Finished         (1)->
                                            <--- Kanal 1 bereit

                  <-       ClientHello (2)
ServerHello (2)    ->
ChangeCipherSpec(2)->
Finished(2)        ->
                  <-  ChangeCipherSpec (2)
                              Finished (2)
                                            <--- Kanal 2 bereit

Es gibt also einen zusätzlichen 1 RTT (Round-Trip-Time) nachdem Kanal 1 bereit ist, bevor Kanal 2 bereit ist. Wenn die Peers möglicherweise bereit sind, auf Resumption zu verzichten, können sie die Handshakes verschachteln, sodass die Kanäle gleichzeitig bereit sind.