5. Dichiarazione di applicabilità

Le raccomandazioni di questo documento si applicano principalmente all'implementazione e alla distribuzione dei protocolli applicativi più comunemente utilizzati con TLS e DTLS su Internet oggi. Esempi includono, ma non sono limitati a:

• Software e servizi web che desiderano proteggere il traffico HTTP con TLS.

• Software e servizi di posta elettronica che desiderano proteggere il traffico IMAP, Post Office Protocol versione 3 (POP3) o SMTP con TLS.

• Software e servizi di messaggistica istantanea che desiderano proteggere il traffico Extensible Messaging and Presence Protocol (XMPP) o Internet Relay Chat (IRC) con TLS.

• Software e servizi multimediali in tempo reale che desiderano proteggere il traffico Secure Realtime Transport Protocol (SRTP) con DTLS.

Questo documento non modifica le raccomandazioni di implementazione e distribuzione (ad esempio, le suite di cifratura obbligatorie da implementare) prescritte dai protocolli applicativi esistenti che utilizzano TLS o DTLS. Se la comunità che utilizza tale protocollo applicativo desidera modernizzare il proprio utilizzo di TLS o DTLS per essere coerente con le migliori pratiche raccomandate qui, deve aggiornare esplicitamente la definizione del protocollo applicativo esistente (un esempio è [RFC7590], che aggiorna [RFC6120]).

I progettisti di nuovi protocolli applicativi sviluppati tramite il processo degli Standard Internet [RFC2026] sono tenuti come minimo a rispettare le migliori pratiche raccomandate qui, a meno che non forniscano documentazione di ragioni impellenti che impedirebbero tale conformità (ad esempio, distribuzione diffusa su dispositivi vincolati che mancano di supporto per gli algoritmi necessari).

Sebbene molte delle raccomandazioni fornite qui possano applicarsi anche a QUIC nella misura in cui utilizza il protocollo di handshake TLS 1.3, QUIC e protocolli di trasporto sicuri simili non rientrano nell'ambito di questo documento. Per QUIC specificamente, i lettori sono rimandati alla Sezione 9.2 di [RFC9001].

Questo documento non tratta l'uso di TLS nelle reti di nodi vincolati [RFC7228]. Per raccomandazioni riguardanti la profilazione di TLS e DTLS per piccoli dispositivi con severi vincoli di potenza, memoria e risorse di elaborazione, il lettore è rimandato a [RFC7925] e [IOT-PROFILE].

5.1. Servizi di sicurezza

Questo documento fornisce raccomandazioni per un pubblico che desidera proteggere le proprie comunicazioni con TLS per raggiungere i seguenti obiettivi:

Riservatezza: tutte le comunicazioni a livello applicativo sono cifrate con l'obiettivo che nessuna parte possa decifrarle tranne il destinatario previsto.

Integrità dei dati: qualsiasi modifica effettuata alla comunicazione in transito è rilevabile dal destinatario.

Autenticazione: un endpoint della comunicazione TLS è autenticato come l'entità prevista con cui comunicare.

Per quanto riguarda l'autenticazione, TLS consente l'autenticazione di uno o entrambi gli endpoint della comunicazione. Nel contesto della sicurezza opportunistica [RFC7435], TLS viene talvolta utilizzato senza autenticazione. Come discusso nella Sezione 5.2, le considerazioni relative alla sicurezza opportunistica non rientrano nell'ambito di questo documento.

Se i distributori deviano dalle raccomandazioni fornite in questo documento, devono essere consapevoli che potrebbero perdere l'accesso a uno dei servizi di sicurezza summenzionati.

Questo documento si applica solo agli ambienti in cui è richiesta la riservatezza. Richiede algoritmi e opzioni di configurazione che impongono la segretezza dei dati in transito.

Questo documento presuppone anche che la protezione dell'integritità dei dati sia sempre uno degli obiettivi di una distribuzione. Nei casi in cui l'integrità non è richiesta, non ha senso usare TLS in primo luogo. Esistono attacchi contro la sola protezione della riservatezza che utilizzano la mancanza di integrità per violare anche la riservatezza (vedi, ad esempio, [DegabrieleP07] nel contesto di IPsec).

Questo documento si rivolge ai protocolli applicativi che sono più comunemente usati su Internet con TLS e DTLS. Tipicamente, tutta la comunicazione tra client TLS e server TLS richiede tutti e tre i servizi di sicurezza sopra indicati. Questo è particolarmente vero quando i client TLS sono user agent come browser web o client di posta.

Questo documento non affronta scenari di distribuzione più rari in cui una delle tre proprietà sopra indicate non è desiderata, come il caso d'uso descritto nella Sezione 5.2. Come altro scenario in cui la riservatezza non è necessaria, si consideri una rete monitorata in cui le autorità responsabili del rispettivo dominio di traffico richiedono l'accesso completo al traffico non cifrato (in chiaro) e in cui gli utenti collaborano e inviano il loro traffico in chiaro.

5.2. Sicurezza opportunistica

Esistono diversi scenari importanti in cui l'uso di TLS è facoltativo, cioè il client decide dinamicamente ("in modo opportunistico") se utilizzare TLS con un particolare server o connettersi in chiaro. Questa pratica, spesso chiamata "sicurezza opportunistica", è descritta a lungo in [RFC7435] ed è spesso motivata dal desiderio di retrocompatibilità con le distribuzioni legacy.

In questi scenari, alcune delle raccomandazioni di questo documento potrebbero essere troppo rigide, poiché il rispetto di esse potrebbe comportare un fallback al testo in chiaro, un risultato peggiore rispetto all'uso di TLS con una versione di protocollo o suite di cifratura obsoleta.