6. Considérations diverses
6.1. Appels anonymes
L'usage de DTLS-SRTP ne fournit pas d'appel anonyme; toutefois, il ne l'empêche pas non plus. Toutefois, si l'on ne prend pas garde lors de l'usage de fonctions d'appel anonyme, telles que celles décrites dans [RFC3325] ou [RFC5767], DTLS-SRTP peut permettre de lever l'anonymat d'un appel autrement anonyme. Lors d'appels anonymes, les procédures suivantes SHOULD être suivies pour éviter la levée d'anonymat.
Lors d'appels anonymes, un nouveau certificat auto-signé SHOULD être utilisé pour chaque appel afin que les appels ne puissent pas être corrélés comme provenant du même appelant. Dans les situations où un certain degré de corrélation est acceptable, le même certificat SHOULD être utilisé pour plusieurs appels afin de permettre la continuité de l'authentification; voir la section 8.4.
De plus, notez que dans les réseaux qui déploient [RFC3325], la RFC 3325 exige que la valeur du champ d'en-tête Privacy définie dans [RFC3323] soit réglée sur « id ». Cela s'utilise conjointement avec le mécanisme SIP identity pour garantir que l'identité de l'utilisateur n'est pas affirmée lors de l'activation d'appels anonymes. En outre, le contenu de l'attribut subjectAltName dans le certificat MUST NOT contenir d'information permettant la corrélation ou l'identification de l'utilisateur souhaitant passer un appel anonyme. Notez que respecter cette recommandation ne suffit pas à fournir l'anonymisation.
6.2. Early media
Si une offre est reçue par une extrémité qui souhaite fournir de l'early media, elle MUST prendre le rôle setup:active et peut immédiatement établir une association DTLS avec l'autre extrémité et commencer à envoyer du média. L'extrémité setup:passive peut ne pas encore avoir validé l'empreinte du certificat de l'extrémité active. Les aspects de sécurité du traitement du média dans cette situation sont discutés à la section 8.
6.3. Forking
En SIP, une requête peut fork vers plusieurs extrémités. Chaque requête forkée peut produire une réponse différente. En supposant que le demandeur a fourni une offre, chaque répondant fournira une réponse unique. Chaque répondant formera une association DTLS avec l'offreur. L'offreur peut alors corréler de façon sûre la réponse SDP reçue dans le message SIP en comparant l'empreinte dans la réponse au certificat haché pour chaque association DTLS.
6.4. Appels à offre différée
Une extrémité peut envoyer une requête SIP INVITE sans offre. Dans ce cas, le(s) récepteur(s) de l'INVITE fournissent l'offre dans la réponse et l'initiateur fournit la réponse dans l'ACK ultérieur ou dans la requête PRACK [RFC3262] si les deux extrémités prennent en charge les réponses provisoires fiables. Dans tous les cas, l'extrémité active établit toujours l'association DTLS avec l'extrémité passive comme négocié dans l'échange offre/réponse.
6.5. Associations multiples
Lorsqu'il existe plusieurs flux (p. ex. plusieurs flux média, RTP et RTCP non multiplexés, etc.), le côté actif MAY effectuer les poignées de main DTLS dans n'importe quel ordre. L'annexe B de [RFC5764] donne des indications sur l'exécution parallèle de poignées de main DTLS. Notez que si le répondant devient actif, il ne peut initier des poignées de main que sur un sous-ensemble des flux potentiels (p. ex. si l'audio et la vidéo sont offerts mais qu'il ne souhaite que l'audio). Si l'offreur devient actif, la réponse complète est reçue avant que l'offreur ne commence à initier des poignées de main.
6.6. Modification de session
Une fois qu'une réponse est fournie à l'offreur, chaque extrémité MAY demander une modification de session qui MAY inclure une offre mise à jour. Cette modification peut être portée par une requête INVITE ou UPDATE. Les pairs peuvent réutiliser les associations existantes si elles sont compatibles (c'est-à-dire mêmes empreintes de clé et paramètres de transport), ou en établir une nouvelle selon les mêmes règles que pour les échanges initiaux, en démantelant l'association existante dès que l'échange offre/réponse est terminé. Notez que si le statut actif/passif des extrémités change, une nouvelle connexion MUST être établie.
6.7. Interaction avec les boîtes intermédiaires
Il existe plusieurs interactions potentiellement problématiques entre DTLS-SRTP et les middleboxes, documentées dans [MMUSIC-MEDIA], qui fournit aussi des recommandations pour les éviter.
6.7.1. Interaction avec ICE
Interactive Connectivity Establishment (ICE), tel que spécifié dans [RFC5245], fournit une méthode permettant aux participants d'une session multimédia de vérifier la connectivité mutuelle. Lorsque ICE est utilisé, les vérifications de connectivité ICE sont effectuées avant le début de la poignée de main DTLS. Notez qu'en mode de nomination agressive, plusieurs paires de candidats peuvent être marquées valides avant qu'ICE ne converge vers une seule paire. Les implémentations MUST traiter toutes les paires de candidats ICE associées à un seul composant comme faisant partie de la même association DTLS. Ainsi, il n'y a qu'une seule poignée de main DTLS même s'il existe plusieurs paires valides. Cela peut impliquer d'ajuster les adresses IP des extrémités si la paire sélectionnée change, comme si les paquets DTLS étaient un flux média ordinaire.
Notez que les paquets Simple Traversal of the UDP Protocol through NAT (STUN) sont envoyés directement sur UDP, pas sur DTLS. [RFC5764] décrit comment démultiplexer les paquets STUN des paquets DTLS et SRTP.
6.7.2. Contrôle du latching sans ICE
Si ICE n'est pas utilisé, il existe un risque d'interaction défavorable avec les Session Border Controllers (SBC) via le « latching », comme décrit dans [MMUSIC-MEDIA]. Pour éviter ce problème, si ICE n'est pas utilisé et que la poignée de main DTLS n'est pas terminée à la réception du SDP de l'autre côté, le côté passive MUST effectuer une seule vérification de connectivité STUN [RFC5389] non authentifiée afin d'ouvrir le trou de souris (pinhole) approprié. Toutes les implémentations MUST être prêtes à répondre à cette requête pendant la période de handshake même sans ICE par ailleurs. Toutefois, le côté actif MUST poursuivre la poignée de main DTLS comme il se doit même si aucune telle vérification STUN n'est reçue, et le côté passif MUST NOT attendre une réponse STUN avant d'envoyer son ServerHello.
6.8. Rekeying
Comme avec TLS, les extrémités DTLS peuvent refaire une clé à tout moment en refaisant la poignée de main DTLS. Pendant le rekey, les extrémités continuent d'utiliser le matériel de clé précédemment établi avec DTLS. Une fois les nouvelles clés de session établies, la session peut basculer vers celles-ci et abandonner les anciennes clés. Cela garantit qu'aucune latence n'est introduite pendant le rekeying.
D'autres considérations sur le rekeying lorsque le contexte de sécurité SRTP est établi avec DTLS se trouvent à la section 3.7 de [RFC5764].
6.9. Serveurs de conférence et contextes de chiffrement partagés
Il a été proposé que les serveurs de conférence utilisent le même contexte de chiffrement pour tous les participants. L'avantage est que le serveur de conférence n'a qu'à chiffrer la sortie pour tous les orateurs au lieu d'une fois par participant.
Cette approche de contexte partagé n'est pas possible sous cette spécification car chaque poignée de main DTLS établit des clés neuves qui ne sont pas entièrement sous le contrôle d'une seule partie. On argue toutefois que l'effort pour chiffrer chaque paquet RTP est faible comparé aux autres tâches du serveur de conférence, telles que le traitement des codecs.
Des extensions futures, telles que [SRTP-EKT] ou [KEY-TRANSPORT], pourraient fournir cette fonctionnalité conjointement aux mécanismes décrits ici.
6.10. Média sur SRTP
Parce que le protocole de transfert de données de DTLS est générique, il est moins optimisé pour RTP que SRTP [RFC3711], spécifiquement adapté à cet usage. DTLS-SRTP [RFC5764] a été défini pour négocier le transport SRTP via une connexion DTLS, alliant les performances de SRTP à la gestion de clés simple de DTLS. La possibilité de réutiliser des implémentations logicielles et matérielles SRTP existantes peut dans certains environnements constituer une motivation supplémentaire pour DTLS-SRTP plutôt que RTP sur DTLS. Les implémentations de cette spécification MUST prendre en charge DTLS-SRTP [RFC5764].
6.11. Chiffrement au mieux
[RFC5479] décrit une exigence de chiffrement au mieux où SRTP est utilisé lorsque les deux extrémités le prennent en charge et que la négociation de clés réussit, sinon RTP est utilisé.
[MMUSIC-SDP] décrit un mécanisme pouvant signaler RTP et SRTP comme alternative. Cela permet à l'offreur d'exprimer une préférence pour SRTP, mais RTP est la valeur par défaut et sera comprise par les extrémités qui ne comprennent pas SRTP ni ce mécanisme d'échange de clés. Les implémentations de ce document MUST prendre en charge [MMUSIC-SDP].