6. Miscellaneous Considerations (Considerazioni varie)
6.1. Chiamate anonime
L'uso di DTLS-SRTP non fornisce chiamate anonime; tuttavia non le impedisce. Se non si ha cura con funzioni di chiamata anonima come in [RFC3325] o [RFC5767], DTLS-SRTP può consentire la de-anonimizzazione di una chiamata altrimenti anonima. Per le chiamate anonime SHOULD seguire le procedure seguenti per evitare la de-anonimizzazione.
Per chiamate anonime SHOULD usare un nuovo certificato autofirmato per ogni chiamata, così le chiamate non possono essere correlate allo stesso chiamante. Dove un certo grado di correlazione è accettabile, SHOULD usare lo stesso certificato per più chiamate per continuità di autenticazione; vedere la sezione 8.4.
Inoltre, nelle reti che dispiegano [RFC3325], RFC 3325 richiede che il valore dell'intestazione Privacy definito in [RFC3323] sia impostato su « id », in congiunzione con SIP Identity per non assertare l'identità dell'utente nelle chiamate anonime. Il contenuto dell'attributo subjectAltName nel certificato MUST NOT contenere informazioni che consentano correlazione o identificazione dell'utente che effettua una chiamata anonima. Seguire questa raccomandazione non basta per l'anonimizzazione.
6.2. Early media
Se un endpoint riceve un'offerta e intende fornire early media, MUST assumere il ruolo setup:active e può stabilire subito un'associazione DTLS con l'altro endpoint e iniziare a inviare media. L'endpoint setup:passive potrebbe non aver ancora validato l'impronta del certificato dell'endpoint attivo. Gli aspetti di sicurezza sono discussi nella sezione 8.
6.3. Forking
In SIP una richiesta può forkare verso più endpoint. Ogni richiesta forkata può produrre una risposta diversa. Assumendo che il richiedente abbia fornito un'offerta, ogni rispondente fornirà una risposta unica. Ogni rispondente formerà un'associazione DTLS con l'offerente. L'offerente può correlare in modo sicuro la risposta SDP ricevuta nel messaggio SIP confrontando l'impronta nella risposta con l'hash del certificato per ogni associazione DTLS.
6.4. Chiamate con offerta ritardata
Un endpoint può inviare INVITE SIP senza offerta. I destinatari forniscono l'offerta nella risposta e l'origine fornisce la risposta nell'ACK successivo o nella richiesta PRACK [RFC3262] se entrambi supportano risposte provvisorie affidabili. In ogni caso l'endpoint attivo stabilisce comunque l'associazione DTLS con quello passivo come negoziato nell'offerta/risposta.
6.5. Associazioni multiple
Con più flussi (es. più stream media, RTP e RTCP non multiplexati, ecc.) il lato attivo MAY eseguire gli handshake DTLS in qualsiasi ordine. L'appendice B di [RFC5764] offre indicazioni sugli handshake paralleli. Se il rispondente diventa attivo, può iniziare handshake solo su un sottoinsieme dei flussi (es. solo audio se offerti audio e video). Se l'offerente è attivo, la risposta completa arriva prima che inizi gli handshake.
6.6. Modifica di sessione
Dopo che una risposta è stata fornita all'offerente, ciascun endpoint MAY richiedere una modifica di sessione che MAY includere un'offerta aggiornata. La modifica può essere in INVITE o UPDATE. I peer possono riusare associazioni esistenti se compatibili (stesse impronte chiave e parametri di trasporto), oppure stabilirne una nuova con le stesse regole degli scambi iniziali, abbattendo l'associazione esistente al completamento dell'offerta/risposta. Se cambia lo stato attivo/passivo degli endpoint, MUST stabilire una nuova connessione.
6.7. Interazione con middlebox
Esistono diverse interazioni potenzialmente negative tra DTLS-SRTP e middlebox, documentate in [MMUSIC-MEDIA], con raccomandazioni per evitarle.
6.7.1. Interazione con ICE
Interactive Connectivity Establishment (ICE), in [RFC5245], consente ai partecipanti di verificare la connettività reciproca. Con ICE i check di connettività ICE avvengono prima dell'inizio dell'handshake DTLS. In modalità di nomination aggressiva, più coppie di candidati possono risultare valide prima della convergenza su una sola. Le implementazioni MUST trattare tutte le coppie di candidati ICE associate a un singolo componente come parte della stessa associazione DTLS: un solo handshake anche con più coppie valide. Possono essere necessari aggiustamenti agli indirizzi se cambia la coppia selezionata, come per un flusso media ordinario.
I pacchetti STUN viaggiano direttamente su UDP, non su DTLS. [RFC5764] descrive il demultiplexing STUN/DTLS/SRTP.
6.7.2. Latching senza ICE
Senza ICE c'è rischio di interazione negativa con SBC tramite « latching », come in [MMUSIC-MEDIA]. Senza ICE, se l'handshake DTLS non è completato alla ricezione dell'SDP dell'altra parte, il lato passivo MUST eseguire un singolo connectivity check STUN [RFC5389] non autenticato per aprire il pinhole. Tutte le implementazioni MUST essere pronte a rispondere durante il periodo di handshake anche senza ICE. Il lato attivo MUST procedere con l'handshake DTLS anche senza tale check STUN; il lato passivo MUST NOT attendere una risposta STUN prima di inviare ServerHello.
6.8. Rekeying
Come in TLS, gli endpoint DTLS possono rifare le chiavi in qualsiasi momento ripetendo l'handshake DTLS. Durante il rekey si continua a usare il materiale di chiave precedente con DTLS. Stabilite le nuove chiavi di sessione, si può passare a quelle e abbandonare le vecchie senza introdurre latenza.
Ulteriori considerazioni sul rekeying con contesto di sicurezza SRTP via DTLS: sezione 3.7 di [RFC5764].
6.9. Server di conferenza e contesti di cifratura condivisi
È stato proposto che i server di conferenza usino lo stesso contesto di cifratura per tutti i partecipanti, riducendo la cifratura dell'uscita a un'unica operazione per tutti gli speaker.
Con questa specifica non è possibile: ogni handshake DTLS stabilisce chiavi fresche non interamente sotto il controllo di una sola parte. Si argomenta però che il costo per cifrare ogni pacchetto RTP è piccolo rispetto ad altri compiti come la elaborazione dei codec.
Estensioni future come [SRTP-EKT] o [KEY-TRANSPORT] potrebbero offrire questa funzionalità insieme ai meccanismi qui descritti.
6.10. Media su SRTP
Il trasferimento dati di DTLS è generico e meno ottimizzato per RTP di SRTP [RFC3711], progettato per quell'uso. DTLS-SRTP [RFC5764] negozia il trasporto SRTP su una connessione DTLS, unendo prestazioni SRTP e gestione chiavi semplice di DTLS. La riuso di implementazioni SRTP esistenti può motivare ulteriormente DTLS-SRTP rispetto a RTP su DTLS. Le implementazioni di questa specifica MUST supportare DTLS-SRTP [RFC5764].
6.11. Cifratura best-effort
[RFC5479] descrive la richiesta di cifratura best-effort: SRTP se entrambi gli endpoint la supportano e la negoziazione delle chiavi riesce, altrimenti RTP.
[MMUSIC-SDP] può segnalare RTP e SRTP come alternative. L'offerente può preferire SRTP; RTP è il default per endpoint senza SRTP o questo scambio di chiavi. Le implementazioni di questo documento MUST supportare [MMUSIC-SDP].