Annexe B. Performance de plusieurs handshakes DTLS
Annexe B. Performance de plusieurs handshakes DTLS
La pratique standard pour les protocoles de sécurité tels que TLS, DTLS et SSH, qui effectuent une gestion de clés en ligne, consiste à créer une association de sécurité distincte pour chaque canal réseau sous-jacent (connexion TCP, quartet hôte/port UDP, etc.). Cela présente deux avantages: la simplicité et l'indépendance des contextes de sécurité pour chaque canal.
Trois préoccupations ont été soulevées concernant la surcharge de cette stratégie dans le contexte de la sécurité RTP:
B.1 Surcharge des opérations de clé publique
La première préoccupation est la surcharge de performance supplémentaire liée à l'exécution d'une opération de clé publique distincte pour chaque canal. La procédure conventionnelle ici (utilisée dans TLS et DTLS) consiste à établir un contexte maître qui peut ensuite être utilisé pour dériver de nouvelles clés de trafic pour de nouvelles associations. Dans TLS/DTLS, cela s'appelle "reprise de session" (session resumption) et peut être négocié de manière transparente entre les pairs.
B.2 Surcharge de la bande passante réseau
La deuxième préoccupation est la surcharge de la bande passante réseau pour l'établissement de connexions ultérieures et pour la repoignée de main (pour le renouvellement de clés) pour les connexions existantes. En particulier, il y a une préoccupation que les canaux auront des exigences de capacité très étroites allouées entièrement au média qui seront dépassées par la repoignée de main. Les mesures de la taille de la repoignée de main (avec reprise) dans TLS indiquent qu'elle est d'environ 300-400 octets si une sélection complète de suites de chiffrement est offerte. (La taille d'une poignée de main complète est d'environ 1-2 kilo-octets plus grande en raison de l'échange de certificat et de matériel de clés.)
B.3 Aller-retours supplémentaires
La troisième préoccupation concerne les aller-retours supplémentaires associés à l'établissement des deuxième, troisième, ... canaux. Dans TLS/DTLS, ceux-ci peuvent tous être effectués en parallèle, mais pour profiter de la reprise de session, ils devraient être effectués après l'établissement du premier canal.
Pour deux canaux, cela fournit un diagramme en échelle comme celui-ci (les chiffres entre parenthèses sont les numéros de canal média):
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
ChangeCipherSpec (1)->
Finished (1)->
<--- Canal 1 prêt
<- ClientHello (2)
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Canal 2 prêt
Ainsi, il y a 1 RTT (temps d'aller-retour) supplémentaire après que le canal 1 soit prêt avant que le canal 2 soit prêt. Si les pairs sont potentiellement disposés à renoncer à la reprise, ils peuvent entrelacer les poignées de main, permettant aux canaux d'être prêts simultanément.