Appendice B. Prestazioni di più handshake DTLS

La pratica standard per i protocolli di sicurezza come TLS, DTLS e SSH, che eseguono la gestione delle chiavi inline, è creare un'associazione di sicurezza separata per ogni canale di rete sottostante (connessione TCP, quartetto host/porta UDP, ecc.). Questo ha i doppi vantaggi della semplicità e dell'indipendenza dei contesti di sicurezza per ogni canale.

Sono state sollevate tre preoccupazioni riguardo all'overhead di questa strategia nel contesto della sicurezza RTP:

B.1 Overhead delle operazioni a chiave pubblica

La prima preoccupazione è l'overhead aggiuntivo delle prestazioni derivante dall'esecuzione di un'operazione a chiave pubblica separata per ogni canale. La procedura convenzionale qui (utilizzata in TLS e DTLS) è stabilire un contesto master che può quindi essere utilizzato per derivare nuove chiavi di traffico per nuove associazioni. In TLS/DTLS, questo è chiamato "ripresa di sessione" (session resumption) e può essere negoziato in modo trasparente tra i peer.

B.2 Overhead della larghezza di banda di rete

La seconda preoccupazione è l'overhead della larghezza di banda di rete per l'istituzione di connessioni successive e per il rehandshake (per il rinnovo delle chiavi) per le connessioni esistenti. In particolare, c'è una preoccupazione che i canali avranno requisiti di capacità molto ristretti allocati interamente ai media che saranno sovraccaricati dal rehandshake. Le misurazioni delle dimensioni del rehandshake (con ripresa) in TLS indicano che è circa 300-400 byte se viene offerta una selezione completa di suite di cifratura. (La dimensione di un handshake completo è circa 1-2 kilobyte più grande a causa dello scambio di certificati e materiale chiave.)

B.3 Round-trip aggiuntivi

La terza preoccupazione riguarda i round-trip aggiuntivi associati all'istituzione del secondo, terzo, ... canale. In TLS/DTLS, questi possono essere tutti eseguiti in parallelo, ma per sfruttare la ripresa di sessione dovrebbero essere eseguiti dopo che il primo canale è stato stabilito.

Per due canali, questo fornisce un diagramma a scala come questo (i numeri tra parentesi sono i numeri dei canali multimediali):

Alice                                   Bob
-------------------------------------------
                  <-       ClientHello (1)
ServerHello (1)    ->
Certificate (1)
ServerHelloDone (1)
                  <- ClientKeyExchange (1)
                      ChangeCipherSpec (1)
                              Finished (1)
ChangeCipherSpec (1)->
Finished         (1)->
                                            <--- Canale 1 pronto

                  <-       Client Hello (2)
ServerHello (2)    ->
ChangeCipherSpec(2)->
Finished(2)        ->
                  <-  ChangeCipherSpec (2)
                              Finished (2)
                                            <--- Canale 2 pronto

Quindi, c'è 1 RTT (tempo di andata e ritorno) aggiuntivo dopo che il canale 1 è pronto prima che il canale 2 sia pronto. Se i peer sono potenzialmente disposti a rinunciare alla ripresa, possono interlacciare gli handshake, permettendo ai canali di essere pronti contemporaneamente.